-
Notifications
You must be signed in to change notification settings - Fork 52
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
Implement DARE 2.0 #20
Conversation
This change moves the platform specific code for AES hardware support detection to a separate internal package.
This change refactors the v1.0 implementation by separating the Sealing/Opening functionallity from the reading/writing. This makes reasoning about / reviewing the code simpler.
This change adds a DARE 2.0 implementation for en/decrypting
io.Reader and io.Writer. Further it adds a generic decrypted
reader/writer to handle 1.0/2.0 compatability.
The default for encrypting io.Reader/io.Writer is DARE 2.0
The default for decrypting io.Reader/io.Writer is DARE 1.0 and 2.0. (backward compatible)
This change also separates the DARE implementations from the io.Reader/io.Writer
implementations to make reasoning about the code easier. As part of this separation
this change adds new test vectors for DARE 1.0 and 2.0.
Fixes #16
Will test this today @aead with the new encryption support in server. Is there anything specific that needs to be done or should this be just a drop in replacement? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few questions i have are this
- Should we still allow users to specify the version such that they can use Dare 1.0 ? if yes then why? - IMO we shouldn't allow them to create encrypted streams with 1.0 anymore.
- Can more comments be added in decrypter/reader implementation, helps in the review process.
Nothing to do - it's full backward compatible and can be used as drop-in replacement. |
This would be not strictly backward compatible. First DARE 2.0 will be automatically selected except the user specifies:
Yes, I will add some comments. |
@aead Where is the spec for 2.0? It does not seem to be present in the DARE.md file in the 2.0 branch. |
This change adds comments to the io.Reader/io.Writer implementations to make understanding the code easier.
This commit changes the expected key size (256 bits) from a code literal to a constant.
@donatello Yes, the spec is not finalized yet (it's missing some performance numbers a.s.o) |
No basically my point was on encryption we will disallow 1.0 but for decryption we allow. |
Yes, but imagine code using a config like: |
We should disallow in my opinion and there is no need to override. Since decryption is backward compatible it shouldn't be a big problem. |
@abperiasamy suggested that we can be bit lenient here since |
This change adds a check to detected whether Seal/SealFinal is called after a SealFinal call happened.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This change adds a DARE 2.0 implementation for en/decrypting io.Reader and io.Writer. Further it adds a generic decrypted reader/writer to handle 1.0/2.0 compatibility.
This change also separates the DARE implementations from the io.Reader/io.Writer
implementations to make reasoning about the code easier. As part of this separation
this change adds new test vectors for DARE 1.0 and 2.0.
Fixes #16