[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bouncycastle-crypto-dev
Subject:    Re: Spam:********, [dev-crypto] TLS 1.2 TlsECDHEKeyExchange expect Signature in wrong format
From:       Hauke Mehrtens <hauke () hauke-m ! de>
Date:       2013-09-29 12:04:26
Message-ID: 5248174A.7010003 () hauke-m ! de
[Download RAW message or body]

Hi Peter,

On 09/29/2013 04:42 AM, Peter Dettman wrote:
> RFC 5246 updated RFC 4492. The digitally-signed element was changed to
> include a signature algorithm field before the actual signature. This
> change affects RFC 4492 digitally-signed elements when TLS 1.2 is
> negotiated. Please see RFC 5246, Appendix A.7. Changes to RFC 4492.

Thanks for the info, I haven't seen RFC 5246, Appendix A.7, I should
have read the full document and not the parts that I though are
relevant. ;-) I will change my implementation and go further with testing.

> Note that the signatures are now over a single hash (as specified in the
> DigitallySigned struct) instead of the MD5/SHA1 combination, and the
> actual signature format is also changed for RSA (to RSASSA-PKCS1-v1_5,
> which includes a DigestInfo encoding). Please see RFC 5246 4.7.
> Cryptographic Attributes
> 
> Regards,
> Pete Dettman
> 
> On 29/09/2013 1:16 AM, Hauke Mehrtens wrote:
>> Bouncycastle expected a SignatureAndHashAlgorithm when TLS 1.2 is used
>> in the Signature of the ServerKeyExchange. This is in
>> TlsECDHEKeyExchange.processServerKeyExchange() where
>> DigitallySigned.parse() is called.
>>
>> In RFC 4492 it only references to Signature without a
>> SignatureAndHashAlgorithm.
>>
>>          struct {
>>              ECParameters    curve_params;
>>              ECPoint         public;
>>          } ServerECDHParams;
>>
>>            select (SignatureAlgorithm) {
>>                case ecdsa:
>>                    digitally-signed struct {
>>                        opaque sha_hash[sha_size];
>>                    };
>>            } Signature;
>>
>>          select (KeyExchangeAlgorithm) {
>>              case ec_diffie_hellman:
>>                  ServerECDHParams    params;
>>                  Signature           signed_params;
>>          } ServerKeyExchange;
>>
>> In  RFC 5246 DigitallySigned is added which has a
>> SignatureAndHashAlgorithm, but this is not Signature and I can not find
>> a new definition of the Signature in RFC 5246.
>>
>>        struct {
>>           SignatureAndHashAlgorithm algorithm;
>>           opaque signature<0..2^16-1>;
>>        } DigitallySigned;
>>
>> We already had problems to determine the correct hash algorithm used for
>> such a signature based on the RFC's when we tested with other TLS
>> implementations.
>>
>> Hauke
>>
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]