-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
x/crypto/{blake2b,blake2s}: implement encoding.BinaryMarshaler and encoding.BinaryUnmarshaler #24548
Comments
Change https://golang.org/cl/102617 mentions this issue: |
I don't think adding a custom
BTW: adding a function to @ValarDragon Have you considered using a XOF - like BLAKE2X /cc @FiloSottile |
Thanks for explaining the situation with I agree, adding a custom clone method to every hash is not a good solution. For the HMAC situation, I'm not really sure thats a problem, except for the reset situation as you mentioned. But in principle if you want to re-use the state right after its keyed, you would marshal at that point, and keep on unmarshalling that for the copy of the state. For the reset situation, you're right it is confusing what to do there. I suppose it is an arbitrary decision, so the best option may be to use nil as the key. (Since there is no error return value) |
I think for now it would be ok to make |
I started an implementation for this, but I was wondering what I should do for test cases. The other hash functions (sha512, sha256, md5) have a TestGolden method, where they test the hash function with a known set of strings. There is no test golden method for blake2b. Should I make the same test golden method here, or is there another preferred way for testing this? The known test cases for blake2b are taken from here, but these were all produced with a key, which means that we would have to enable marshalling for keyed digests to use those test cases. I'm planning on serializing offset as uint32, and size as uint8. Offset seems to always be positive, and size never exceeds the number 64, so it can fit into 1 byte. |
Hm - you could follow the same approach but instead of 2 instances of the hash function and a set of precomputed hashes you can use 3 hash instances and use the 3-th as reference.
|
Change https://golang.org/cl/103241 mentions this issue: |
The marshal method allows the hash's internal state to be serialized and unmarshaled at a later time, without having the re-write the entire stream of data that was already written to the hash. Fixes golang/go#24548 Change-Id: I82358c34181fc815f85d5d1509fb2fe0e62e40bd Reviewed-on: https://go-review.googlesource.com/103241 Reviewed-by: Filippo Valsorda <filippo@golang.org> Run-TryBot: Filippo Valsorda <filippo@golang.org>
The marshal method allows the hash's internal state to be serialized and unmarshaled at a later time, without having the re-write the entire stream of data that was already written to the hash. Fixes golang/go#24548 Change-Id: I82358c34181fc815f85d5d1509fb2fe0e62e40bd Reviewed-on: https://go-review.googlesource.com/103241 Reviewed-by: Filippo Valsorda <filippo@golang.org> Run-TryBot: Filippo Valsorda <filippo@golang.org>
The marshal method allows the hash's internal state to be serialized and unmarshaled at a later time, without having the re-write the entire stream of data that was already written to the hash. Fixes golang/go#24548 Change-Id: I82358c34181fc815f85d5d1509fb2fe0e62e40bd Reviewed-on: https://go-review.googlesource.com/103241 Reviewed-by: Filippo Valsorda <filippo@golang.org> Run-TryBot: Filippo Valsorda <filippo@golang.org>
The marshal method allows the hash's internal state to be serialized and unmarshaled at a later time, without having the re-write the entire stream of data that was already written to the hash. Fixes golang/go#24548 Change-Id: I82358c34181fc815f85d5d1509fb2fe0e62e40bd Reviewed-on: https://go-review.googlesource.com/103241 Reviewed-by: Filippo Valsorda <filippo@golang.org> Run-TryBot: Filippo Valsorda <filippo@golang.org>
The marshal method allows the hash's internal state to be serialized and unmarshaled at a later time, without having the re-write the entire stream of data that was already written to the hash. Fixes golang/go#24548 Change-Id: I82358c34181fc815f85d5d1509fb2fe0e62e40bd Reviewed-on: https://go-review.googlesource.com/103241 Reviewed-by: Filippo Valsorda <filippo@golang.org> Run-TryBot: Filippo Valsorda <filippo@golang.org>
The marshal method allows the hash's internal state to be serialized and unmarshaled at a later time, without having the re-write the entire stream of data that was already written to the hash. Fixes golang/go#24548 Change-Id: I82358c34181fc815f85d5d1509fb2fe0e62e40bd Reviewed-on: https://go-review.googlesource.com/103241 Reviewed-by: Filippo Valsorda <filippo@golang.org> Run-TryBot: Filippo Valsorda <filippo@golang.org>
The marshal method allows the hash's internal state to be serialized and unmarshaled at a later time, without having the re-write the entire stream of data that was already written to the hash. Fixes golang/go#24548 Change-Id: I82358c34181fc815f85d5d1509fb2fe0e62e40bd Reviewed-on: https://go-review.googlesource.com/103241 Reviewed-by: Filippo Valsorda <filippo@golang.org> Run-TryBot: Filippo Valsorda <filippo@golang.org>
It is often useful to be able to copy the internal state for blake2b, such as if you want to compute
Blake2b(msg || tag1)
andBlake2b(msg || tag2)
, and you want to avoid double-computing what results from updatingmsg
.I've added a clone method to do this here. This is an improvement that can't be made in applications using the library, since the digest struct isn't exported.
Since the publicly visible interface for digest is hash.Hash, I made the method for cloning
func Clone(h hash.Hash) (*digest, error)
instead offunc (d *digest) Clone (*digest)
.This could alternatively be added as a method that everything which implements the hash.Hash interface must implement, since there have been requests for this before. (Link 1, Link 2)
The text was updated successfully, but these errors were encountered: