[openssl-users] X25519 - why openssl shows server temp key as 253 bits?

[Robert Moskowitz]

And I seem to recall that one bit is for compact representation. That 
is, is y positive or negative.  With p256, you have to transmit x and y 
or deal with the compact representation patent.

On 09/04/2018 08:00 AM, Kyle Hamilton wrote:
> Probably because the definition of X25519 requires that bits 0, 1, and 
> 2 of the first byte of the private key are set to 0 before being used, 
> and OpenSSL counts the number of bits including the highest-order set 
> bit.  (Really, there's an additional 2 bits that are also set to known 
> values: bit 6 of the last byte is set, and bit 7 of the last byte is 
> cleared.  In my view, this actually reduces the necessary brute-force 
> search space from 256 bits to 251 bits. However, literally any 32-byte 
> string can be used as a public key.  Apparently, djb views this as 
> sufficient to call it a 256-bit strength function.)
>
> For the specification, please see the subsection entitled 
> "Responsibilities of the User" in section 3 of 
> https://cr.yp.to/ecdh/curve25519-20060209.pdf .
>
> -Kyle H
>
>
>
>
>
> On Mon, Sep 3, 2018, 22:29 M K Saravanan <mksarav at gmail.com 
> <mailto:mksarav at gmail.com>> wrote:
>
>     Hi,
>
>     When using openssl with X25519, why it shows the server temp key
>     as 253 bits?
>
>     Example:
>
>     ---
>     No client certificate CA names sent
>     Peer signing digest: SHA256
>     Peer signature type: RSA
>     Server Temp Key: X25519, 253 bits
>     ---
>
>     I thought Curve25519 is using 256 bit keys.
>
>     Why 253 instead of 256?
>
>     with regards,
>     Saravanan
>     -- 
>     openssl-users mailing list
>     To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180904/d5799075/attachment.html>