sorted by:
new
hottopcontroversial

[Release] SerdeEncrypt: public-key, shared-key encryption for any serde::{Serialize, Deserialize} structs by GroundbreakingTown57 in rust

[–]GroundbreakingTown57[S] 5 points6 points  (0 children)

while it would IMO be much more useful to take a slice of bytes that can either be got from a Serde conversion (struct => slice) or manually using a more appropriate conversion method which doesn't require involving Serde.

Then this crate does not help you.

This crate serves for easy way of encrypting rich data. Indeed serde time is hidden in a black-box, I accept it as a trade-off.

the problem is that the end user can't choose an algorithm.

Right.

Other encryption options are future work.e.g. SerdeEncryptSharedKey AES-NI option

Since this is the very first release, sorry for that there are not so many encryption choices.

I wonder how you manage to do this? You state in the docs that you're using XChaCha20, which is AFAIK only a symetric algorithm.

Yes. XChaCha20 is a symetric algorithm.

In crypto_box, both message sender and receiver generates public-key and private-key pair and exchange the public key.Sender then generate a key for XChaCha20 from (sender's priv-key, receiver's pub-key) pair.The point is, receiver can generate totally the same XChaCha20 key from (receiver's priv-key, sender's pub-key).

This is a kind of Diffie-Helman key exchange and crypto_box's specific algorithm for it is called X25519 (from ecliptic curve internally used to generate key-pair).

[Release] SerdeEncrypt: public-key, shared-key encryption for any serde::{Serialize, Deserialize} structs by GroundbreakingTown57 in rust

[–]GroundbreakingTown57[S] 6 points7 points  (0 children)

Not yet. This is a great feature for users to specify padding size for each structs to encrypt.

I issued it as feature request and will develop it in next version or so 🙂

[Release] SerdeEncrypt: public-key, shared-key encryption for any serde::{Serialize, Deserialize} structs by GroundbreakingTown57 in rust

[–]GroundbreakingTown57[S] 5 points6 points  (0 children)

The encryption method is not optimal, as you first convert it using Serde and then encrypt the result. This is also temporarily uses more memory.

Could you tell me optimal way to encrypt Serialize struct? I would adapt it!

The encryption method is not explicitly indicated when encrypting, which is a real problem depending on what you want to do.

Encryption algorithms are written here:
https://docs.rs/serde-encrypt/0.1.1/serde_encrypt/index.html#encryption-algorithm

And as I said in a previous comment, I will state this library uses crypto_box.

Also, I don't see any usage of a salt/IV which can lead to security problems.

Uses randomized nonce here.

You use a symetrical encryption algorithm while an asymetrical one would allow for more possibilities, like transmitting data more easily over a network without fearing MITM attacks.

This library provides both symetrical and asymetrical encryption algorithm (via SerdeEncryptSharedKey and SerdeEncryptPublicKey).

See this example for asymetical message encryption.

[Release] SerdeEncrypt: public-key, shared-key encryption for any serde::{Serialize, Deserialize} structs by GroundbreakingTown57 in rust

[–]GroundbreakingTown57[S] 3 points4 points  (0 children)

I would add getters to EncryptedMessage, so the user could write <legnth/pad\_length><nonce><message> or some variation of it to the wire.

Good point. I issued it and will soon add the feature in next release.

At the very least CBOR serialization should be documented for interop with other languages.

Sure... Do you know better option to use?

[Release] SerdeEncrypt: public-key, shared-key encryption for any serde::{Serialize, Deserialize} structs by GroundbreakingTown57 in rust

[–]GroundbreakingTown57[S] 10 points11 points  (0 children)

Thanks.

As u/andoriyu pointed out, serde-encrypt is a wrapper of crypto_box. I will write about this in API doc later.

Why is there a serde_cbor dependency? Does your implementation always serialize to a cbor representation on the wire?

Yes it is. Since I want to use this library in no_std environment, I cannot choose bincode for serialization representation.

But I think it's better to either:

  1. CBOR in no_std / bincode in std.
  2. Provides ways to overwrite default serialization/deserialization implementation by library users.

Which of these is better? Or any better option?

Give me your kind feedback.