Question regarding use of Orion

[brycx]

Hi there!

I'm the author and maintainer of orion and recently came over this project, which is using the orion::aead API. First off, thanks for considering and using orion, that is very rewarding for me.

Second, I was wondering if you were aware that orion also provides a BLAKE2b implementation? The reason I'm asking is, because instead of using orion for BLAKE2b, the blake2_rfc crate is pulled in. So I'm wondering if there's something you dislike about the API provided by orion, which I might be able to improve? Of course, I'm also interested in any other reason for the current choice.

As an example, the orion::hazardous implementation for BLAKE2b could be used as such, where blake2_rfc is used now:

let hash_salt = SecretKey::from_slice(SIGNATURE_BLAKE2B_HASH_SALT)?;
let mut ctx = Blake2b::new(Some(&hash_salt), SIGNATURE_BLAKE2B_HASH_SIZE)?;
ctx.update(&packed_data)?;
let packet_hash = ctx.finalize()?.as_ref();

[norgance-admin]

Hi !

This is a side project that I do for fun and to learn technologies I'm not familiar with. I'm a beginner in Rust, so my code may be a bit scary in its current state. I wanted end2end encryption using specifically xchacha20poly1305 and nothing else to please a friend into crypto. I spent some time looking around libraries and orion::aead did check all the boxes and it was very easy to use and understand. So thanks for your work :-)

I use blake2b in various place, not convinced about blake3, and I simply copy/pasted older code using blake2_rfc. The orion API is fine, though I would probably create an utility method to use it in a single function call like blake2_rfc.

By the way, I also use argon2id and I see that orion offers argon2i only. Is there any reason for that, other than someone needs to implement it of course ?

[brycx]

Thank you for the kind words.

The orion API is fine, though I would probably create an utility method to use it in a single function call like blake2_rfc.

That makes sense in this case, where you know all the parameters are valid (&packed_data would hardly exceed the size limit).

By the way, I also use argon2id and I see that orion offers argon2i only. Is there any reason for that, other than someone needs to implement it of course ?

Main reason was the need for additional dependencies to support the threading. Back when I looked into that, they all had varying degrees of unsafe code in use, which orion tries to abstain from. Of course someone would have to implement it as well. Is there any reason you require the id variant strictly over i?

[norgance-admin]

I actually use argon2id without threads using ThreadMode::Sequential from the rust-argon2 crate, as it runs in a WebWorker on the client browser and I don't think WebWorkers and WebAssembly support threads (yet?).

As for why argon2id, it's simply because it's the recommendation:

The Argon2id variant with t=1 and maximum available memory is
RECOMMENDED as a default setting for all environments.  This setting
is secure against side-channel attacks and maximizes adversarial
costs on dedicated bruteforce hardware.

[brycx]

I heard there were some experiments with it, though I don't know if they have something working. In terms of using Argon2 in in sequential mode, this seems to be viable, but then we're just missing someone to implement it.