Happy Holidays Ron! Looking at the differences between Cryptography-Core-rww.17 and Cryptography-Core-cmm.18, one possibility might be sharing the same vector of a BlockCipher with another place? Its real easy to do (particularly in test code) but since it's a ByteArray that, for many modes, modified in place, it cannot be shared.
Which primitives is your code using; for example if you're not using CTR mode then we could probably eliminate all 23 changes on that class.
I reviewed all of the changes once again between those two versions and they all look good.
That leaves the differences between Cryptography-RandomAndPrime-rww.2.mcz and Cryptography-RandomAndPrime-RJT.10.mcz. That was all the SecureRandom refactoring, do you think it might be the cause?
- Chris
----- Original Message ---- From: Ron Teitelbaum Ron@USMedRec.com To: Cryptography Team Development List cryptography@lists.squeakfoundation.org; chris@funkyobjects.org Sent: Tuesday, January 2, 2007 9:39:04 PM Subject: SSL Error
Chris and All,
It appears that the changes to
Cryptography-RandomAndPrime and Cryptography-Core break the SSL Code.
If you load
Cryptography-RandomAndPrime-rww.2.mcz Cryptography-Core-rww.17.mcz
Then run our SSL example code:
'https://tls.secg.org:40023' asUrl retrieveContents.
You will get back the proper contents.
Loading
Cryptography-RandomAndPrime-RJT.10.mcz Cryptography-Core-cmm.18
It breaks with a return message from the server Bad Record Mac.
I tried loading each method individually and thought I'd isolated it, but I got inconsistent results. The RJT version of RandomAndPrime was my change to ensure the initial vector had the proper number of bytes.
Test to Mac with the new code appears to still be working.
I have not been able to isolate the error yet, but I thought I'd mention it incase anyone has an idea about which change is causing the error.
Any help would be appreciated.
Thanks,
Ron Teitelbaum Cryptography Team Leader
Happy New Year to everyone!
Ron,
I just loaded all the latest code versions and your test code seems to be working without any issues. I ran all of the URLs and the test server with a SSLTracingConnHandler, all without failure. I wonder what the problem could be on your machine or if anyone else has problems with SSL.
regards, Robert
On Jan 2, 2007, at 7:41 PM, Chris Muller wrote:
Happy Holidays Ron! Looking at the differences between Cryptography-Core-rww.17 and Cryptography-Core-cmm.18, one possibility might be sharing the same vector of a BlockCipher with another place? Its real easy to do (particularly in test code) but since it's a ByteArray that, for many modes, modified in place, it cannot be shared.
Which primitives is your code using; for example if you're not using CTR mode then we could probably eliminate all 23 changes on that class.
I reviewed all of the changes once again between those two versions and they all look good.
That leaves the differences between Cryptography-RandomAndPrime-rww. 2.mcz and Cryptography-RandomAndPrime-RJT.10.mcz. That was all the SecureRandom refactoring, do you think it might be the cause?
- Chris
----- Original Message ---- From: Ron Teitelbaum Ron@USMedRec.com To: Cryptography Team Development List cryptography@lists.squeakfoundation.org; chris@funkyobjects.org Sent: Tuesday, January 2, 2007 9:39:04 PM Subject: SSL Error
Chris and All,
It appears that the changes to
Cryptography-RandomAndPrime and Cryptography-Core break the SSL Code.
If you load
Cryptography-RandomAndPrime-rww.2.mcz Cryptography-Core-rww.17.mcz
Then run our SSL example code:
'https://tls.secg.org:40023' asUrl retrieveContents.
You will get back the proper contents.
Loading
Cryptography-RandomAndPrime-RJT.10.mcz Cryptography-Core-cmm.18
It breaks with a return message from the server Bad Record Mac.
I tried loading each method individually and thought I'd isolated it, but I got inconsistent results. The RJT version of RandomAndPrime was my change to ensure the initial vector had the proper number of bytes.
Test to Mac with the new code appears to still be working.
I have not been able to isolate the error yet, but I thought I'd mention it incase anyone has an idea about which change is causing the error.
Any help would be appreciated.
Thanks,
Ron Teitelbaum Cryptography Team Leader
Happy New Year to everyone!
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Chris and Rob,
I just tried it again and it fails consistently. The problem is definitely in Cryptography-Core.
(1 to: 10) collect: [:a | 'https://tls.secg.org:40023' asUrl retrieveContents.]
Works for core 17 and fails for core 18.
Ok I found the problem.
CBC>>initialVector: aByteArray "Ferguson and Schneier recommend this on page 72 of 'Practical Cryptography'." cipher encryptBlock: aByteArray. super initialVector: aByteArray
Since encrypt and decrypt use initialVector this adds an additional encrypt into every pass. Deleting this method fixes the problem. I understand the intent here so we should either remove initialVector from encrypt and decrypt and set vector directly (adding the destroy method from the superclass initialVector method) or remove this method.
What do you think?
Ron Teitelbaum
-----Original Message----- From: cryptography-bounces@lists.squeakfoundation.org [mailto:cryptography-bounces@lists.squeakfoundation.org] On Behalf Of Robert Withers Sent: Tuesday, January 02, 2007 10:57 PM To: Cryptography Team Development List Cc: Ron@USMedRec.com Subject: Re: [Cryptography Team] Re: SSL Error
Ron,
I just loaded all the latest code versions and your test code seems to be working without any issues. I ran all of the URLs and the test server with a SSLTracingConnHandler, all without failure. I wonder what the problem could be on your machine or if anyone else has problems with SSL.
regards, Robert
On Jan 2, 2007, at 7:41 PM, Chris Muller wrote:
Happy Holidays Ron! Looking at the differences between Cryptography-Core-rww.17 and Cryptography-Core-cmm.18, one possibility might be sharing the same vector of a BlockCipher with another place? Its real easy to do (particularly in test code) but since it's a ByteArray that, for many modes, modified in place, it cannot be shared.
Which primitives is your code using; for example if you're not using CTR mode then we could probably eliminate all 23 changes on that class.
I reviewed all of the changes once again between those two versions and they all look good.
That leaves the differences between Cryptography-RandomAndPrime-rww. 2.mcz and Cryptography-RandomAndPrime-RJT.10.mcz. That was all the SecureRandom refactoring, do you think it might be the cause?
- Chris
----- Original Message ---- From: Ron Teitelbaum Ron@USMedRec.com To: Cryptography Team Development List cryptography@lists.squeakfoundation.org; chris@funkyobjects.org Sent: Tuesday, January 2, 2007 9:39:04 PM Subject: SSL Error
Chris and All,
It appears that the changes to
Cryptography-RandomAndPrime and Cryptography-Core break the SSL Code.
If you load
Cryptography-RandomAndPrime-rww.2.mcz Cryptography-Core-rww.17.mcz
Then run our SSL example code:
'https://tls.secg.org:40023' asUrl retrieveContents.
You will get back the proper contents.
Loading
Cryptography-RandomAndPrime-RJT.10.mcz Cryptography-Core-cmm.18
It breaks with a return message from the server Bad Record Mac.
I tried loading each method individually and thought I'd isolated it, but I got inconsistent results. The RJT version of RandomAndPrime was my change to ensure the initial vector had the proper number of bytes.
Test to Mac with the new code appears to still be working.
I have not been able to isolate the error yet, but I thought I'd mention it incase anyone has an idea about which change is causing the error.
Any help would be appreciated.
Thanks,
Ron Teitelbaum Cryptography Team Leader
Happy New Year to everyone!
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Ok I found the problem.
CBC>>initialVector: aByteArray "Ferguson and Schneier recommend this on page 72 of 'Practical Cryptography'." cipher encryptBlock: aByteArray. super initialVector: aByteArray
Since encrypt and decrypt use initialVector this adds an additional encrypt into every pass. Deleting this method fixes the problem. I understand the intent here so we should either remove initialVector from encrypt and decrypt and set vector directly (adding the destroy method from the superclass initialVector method) or remove this method.
What do you think?
Oh, great catch Ron. I had used the Refactory to abstract BlockCipherMode>>'vector', I didn't noticed this result.
#initialVector: is somewhat of a misnomer for encrypting block to block because it's supposed to be for the *initial* block.
So I posted a fix to Core that adds BlockCipherMode>>#vector:, which simply sets the vector (still avoiding leakage), while #initialVector: still encrypts the IV per Schneiers recommendation.
The CBC test had to be adjusted to account for this (i.e., we cannot compare ciphertexts after a key-change). You should also adjust your Rfc tests to account for the same (i.e., it seems to be a more a test of Rijndael, I would reset the #vector: to the unencrypted value in the spec right after setting the initialVector:).
Thanks! Chris
cryptography@lists.squeakfoundation.org
-
Chris Muller -
Robert Withers -
Ron Teitelbaum