Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rename "djb" type curve to "curve25519" everywhere #475

Closed

Conversation

cosmicexplorer
Copy link
Contributor

@cosmicexplorer cosmicexplorer commented Jun 27, 2022

Broken out from #287.

  1. Rename KeyType::Djb to KeyType::Curve25519.
  2. Rename "DJB_TYPE" to "CURVE_25519_TYPE" in java and swift
  3. Add docs and the Keyed trait to curve*.rs

TODO

@cosmicexplorer cosmicexplorer force-pushed the rename-djb-curve25519 branch 4 times, most recently from 847c612 to 4b4964d Compare June 27, 2022 08:42
@cosmicexplorer cosmicexplorer marked this pull request as draft June 27, 2022 08:44
@cosmicexplorer cosmicexplorer marked this pull request as ready for review June 27, 2022 08:48
@cosmicexplorer cosmicexplorer marked this pull request as draft June 28, 2022 05:30
Copy link
Contributor

@jrose-signal jrose-signal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I forgot to check which PRs were still drafts, whoops. Many comments on this one, and I feel a little bad for being like this since this is how we go months without any documentation progress.

*
* Licensed according to the LICENSE file in this repository.
*/
package org.signal.libsignal.protocol.ecc;
import org.signal.libsignal.protocol.InvalidKeyException;

public class Curve {
public static final int DJB_TYPE = 0x05;
public static final int CURVE_25519_TYPE = 0x05;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the constant here is public, let's leave the old name here too but mark it deprecated. (You can see the combined annotation + javadoc idiom for that elsewhere in the library.)

@@ -26,7 +26,7 @@ public ECPublicKey(byte[] serialized) {

static public ECPublicKey fromPublicKeyBytes(byte[] key) {
byte[] with_type = new byte[33];
with_type[0] = 0x05;
with_type[0] = Curve.CURVE_25519_TYPE;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yuck, good find.

Comment on lines +14 to +16
pub const CTR_NONCE_SIZE: usize = aes::BLOCK_SIZE - 4;

const NONCE_SIZE: usize = Self::CTR_NONCE_SIZE;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please keep unrelated changes out of the diff! :-)

(I don't think we want this change but we can talk about it elsewhere.)

Comment on lines +9 to +22
//!```
//! use libsignal_protocol::KeyPair;
//! use std::collections::HashSet;
//!
//! let alice = KeyPair::generate(&mut rand::thread_rng());
//! assert!(alice == alice.clone());
//! let bob = KeyPair::generate(&mut rand::thread_rng());
//! assert!(alice != bob);
//!
//! // Keys can be hashed and put in sets.
//! let key_set: HashSet<KeyPair> = [alice, bob].iter().cloned().collect();
//! assert!(key_set.contains(&alice));
//! assert!(key_set.contains(&bob));
//!```
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I…don't consider these very compelling examples, heh! They don't show any key cryptography things happening. I wouldn't consider that a blocker, though; the module could just have that one line of documentation for now.


#![warn(missing_docs)]

pub mod curve25519;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We talked about this a bit a while ago, but this is very deliberately not pub, because we don't want libsignal_protocol keys to be thought of as using a specific key implementation. All we need is that they support both signatures and key agreement.

@@ -100,6 +131,8 @@ impl PrivateKey {
result
}

/// Verify a signature from [`Self::calculate_signature`] against another key pair's public key.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a static method, so there's no "another key pair" to worry about.

Comment on lines +176 to 178
/// Return the bytes of a [`PublicKey`] that another party can use to validate against
/// [`Self::verify_signature`].
pub fn derive_public_key_bytes(&self) -> [u8; PUBLIC_KEY_LENGTH] {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's not the only use, it's also for key agreement! I'd drop the use part completely again.

@@ -25,7 +25,7 @@
mod address;
mod consts;
mod crypto;
mod curve;
pub mod curve;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This still counts as changing the module structure; it's the public surface of the module that matters, not its implementation. I still think we should stay flat until we discuss it properly and as a whole.

}
}
/// Interface for structs that perform operations parameterized by values of [`KeyType`].
pub trait Keyed {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, this isn't really the right name for the trait. Public keys and private keys and key pairs aren't "keyed", they're…"typed"?

That said, though, I think this is a reasonable trait, but until we have a use case for it I'd rather not add it, and that won't happen until we support another key type. It might turn out we need different operations besides just key_type.

pub fn calculate_agreement(
&self,
their_key: &PublicKey,
) -> Result<[u8; curve25519::AGREEMENT_LENGTH]> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the place we talked about before: key agreement can't hardcode an output length, because the keys might (someday) not be curve25519 keys.

@cosmicexplorer cosmicexplorer marked this pull request as ready for review July 18, 2022 22:37
cosmicexplorer added a commit to cosmicexplorer/libsignal that referenced this pull request Jul 19, 2022
- [NON RUST/RENAME] rename "DJB_TYPE" to "CURVE_25519_TYPE" in java and swift
- [1+CRYPTO CRATE] make swift/build-ffi.sh --generate-ffi work
- [1+CURVE] add docs and the Keyed trait to `curve*.rs`
cosmicexplorer added a commit to cosmicexplorer/libsignal that referenced this pull request Jul 19, 2022
- [NON RUST/RENAME] rename "DJB_TYPE" to "CURVE_25519_TYPE" in java and swift
- [1+CRYPTO CRATE] make swift/build-ffi.sh --generate-ffi work
- [1+CURVE] add docs and the Keyed trait to `curve*.rs`
cosmicexplorer added a commit to cosmicexplorer/libsignal that referenced this pull request Jul 19, 2022
- [NON RUST/RENAME] rename "DJB_TYPE" to "CURVE_25519_TYPE" in java and swift
- [1+CRYPTO CRATE] make swift/build-ffi.sh --generate-ffi work
- [1+CURVE] add docs and the Keyed trait to `curve*.rs`
- [NON RUST/RENAME] rename "DJB_TYPE" to "CURVE_25519_TYPE" in java and swift
- [1+CRYPTO CRATE] make swift/build-ffi.sh --generate-ffi work
- [1+CURVE] add docs and the Keyed trait to `curve*.rs`
cosmicexplorer added a commit to cosmicexplorer/libsignal that referenced this pull request Sep 9, 2022
- [NON RUST/RENAME] rename "DJB_TYPE" to "CURVE_25519_TYPE" in java and swift
- [1+CRYPTO CRATE] make swift/build-ffi.sh --generate-ffi work
- [1+CURVE] add docs and the Keyed trait to `curve*.rs`
@stale
Copy link

stale bot commented Feb 4, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Feb 4, 2023
@stale
Copy link

stale bot commented Feb 11, 2023

This issue has been closed due to inactivity.

@stale stale bot closed this Feb 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging this pull request may close these issues.

2 participants