3 ms·

I’m not sure what you mean by there being no public key cryptography here. In the Crypto constructor, a random secret key is generated, and then the generator f

I’m not sure what you mean by there being no public key cryptography here. In the Crypto constructor, a random secret key is generated, and then the generator for Curve25519 is scalar multiplied on the elliptic curve by this secret key to generate a public key. That’s the standard process for X25519 key generation, and it’s what Libsodium does to generate a secret key/public key pair [1]. To establish a shared secret session key, the standard ECDH procedure is used, as seen in Crypto::setRemotePublicKey, where we multiply the other party’s public key by our secret key on curve25519 to establish a shared secret. This shared secret is then used for encryption, since symmetric encryption is generally cheaper + more secure than asymmetric. I absolutely agree that this project needs a more formal cryptographic approach, and should be using a higher level construct (e.g: crypto_secretstream, also from libsodium), but as far as I can tell at first glance, this is a working implementation of X25519. 1: https://github.com/jedisct1/libsodium/blob/7993f5ec5199b6637de6946d001a4e71c05f9ceb/src/libsodium/crypto_box/curve25519xsalsa20poly1305/box_curve25519xsalsa20poly1305.c#L26 https://github.com/jedisct1/libsodium/blob/7993f5ec5199b6637...

yvbbrjdr 5y ago
The reason I "rolled my own" key exchange is that I'd want to use the IETF variant of Chacha20-Poly1305 in my protocol and there doesn't seem to be helper functions for key exchange for this algo.
- opheliate 5y ago
  Unless I'm misunderstanding you, the crypto_secretstream construction [1] that I (and others) have recommended uses ChaCha20Poly1305-IETF as its symmetric cipher. There wouldn't be a key exchange for this algorithm, since it's symmetric. However, the crypto_kx functions [2] generate a 256 bit shared secret, which should work for a ChaCha20Poly1305 key I believe? 1: https://doc.libsodium.org/secret-key_cryptography/secretstream https://doc.libsodium.org/secret-key_cryptography/secretstre... 2: https://doc.libsodium.org/key_exchange https://doc.libsodium.org/key_exchange
  - yvbbrjdr 5y ago
    Probably should have used higher-level functions. Maybe next time :). I don't think I can change the protocol and break compatibility at this time lol. The crypto_kx functions seem to generate 2 symmetric keys for 2 directions. That creates complications in the code and that's why I didn't use it initially..
    - opheliate 5y ago
      Yeahhh, that's a fair point about unnecessary complexity. The docs say if only one symmetric key is necessary, you can just set one of tx/rx to null, and the other will still be the requisite 256 bits, but I appreciate why that's a bit ugly.
fulafel 5y ago
I see. I stand corrected - apologies, @yvbbrjdr. Clearly my crypto 101 was too long ago! But my other points still stand I think.

yvbbrjdr 5y ago

The reason I "rolled my own" key exchange is that I'd want to use the IETF variant of Chacha20-Poly1305 in my protocol and there doesn't seem to be helper functions for key exchange for this algo.

opheliate 5y ago
Unless I'm misunderstanding you, the crypto_secretstream construction [1] that I (and others) have recommended uses ChaCha20Poly1305-IETF as its symmetric cipher. There wouldn't be a key exchange for this algorithm, since it's symmetric. However, the crypto_kx functions [2] generate a 256 bit shared secret, which should work for a ChaCha20Poly1305 key I believe? 1: https://doc.libsodium.org/secret-key_cryptography/secretstream https://doc.libsodium.org/secret-key_cryptography/secretstre... 2: https://doc.libsodium.org/key_exchange https://doc.libsodium.org/key_exchange
- yvbbrjdr 5y ago
  Probably should have used higher-level functions. Maybe next time :). I don't think I can change the protocol and break compatibility at this time lol. The crypto_kx functions seem to generate 2 symmetric keys for 2 directions. That creates complications in the code and that's why I didn't use it initially..
  - opheliate 5y ago
    Yeahhh, that's a fair point about unnecessary complexity. The docs say if only one symmetric key is necessary, you can just set one of tx/rx to null, and the other will still be the requisite 256 bits, but I appreciate why that's a bit ugly.

fulafel 5y ago

I see. I stand corrected - apologies, @yvbbrjdr. Clearly my crypto 101 was too long ago! But my other points still stand I think.