Skip to content
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

Draft
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

AndersSteenNilsen
Copy link

Did this to exercise my Rust. Any interest having it in the main repo?

@AndersSteenNilsen AndersSteenNilsen marked this pull request as draft June 13, 2024 12:16
@AndersSteenNilsen AndersSteenNilsen mentioned this pull request Jun 15, 2024
18 tasks
Copy link
Member

@newpavlov newpavlov left a 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],
Copy link
Member

@newpavlov newpavlov Jun 16, 2024

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.

Copy link
Author

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;
Copy link
Member

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>,
Copy link
Member

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> {
Copy link
Member

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.

@AndersSteenNilsen
Copy link
Author

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

@tarcieri
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants