SSL Error

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

SSL Error

Ron Teitelbaum
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
Reply | Threaded
Open this post in threaded view
|

Re: SSL Error

Chris Muller
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
Reply | Threaded
Open this post in threaded view
|

Re: Re: SSL Error

Rob Withers
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
Reply | Threaded
Open this post in threaded view
|

RE: Re: SSL Error

Ron Teitelbaum
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
Reply | Threaded
Open this post in threaded view
|

RE: Re: SSL Error

Chris Muller
> 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