Re: [Lwip] [Cfrg] Threshold cryptography on CFRG curves

[Rene Struik <[e-mail]>]

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
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg


-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]