-
Notifications
You must be signed in to change notification settings - Fork 256
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding the hash Multimixer-128 #591
base: master
Are you sure you want to change the base?
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.
AFAIK this hash function does not have any real world adoption and it has not received any independent cryptanalysis. The paper has only one citation from the same group. So I am not sure if we want to include this function at the current time.
@tarcieri WDYT?
let mut k = [0u32; 4]; | ||
for i in 0..4 { | ||
h[i] = u32::from_ne_bytes([ | ||
self.key_blocks[self.block_index][i * 4], |
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.
What happens with messages bigger than key size? IIUC this code will panic.
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.
Yes, correct, actually the message and key should be equal in size. I first created the algorithm with a key, but then also implemented a PRNG with a seed. I really wanted to bench the code, and for this I would need a really big key. Ideally I would maybe create two different hash-classes, Multimixer-128 and Multimixer-128-PRNG. I think this would solve the other comments as well.
HashMarker, OutputSizeUser, | ||
}; | ||
use rand_chacha::rand_core::{RngCore, SeedableRng}; | ||
use rand_chacha::ChaCha8Rng; |
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.
You should use the chacha20
crate instead.
key_blocks: Vec<Block<Self>>, | ||
block_sums: [u64; 8usize], | ||
block_index: usize, | ||
rng: Option<ChaCha8Rng>, |
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.
This looks... suspicious. If you want to make code generic over key blocks generator, I think it's better to make it generic over closure.
} | ||
|
||
//Uses key instead of RNG, needs to be same size as message. | ||
fn new_from_slice(key: &[u8]) -> Result<Self, InvalidLength> { |
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.
In general, T::new(&key)
and T::new_from_slice(&key).unwrap()
should produce the same result for the same key
.
Thank you for the review! Yes, it should not be used by the public, but as I understood it, maybe as a replacement for the NU hash in UMAC. I really appreciate the comments, but if it not going to be merged, I think I'll give implementing UMAC a try 🙂. RustCrypto/MACs#1 |
Joan Daemen is listed as one of the authors on the paper, so I wouldn't completely discount it, but I'm not seeing a whole lot in the way of peer review on it. It seems very new. |
Did this to exercise my Rust. Any interest having it in the main repo?