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: '<a href="https://tls.secg.org:40023'">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 [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
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 <[hidden email]> To: Cryptography Team Development List <[hidden email]>; [hidden email] 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: '<a href="https://tls.secg.org:40023'">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 [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
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 <[hidden email]> > To: Cryptography Team Development List > <[hidden email]>; [hidden email] > 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: > > '<a href="https://tls.secg.org:40023'">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 > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ > cryptography _______________________________________________ Cryptography mailing list [hidden email] 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 | '<a href="https://tls.secg.org:40023'">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: [hidden email] > [mailto:[hidden email]] On Behalf Of > Robert Withers > Sent: Tuesday, January 02, 2007 10:57 PM > To: Cryptography Team Development List > Cc: [hidden email] > 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 <[hidden email]> > > To: Cryptography Team Development List > > <[hidden email]>; [hidden email] > > 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: > > > > '<a href="https://tls.secg.org:40023'">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 > > [hidden email] > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ > > cryptography > > _______________________________________________ > Cryptography mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography _______________________________________________ Cryptography mailing list [hidden email] 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 mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
Free forum by Nabble | Edit this page |