-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
primitives/core/src/crypto.rs
Outdated
let minlen = seed_slice.len().min(big_seed.len()); | ||
seed_slice[0..minlen].copy_from_slice(&big_seed[0..minlen]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should add some debug assert that big_seed.len() > seed_slice.len()
? Otherwise there may will be some implementation that will just use some zeros?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah probably would be better to fail than filling the tail of the seed with zeroes.
But what about embedding the only function that substrate-bip39
offers directly into substrate?
As I said that library provides 1 function (the other is not used anymore after this pr).
The function is this:
pub fn seed_from_entropy(entropy: &[u8], password: &str) -> Result<[u8; 64], Error> {
if entropy.len() < 16 || entropy.len() > 32 || entropy.len() % 4 != 0 {
return Err(Error::InvalidEntropy);
}
let mut salt = String::with_capacity(8 + password.len());
salt.push_str("mnemonic");
salt.push_str(password);
let mut seed = [0u8; 64];
pbkdf2::<Hmac<Sha512>>(entropy, salt.as_bytes(), 2048, &mut seed);
salt.zeroize();
Ok(seed)
}
Sounds a bit bombastic to define a library only to provide a function...
Furthermore, we can then easily modify it to fill a mut slice
(passed as parameter) to fill it with an arbitrary number of bytes... Thus there would be no need to check if we can fill the seed buffer because we always can
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no real opinion here. We can copy the function, I don't really care. I don't know the history behind the substrate-bip39 crate.
Co-authored-by: Anton <anton.kalyaev@gmail.com>
* Crypto pair refactory * Remove unused method * Apply review suggestions * Remove leftovers * Associated type is not really required * Fix after refactory * Fix benchmark-ui test --------- Co-authored-by: Anton <anton.kalyaev@gmail.com>
* Crypto pair refactory * Remove unused method * Apply review suggestions * Remove leftovers * Associated type is not really required * Fix after refactory * Fix benchmark-ui test --------- Co-authored-by: Anton <anton.kalyaev@gmail.com>
While preparing the integration of BLS curves I noticed some duplicated code that can be directly part of the
Pair
trait default implementation.Note 1. I've left a temporary test just to check that the result was the one expected for an implementation that was essentially doing the same stuff but in a fancier way (I'll remove it before merge)
Note 2. I would also like to take the opportunity to hear your opinion about
substrate-bip39
repo/crate.Is a library containing only 2 functions (both of few lines), and one of these now ends up being unused.
Maybe we can just embed the
seed_from_entropy
function in the core code (keeping the tests obviously) Any drawback?