Request for review - Adding db persistence for all SecretFormat of vault keys as well as supporting derivations

Clients Ğcli
,
2

Some quick general feedback before a code review:

about english

On a plusieurs fois essayé de passer à l’anglais sur ce forum

Mon avis est qu’il vaut mieux écrire anglais quand ce n’est pas trop un frein pour faciliter l’intégration de nouveaux contributeurs non francophones, sachant que la plupart des devs comprennent plutôt bien l’anglais.

I knew about Diesel (https://diesel.rs/), not SeaORM. Did you do some comparison to guide your choice?

The mnemonic is kind of a human-readable version of a seed and can be used to derive any kind of key using the appropriate KDF. The naming appears a bit confusing to me.

The seed is not “ed25519”, it is used to derive a key pair. And the problem is mainly the low entropy of the seed if a human is asked as entropy source. See these steps:

/// get keypair from Cesium id/pwd
pub fn pair_from_cesium(id: String, pwd: String) -> nacl::sign::Keypair {
	let params = scrypt::Params::new(12u8, 16u32, 1u32, 32).unwrap();
	let seed = &mut [0u8; 32];
	scrypt::scrypt(&pwd.into_bytes(), &id.into_bytes(), &params, seed).unwrap();
	nacl::sign::generate_keypair(seed)
}

The scheme is:

human entropy (id, passwd)
:arrow_down: (scrypt)
seed
:arrow_down: (nacl)
keypair

The security problem lies in the way we are using human “entropy” and scrypt to build the seed, not the way we are using nacl KDF to derive the key.

You should not call this “private key” when it is only a SURI, this is confusing.

Then None and / have the same meaning :wink:

Always a good idea to reduce the number of dependencies!

I’ll be happy to have @vit feedback on the functional part since a lot of these features are covered in Tikka!

4 Likes