-
Notifications
You must be signed in to change notification settings - Fork 82
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
argon2: parallel memory view abstraction #380
Comments
More concretely, I think a prospective The reason for this is the |
The previous parallel implementation of Argon2 was removed in #247. There were soundness concerns about how it handled mutable aliasing, namely that it's unsound for mutable aliases to exist even if they aren't accessed.
This is a discussion issue for how to build a sound abstraction for use in a new parallel implementation of Argon2. Please make sure to read through this issue before attempting a new parallel implementation.
Argon2 memory layout
The memory layout used by Argon2 is somewhat difficult to model in Rust due to how it's arranged, though this choice of arrangement is due to its goals of sequential memory hardness.
https://datatracker.ietf.org/doc/html/rfc9106#section-3.4
(Note: since slices are an important concept in Rust, to disambiguate I'll throw scare quotes on Argon2 "slices")
The parallel implementation is described as follows in the Argon2 paper:
https://www.password-hashing.net/argon2-specs.pdf
This scheme prevents mutable aliasing because for each thread in
p
lanes, it has exclusive mutable access to segmentj
in its own lane, but has a shared view of the segments of previous lanes.To "rustify" the above diagram, for
j = 2
it would allow the following access:Which is to say, each thread has exclusive
&mut [Block]
access to thej
th segment in their lane, and shared&[Block]
access to all segments in all lanes for previous "slices" prior toj
.To make this work, I would suggest having a type like
struct Memory
which defines iterators that can hand out slice-and-lane-specific "views" of memory while ensuring no mutable aliasing occurs.This type can use dynamically checked borrow rules to avoid invalid accesses, e.g. if
j
were 2 and an immutable view of a segment in "slice" 2 were requested, this would cause an error. All of the borrows (i.e. the ones held by the "views") would have to be returned beforej
could be advanced, at which point a new "view" can be constructed per-lane for the next iteration ofj
.The text was updated successfully, but these errors were encountered: