Opened 4 years ago

Last modified 2 years ago

#16562 new defect

Harmonize curve25519-signature format with what others are doing

Reported by: nickm Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-relay x25519 cross-signature needs-design
Cc: isis, hdevalance Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Here's another one that we have to do before the 0.2.7.2-alpha release if we're going to do it at all:

https://github.com/trevp/tswip/blob/master/curve25519sigs.md

I'm not in love with the differences here, but they seem mostly harmless. Trevor tells me that there's a chance of his that format being standardized. If so, we might as well help it along by doing what they do.

Changing the nonce-generation mechanism is IMO not very important. The change to consider before the next alpha would be the signature format.

Child Tickets

Change History (12)

comment:1 Changed 4 years ago by nickm

Right now, our ref10 code's verification logic does:

  if (signature[63] & 224) goto badsig;

And donna's verification logic does:

        if ((RS[63] & 224) || !ge25519_unpack_negative_vartime(&A, pk))
                return -1;

So if we're going to add support for this, we're going to need to do it in these steps:

  1. Alter the verification logic to accept the new sign bit location.
  2. Some time later, generate descriptors with their crosscertification signatures in the new format.
  3. Some time later, remove support for accepting the old signature format format.

comment:2 Changed 4 years ago by nickm

Priority: blockernormal

Actually, if we follow that process, I think we can defer this to 0.2.7.3-alpha or later, since we need to be backward compatible for a while. So, downgrading.

comment:3 Changed 4 years ago by teor

The link in the description is broken.
Any idea where the spec went?

comment:4 Changed 4 years ago by nickm

Darn, apparently that was a private repository. :p

Trevor tells me that there should be a public version in a week or two.

comment:5 Changed 4 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.8.x-final

comment:6 Changed 4 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.???

Move a few tickets out of 0.2.8. I would take a good patch for most of these if somebody writes one. (If you do, please make the ticket needs_review and move it back into maint-0.2.8 milestone. :) )

comment:7 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:8 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:9 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:10 Changed 2 years ago by nickm

Cc: isis hdevalance added
Severity: Normal

comment:11 Changed 2 years ago by nickm

Keywords: tor-relay x25519 cross-signature needs-design added

comment:12 Changed 2 years ago by isis

Hi! I talked to Trevor briefly about this and he says:

Hi, it would be great to align! The XEdDSA spec is here: https://whispersystems.org/docs/specifications/xeddsa/ . However, I'm going to update that spec soon as "Generalized EdDSA": https://moderncrypto.org/mail-archive/curves/2017/000925.html . This is compatible but has different private nonce generation. This is already implemented at https://github.com/WhisperSystems/libsignal-protocol-c/tree/master/src/curve25519/ed25519/additions/generalized, so it would be easy to test for compatibility.


He also says we could/should sit down some afternoon and grapple with all the differences.

If we do change the verification format, is there already a subprotocol number which would need to change?

Note: See TracTickets for help on using tickets.