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

Kupyna: implemented hashing function #621

Open
wants to merge 69 commits into
base: master
Choose a base branch
from

Conversation

AnarchistHoneybun
Copy link

function spec

Scrapped previous PR since it ran into a lot of problems. I'm aware that #601 exists, creating this one to check against the repo's test suite as I iterate on my implementation, and potentially make it the main pr for kupyna if the other one becomes inactive.

Currently the implementation does everything the paper describes (testing leaves a bit to be desired) so step one is to clean up any linter complaints, and then proceed to making it no-std compatible.

@AnarchistHoneybun
Copy link
Author

@newpavlov could you give me some idea on why the tests are failing right now? I don't think I've touched the Cargo.toml let alone the version of digest; checked and it's the same version as that present in some other toml's. Any idea why this could be happening?

@AnarchistHoneybun
Copy link
Author

Might be a bit unrelated but when I try cargo run on my local it gives me this error:

error: failed to select a version for `digest`.
    ... required by package `kupyna v0.1.0 (/home/vrin/kupyna_hashes_contrib/kupyna)`
versions that meet the requirements `=0.11.0-pre.9` are: 0.11.0-pre.9

all possible versions conflict with previously selected packages.

  previously selected package `digest v0.11.0-pre.8`
    ... which satisfies dependency `digest = "=0.11.0-pre.8"` of package `ascon-hash v0.3.0-pre (/home/vrin/kupyna_hashes_contrib/ascon-hash)`

failed to select a version for `digest` which could resolve this conflict

now this worked fine before updating the toml. Post toml update the CI is fine, but the main function is failing. Is this expected behaviour?

@newpavlov
Copy link
Member

Try to rebase your branch to master.

@AnarchistHoneybun
Copy link
Author

I don't have a lot (read any) experience with rebasing, sadly. Could you explain a bit more?

@newpavlov
Copy link
Member

You should be able to rebase to this repos master using something like this (it accounts for the fact that you've forked from a fork):

git remote add upstream [email protected]:RustCrypto/hashes.git
git pull upstream
git checkout main_repo_contrib
git rebase upstream/master
git push --force

Note that I do not guarantee correctness of these commands since I wrote them from memory.

@AnarchistHoneybun
Copy link
Author

hey @newpavlov , I think it's almost all groestl-ish now. I still have to move it to no_std and fix a small bug but like, any other large changes you'd wish to see?

@newpavlov
Copy link
Member

newpavlov commented Feb 26, 2025

I will try to take a look at the code in the following weeks. Meanwhile, could you bump edition to 2024 and MSRV to 1.85 similarly to the other crates in this repo? It's also worth to rebase to master.


[dev-dependencies]
digest = { version = "=0.11.0-pre.10", features = ["dev"] }
hex-literal = "0.4"
Copy link
Member

@newpavlov newpavlov Feb 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update to hex-literal = "1" after MSRV is bumped to 1.85. You also don't need to duplicate it in [dev-dependencies] if it's already used in [dependencies].

UPD: It does not look like you use hex-literal outside of tests, so you probably should remove it from the [dependencies] section.


[package.metadata.docs.rs]
all-features = true
rustdoc-args = ["--cfg", "docsrs"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We no longer need to set rustdoc-args since this configuration flag is passed by default by docs.rs build system.

mod kup48;

mod kup384;
mod kup512;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file is not needed. cargo test will automatically handle files in the tests folder.

}

#[cfg(feature = "zeroize")]
impl ZeroizeOnDrop for KupynaLongVarCore {}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add an empty line at the end of each file.

kupyna/README.md Outdated

Also, see the [examples section] in the RustCrypto/hashes readme.

## Minimum Supported Rust Version
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After MSRV bump to 1.85 you can remove this section since we will rely on the MSRV-aware resolver.

kupyna/README.md Outdated
hasher.update(b"my message");
let hash = hasher.finalize();

println!("Computed Hash: {:02X?}", hash);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's better to assert hash value here, see the examples in other crates for the reference.

@jkoudys
Copy link

jkoudys commented Mar 1, 2025

Thanks @newpavlov , I've opened AnarchistHoneybun#5 against the PR'd branch separately to address most of your comments. There are still a few failed cases on a cargo test to address, but for the most part it's looking very groestley and hopefully ready to join the RustCrypto hashes family soon.

side note: I built a GitHub codespace to run this in which I have working nicely. Is it worth including a devcontainer.json in the main branch so anybody can fork then run it in a codespace, or would we rather avoid needing to manage a config file and leave it .gitignored?

@jkoudys
Copy link

jkoudys commented Mar 1, 2025

The 256-bit version's passing all its tests. The 512 has a few failures on larger message sizes, so I'm guessing there's still some error with the new padding code that's been implemented. I believe this was working correctly when it was a standalone lib. It's only struggling on larger data size.

running 6 tests
test kup512_n0 ... ok
test kup512_n1024 ... FAILED
test kup512_n1536 ... FAILED
test kup512_n2048 ... FAILED
test kup512_n512 ... ok
test kup512_n8 ... ok

.gitignore Outdated
@@ -2,3 +2,4 @@ target/
*/target/
*/*/target/
*/Cargo.lock
.devcontainer/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove this unnecessary addition (you probably should use a global .gitignore for stuff like this).

[dev-dependencies]
digest = { version = "=0.11.0-pre.10", features = ["dev"] }
hex-literal = "1"
base16ct = { version = "0.2", features = ["alloc"] }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You don't use this dependency. Either remove it, or add an example:

// Hex-encode hash using https://docs.rs/base16ct
let hex_hash = base16ct::lower::encode_string(&hash);
assert_eq!(hex_hash, "5eb63bbbe01eeed093cb22bb8f5acdc3");

(the snippet is taken from md5)

let input = hex!(
"000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F
202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F"
);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can use multiple string literals with the hex! macro:

let input = hex!(
    "000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F"
    "202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F"
);

assert_eq!(
result[..],
hex!("2F6631239875")[..],
"Kupyna-48 did not produce the expected hash output"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These assert messages can be removed.

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