-
Notifications
You must be signed in to change notification settings - Fork 258
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
Next iteration of Digest traits #20
Comments
@burdges
|
I have not read the Grøstl paper but the abstract says "Grøstl is a so-called wide-pipe construction where the size of the internal state is significantly larger than the size of the output." Do you want run-time variable output so that Grøstl could be used instead of Keccek's SHAKE mode? If so, you'll want dynamic allocation for that, and your Rust does not support dynamic stack allocation currently, but support for DSTs should improve via alloca, unsized rvalues, or dependent types. Right now, there is only minimal discussion about supporting DSTs that contain multiple DSTs inside though. If the language designers do not go for super-fat pointers then we might wind up with arena based schemes roughly like :
so |
Groestl can't operate as XOF, because size of the output influences IV, thus output length must be known at digest initialization. (see section 3.5 of the paper) As I stated in the reddit discussion I am thinking about writing trait VariableOutput<'a>: Sized {
fn new(buf: &'a mut [u8]) -> Result<Self, InvalidLength>;
fn variable_result(self) -> &'a [u8];
} Here length of the It's not ideal as requirement to pass buffer could be unnecessary restrictive for some hashes. (e.g. BLAKE2 defines "variable" output as a simple truncation) But I think it will be better compared to creation of yet another trait. Regarding alloca there is concerns about performance issues of using dynamically sized structs on the stack, so I think it will be better to stick with the buffer approach. |
Rust language team expects "const generics available on nightly by the end of 2017". In my opinion, library interfaces that expose generic array crate should therefore be slated for deprecation in 2018, after const generics reach stability. I'd hoped they might stabilize For now, I'd suggest creating a trait that covers the desired fixed length array types, but which you can deprecate without fear of breaking anything :
The benefit is that code that does not need to be polymorphic on array length can use these hash functions without breaking in future. |
@burdges |
I mentioned this here mostly because if you were going to redesign digest in a big way soon anyways, then you could maybe future proof it, but no reason to rush anything. :) |
The new const generics RFC looks worth watching : rust-lang/rfcs#2000 |
@burdges |
I've updated crates to |
I'm thrilled to see |
Sacundim in his feedback on the reddit proposed to use instead of
VariableOutput
the following traits:ExtendableOutput
for functions like SHAKE from SHA-3, which allow to "read" indefinitely from the resultVariableOutput
for functions likeGroestl
, which have some limits on the output size and may require output size to be known at state initalizationAlso @burdges proposed to move out
BlockSize
from theInput
trait to a separate one.The text was updated successfully, but these errors were encountered: