Validate AesSiv parameters in AesSivKeyManager the same way the AesSivParameters

[dinigo]

This enables keys of lengths 32 and 48 bytes to be used

see https://github.com/tink-crypto/tink-java/issues/32

[dinigo]

Hello. Do you have documentation on how to run the tests? bazel test tink doesn't find them

ERROR: No test targets were found, yet testing was requested

I'd like to add a test on keys length 32 and 48 bytes. I have it working and it is consistent with other libraries implementations. But It's hard to progress without properly setting up the project.

[morambro]

HI @dinigo still haven't looked at this patch. For testing you can do (I recommend using Bazelisk https://github.com/bazelbuild/bazelisk):

cd path/to/tink_java
# Run all the tests; will cache results if files are unchanged.
bazelisk test ...
# Limited to daead:
bazelisk test //src/test/java/com/google/crypto/tink/daead/...
# Or even:
bazelisk test //src/test/java/com/google/crypto/tink/daead:AesSivKeyManagerTest

[tholenst]

Can you add some context why you want this? Current behavior is on purpose (see e.g. https://github.com/tink-crypto/tink-cross-lang-tests/blob/main/cross_language/cross_language/daead/aes_siv_keys.py#L38-L39 where we explicitly test that these keys fail)

Edit: please add the context to the issue you filed -- sorry for commenting here. I didn't see the issue at first.

[dinigo]

@tholenst . Currently Google Cloud DLP "states" in their documentation their service is using AES-SIV for deterministic encryption.

However, they only support keys as long as 32 bytes.

• I need to encrypt-decrypt consistently with this Google service in an air-gapped system where we cannot access the API/Service.
• I need the ability to bulk decrypt big amounts of information without relying on the DLP service small throughput.
• I see AES-SIV RFC5297 does not support this key length (apparently)
• Google Cloud support asked explicitly to raise it here.

I see there's no point on supporting 128 bit keys since it doesn't align with the RFC

[tholenst]

Thanks for the context. The fact that Tink out of the box only supports 64 bytes is intentional. See https://developers.google.com/tink/deterministic-aead#choose_a_key_type.

I will however comment on https://github.com/tink-crypto/tink-java/issues/32 with a way forward.