Skip to content

Use the constant_time_eq crate instead of our bespoke implementation #5706

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

Merged
merged 1 commit into from
Apr 17, 2025

Conversation

coolreader18
Copy link
Member

The newer versions of the volatile crate have a completely different API from what we were using it for, and the constant_time_eq provides a timing-safe comparison that is more verified to work properly. The only difference is that it makes no attempt to be constant-time if the strings are of different lengths, unlike our function which was based on CPython's implementation. However, I don't think that's actually an important property, considering this is intended to be used for hashed digests, which are inherently a fixed length. (and if you're using RustPython in a security-critical context where you're worried about timing attacks, you're probably doing something wrong.)

@coolreader18 coolreader18 merged commit ecdb7d3 into RustPython:main Apr 17, 2025
10 of 11 checks passed
@coolreader18 coolreader18 deleted the constant_time_eq branch April 17, 2025 16:55
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.

2 participants