Hi Phil:
The link below provides specifications (Appendix J) and examples
(Appendix K) for representations of curve points (where these are
represented in a lossless manner). While the examples only deal with
curves over the field GF(p), where p=2^255-19, the specifications are
general and, thereby, also can be used for, e.g., Curve448.
Please see
https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-08#appendix-K.1
I hope this helps.
Best regards, Rene
On 12/17/2019 11:54 AM, Phillip Hallam-Baker wrote:
I am working my way through an ID describing four schemes using
threshold math based on the Ed25519, Ed448, X25519 and X448 curves.
These will specify
* Threshold Key Generation
* Threshold Decryption
* Mutual Authenticated Key Exchange
* Side channel resistance.
I think I have the math worked out now for the Montgomery curves.
There is something of an issue with encoding signed results. In
particular for X448.
X25519 is 255 bits = 31.7 bytes so there is a spare bit we can use to
express the sign. X448 is 448 bits = 56.0 bytes. So there is no extra
space.
The simplest option seems to be to extend the encoding of X448 results
by one byte so that they are 57 bytes. Which is essentially what we do
for Ed448.
Should I do the same for X25519 as well? After all RFC 7748 section 5
says:
For X25519, the unused, most significant bit MUST be zero.
These results are going to need separate algorithm identifiers in any
case as they are distinct from the regular CurveX results. But the
only circumstance in which they are going to appear on the wire is in
contexts which are not covered by existing IETF protocols, that is
threshold decryption and threshold key generation.
Also note that there is a NIST solicitation on this area:
https://csrc.nist.gov/publications/detail/nistir/8214a/draft
The proposals at the workshop seem to have been focused on threshold
signatures which don't hold much interest for me. If we want to know
that a document was signed by Alice and by Bob, have Alice and Bob
both sign it. Done. Can even define signature quorums (n out of m).
The only advantage I can see in having a threshold scheme is if the
signature can sit in the exact same protocol slot that a regular one
could. And it doesn't look like RFC8032 can be adapted for that.. Or
at least, my attempt failed.
I can split the signature between Alice and Bob so that both of them
have to co-operate to sign. But whoever assembles the contributions
can extract the private key (!). Which isn't going to work if we want
Alice and Bob to split up the signature duties.
This constraint might be acceptable if we were designing some sort of
TPM device and splitting the signature capability between application
layer code and the TPM with the combination of the signature
contributions taking place inside the TPM. But since the TPM is going
to be able to reverse engineer the private key anyway, why not have
the application code just tell the TPM what its contribution to the
private key is... ?
_______________________________________________
Cfrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/cfrg
--
email: [email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
