-
Notifications
You must be signed in to change notification settings - Fork 19
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
fix: Trade AssumeValidAAD for run-time checks and proofs #203
Conversation
DefaultCMM.GetEncryptionMaterials is given a valid encryption context, to which it may append the mapping `[reservedField := enc_vk]`. This would invalidate the encryption context if * `reservedField` is not UTF8 or is too long (but we know it's fine, because it's a constant) * `enc_vk` is not UTF8 or is too long after it has been Base64 encoded (but we know it's fine, because of the new and tested postcondition of `Signature.KeyGen`, and because of some new specifications and lemmas regarding `Base64.Encode`) * the updated encryption context exceeds the maximum number of allowed mappings (this is now run-time checked) * the updated encryption context contains too many bytes altogether (this is now run-time checked, which involves walking over all the entries in the encryption context--possibly expensive) Fixes #79
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
src/Crypto/Signature.dfy
Outdated
} | ||
|
||
method {:extern "Signature.ECDSA", "KeyGen"} KeyGen(s : ECDSAParams) returns (res: Result<SignatureKeyPair>) | ||
method {:extern "Signature.ECDSA", "KeyGen"} KeyGen(s: ECDSAParams) returns (res: Result<SignatureKeyPair>) |
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.
I would be more comfortable if this was a runtime check.
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.
+1
} | ||
|
||
MessageHeader.AssumeValidAAD(enc_ctx); // TODO: we should check this (https://github.com/awslabs/aws-encryption-sdk-dafny/issues/79) |
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.
Can we also remove AssumeValidAAD
in MessageHeader? I think we might be also using this as a shortcut in tests, if that's the case, could we move AssumeValidAAD
into TestUtils? If you think that's out of scope for this PR, we should at least cut a new issue to do that work so that we can avoid this assumes creeping into other areas.
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.
Good call. I'll fix it.
src/Crypto/Signature.dfy
Outdated
} | ||
|
||
method {:extern "Signature.ECDSA", "KeyGen"} KeyGen(s : ECDSAParams) returns (res: Result<SignatureKeyPair>) | ||
method {:extern "Signature.ECDSA", "KeyGen"} KeyGen(s: ECDSAParams) returns (res: Result<SignatureKeyPair>) |
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.
+1
@@ -13,9 +13,18 @@ module {:extern "Signature"} Signature { | |||
case ECDSA_P256 => 71 | |||
case ECDSA_P384 => 103 | |||
} | |||
|
|||
function method FieldSize(): nat { |
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.
Hardcoding the field size directly instead of using our crypto primitives to get this value seems like a sharp edge. On the other hand, I'm not sure how else we would go about using this value as part of our specs. I'd like to think this one over on whether there is another approach to this.
The previous uses of AssumeValidAAD in test/SDK/Serialize.dfy have now been replaced by proofs, found in test/Util/TestUtils.dfy.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
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!
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
var sigKeyPair :- ExternKeyGen(s); | ||
if |sigKeyPair.verificationKey| == s.FieldSize() { | ||
return Success(sigKeyPair); | ||
} else { | ||
return Failure("Incorrect verification-key length from ExternKeyGen."); | ||
} |
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.
I know we started following this pattern in a recent PR and I really like this. 👍
@@ -367,12 +367,12 @@ module Base64 { | |||
if IsBase64String(s) then Success(DecodeValid(s)) else Failure("The encoding is malformed") | |||
} | |||
|
|||
predicate StringIs8Bit(s: string) { | |||
forall i :: 0 <= i < |s| ==> s[i] < 256 as char | |||
predicate StringIs7Bit(s: string) { |
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.
Can we get a bit more info on why this is the case.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Description of changes:
DefaultCMM.GetEncryptionMaterials is given a valid encryption context, to which it may append
the mapping
[reservedField := enc_vk]
. This would invalidate the encryption context ifreservedField
is not UTF8 or is too long (but we know it's fine, because it's a constant)enc_vk
is not UTF8 or is too long after it has been Base64 encoded (but we know it's fine, because of the new andtested postcondition of
Signature.KeyGen
, and because of some new specifications and lemmas regardingBase64.Encode
)the updated encryption context exceeds the maximum number of allowed mappings (this is now run-time checked)
the updated encryption context contains too many bytes altogether (this is now run-time checked, which involves
walking over all the entries in the encryption context--possibly expensive)
Fixes #79
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.