Thomas Holenstein

Results 72 comments of Thomas Holenstein

Instances of https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ThreadLocalRandom.html are not cryptographically secure (as it explains there). Tink already uses ThreadLocal random, but as explained in https://github.com/tink-crypto/tink-java/issues/24#issuecomment-1911639957 above this simply forwards to a global object and...

Thank you! I will keep reduce the priority of this, and keep it open though because AFAIK without Conscrypt Tink is still unacceptably slow.

The fact that Tink only supports 64 byte keys is intentional. See https://developers.google.com/tink/deterministic-aead#choose_a_key_type. However, we could create a separate configuration which supports 32 byte keys. The code would then look...

The question is whether this satisfies users. However, looking at the code it also doesn't seem right that https://cloud.google.com/sensitive-data-protection/docs/pseudonymization simply supports 32 byte keys (though I don't really understand the...

We currently don't plan to change this. Please comment if you need this, or maybe ping the team who is interested in this to contact us internally (I wouldn't know...

Thank you for filing this issue. The main fear we have is that we don't want to use a complicated parser on unverified data if we can avoid it. There...

Thanks for the report. There are several ways, in your particular case I would directly create the corresponding parameters object. ``` LegacyKmsEnvelopeAeadParameters parameters = LegacyKmsEnvelopeAeadParameters.builder() .setKekUri(reference.getKeyURI()) .setDekParsingStrategy( LegacyKmsEnvelopeAeadParameters.DekParsingStrategy.ASSUME_AES_GCM) .setDekParametersForNewKeys( AesGcmParameters.builder()...

Thank you. Yes, you understood me correctly. Indeed, we want to be careful with parsing unverified tokens. Parsing JSON can be tricky. However, we should be able to do something...

This is still something we would like to fix, but it turns out the internals make it more complicated than expected.

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...