On 01/31/2014 04:48 AM, Werner Koch wrote:
I explained it below. RFC-6637 requires the use of SEC encoding which
is nice because you will never have the problems with leading zeroes.
However, EdDSA uses a different compression format without any
identifier (which makes up nice 32 bytes). A leading zero may however
happen. RFC-4880 does not allow that and thus one would need to check
whether to left pad a read MPI before using it with Ed25519 code. As I
said, not a real problem but it would be possible to save 2 lines of
code if we could use a raw octet string.
Werner, it's an unexpected argument...
I would say that the MPI encoding is even more appropriate format when
considering a compact representation (i.e. (x) v.s. (x,y) )
For example, with http://tools.ietf.org/html/draft-jivsov-ecc-compact
the compact representation is exactly an element in the underlying
field, Fp. It's exactly an integer mod p. If we use an MPI for an RSA
key component, why shouldn't we use an MPI for the x as well?
Likewise, with Ed25519 high-bit encoding the value is (almost) an
integer in a Fp field.
It's a good idea to ensure that when you copy the value of an MPI into a
buffer, the highest bytes of the buffer are zeros ;-)
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp