Skip to content

Zero byte operations #239

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

Merged
merged 7 commits into from
Mar 27, 2020
Merged

Zero byte operations #239

merged 7 commits into from
Mar 27, 2020

Conversation

seebees
Copy link
Contributor

@seebees seebees commented Jan 9, 2020

Resolves #237

Several changes bundled together:

  • Change the references to CryptoKey to AwsEsdkJsCryptoKey
  • Raw AES Keyring master keys were not correctly using the non-zero backend
  • The WebCrypto decrypt API combines the data and tag together, so zero bytes of data is not exactly zero.
  • Small, remove redundant check to 'algorithm'
  • For MSRCrypto update the algorithm argument for importKey

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Check any applicable:

  • Were any files moved? Moving files changes their URL, which breaks all hyperlinks to the files.

seebees added 7 commits March 24, 2020 13:13
Regarding aws#237, the shape of the CryptoKey
when dealing with a fallback may slightly differ.
By changing all references to AwsEsdkJsCryptoKey
I can control any type mismatch.
There are two sublte things going on here.

First, in the case of a mixed backend,
the non-zero backend should be the native implementation.
I assert that it should be slightly harder to exfiltrate
from the native implementation than a JS implementation.

Second, if I force the import of the master key into only half of the mixed backend,
then `getSubtleFunction` will complain about a mismatch.
Because the crypto key and the backend are not both mixed.

To resolve this the backend for the raw AES master key is issolated here.
See: aws#237

Since the WebCrypto decrypt API expects the AES-GCM tag with the encrypted data,
zero bytes of encrypted data is not zero bytes of data.

fix: Add tests

Add tests to specificly cover the Mixed Backend conditions
and logic.
The suite did not have a KDF,
so this value was `undefined` which should never happen in practice.
Tests should match expected situations.
Since MSRCrypto is a viable option for a falback,
it must be usable.

These differ from the WebCrypto API
* The algorithm argument in importKey is passed through to the imported key.
* The algorithm is normalize to lower case

microsoft/MSR-JavaScript-Crypto#1
Adding an example of useing a fallback.
This example uses MSRCrypto version 1.6.0.
@seebees seebees force-pushed the zero_byte_operations branch from 80dfd38 to 6e23c2d Compare March 26, 2020 19:31
@seebees seebees merged commit 2758a1a into aws:master Mar 27, 2020
@seebees seebees deleted the zero_byte_operations branch March 27, 2020 20:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Raw aes keyrings in a browse not processing zero byte AES-GCM operations.
3 participants