Michael D wrote on Tue, 12 Jan 2010 06:01:23 -0800
(but some of my mail got lost or dropped for some 
reason and I only later found in mail-archive)
(and majordomo 'which' is either broken 
or deceptive, which didn't help matters!)
>>>
Dave,
I think I have been getting ahead of myself and need to do some more 
reading.  More quick questions, if you don't mind me asking.
I have included an answer you gave me months ago regarding Yc. 

For a 192bit curve, the number of bytes is 50.

I imagine one of the bytes is if the point is compressed or uncompressed.
(Is that right?)

What is the length prefix?  Is that what is referred to as
PublicValueEncoding 
in RFC4492?  Where can I read about that and how
it is set?

Thanks for your help, I really appreciate it.
<<<

I seem to be having trouble explaining effectively.
Let's try an example. From s_client -msg per below:

<<< TLS 1.0 Handshake [length 00bb], ServerKeyExchange
    0c 00 00 b7 03 00 13 31 04 d6 f9 6d 02 15 3a 88
    0d da ac ed d7 94 8a ff 6d fa 09 c5 9b ad 39 18
    43 24 34 8d 67 7b ca 22 6e 14 fd ab 32 1a 76 19
    00 a2 39 8e c8 f8 41 6f b6 00 80 1a a7 e3 92 04
    9f 42 db 75 7f 5f 66 7f 43 90 d0 e3 b4 87 e4 9d
    27 17 49 1b c2 68 7e eb 20 c3 a2 b0 a3 df 7a fa
    ab 23 4e 61 b7 8e 11 12 0f 73 74 d0 e9 38 ce 33
    ba 07 21 77 0b a5 fe 40 8d a0 51 12 b7 bf ad 0a
    a3 88 de ce fb a1 a7 73 48 2b 20 48 cd 01 3c f4
    5b 14 b7 a2 70 4f 6d 80 07 4a 2d 9e d8 61 37 71
    28 1f 55 ec 59 69 ba de 40 87 12 ec d5 06 6e 86
    0b ae e6 9e cc f8 ea 27 04 ba dd

I interleave the relevant definitions from 4492 and 4346 
with (hex)offset: bytes selected from the above.

Handshake:
          HandshakeType msg_type;    /* handshake type */ 
0: 0c =server_key_exchange
          uint24 length;             /* bytes in message */ 
3: 00 00 b7
ServerKeyExchange for case ec_diffie_hellman:
                ServerECDHParams    params;
                Signature           signed_params;

params: 
            ECParameters    curve_params;
            ECPoint         public;
curve_params:
            ECCurveType    curve_type;     
4: 03 =named_curve
                (other cases omitted)
                case named_curve:
                    NamedCurve namedcurve;      
5: 00 13 =secp192r1 
point:
            opaque point <1..2^8-1>;     
7: 31 =length=49decimal + 49bytes beginning at 8:
All "vectors" in TLS begin with a length prefix, see 4.3.

So those 49 bytes are the server's point. Per 5.4 it is 
encoded per ANSI X9.62 and can be uncompressed or compressed; 
I don't know/have that standard so I just skip 49 bytes. If I 
ever need to fully understand this I'll read through the code.
Apparently here it was uncompressed, since 2*192b = 48 bytes 
matches almost exactly. Probably first byte 04 means uncompressed.

Then Signature has length 39: 00 80 =128decimal followed by 128bytes.
(In this example it's an RSA-1k signature because I was that cert 
i.e. I negotiated ECDHE-RSA-AES128-SHA.)

Per 5.7 PublicValueEncoding is used in *Client*KeyExchange to specify 
a client with an EC cert uses that subjectkey for its (public) point.
Otherwise ClientKeyExchange contains the client's ephemeral point, 
as ECPoint. It doesn't need to specify the curve, because it must 
share the one specified by the server; and isn't (directly) signed, 
instead it is included in client's CertificateVerify if used 
and of course the whole negotiation is verified by Finished.


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to