Google Tink 混合参数
Google Tink Hybrid params
Google Tink 支持“混合加密”——一种使用非对称密钥加密对称密钥、使用对称密钥加密明文并将两个密文捆绑为一条消息的便捷方法。
不过,貌似基本支持两组参数组合:
EciesAeadHkdfPrivateKeyManager.eciesP256HkdfHmacSha256Aes128GcmTemplate();
EciesAeadHkdfPrivateKeyManager.eciesP256HkdfHmacSha256Aes128CtrHmacSha256Template();
在内部,这些映射到例如
public static final KeyTemplate eciesP256HkdfHmacSha256Aes128GcmTemplate() {
return createKeyTemplate(
EllipticCurveType.NIST_P256,
HashType.SHA256,
EcPointFormat.UNCOMPRESSED,
AesGcmKeyManager.aes128GcmTemplate(),
KeyTemplate.OutputPrefixType.TINK,
EMPTY_SALT);
}
交换似乎相当简单,例如AesGcmKeyManager.aes128GcmTemplate()
对于 AesGcmKeyManager.aes256GcmTemplate()
,除了 createKeyTemplate
是私有的,并且使用包私有方法,并且 EciesAeadHkdfPrivateKeyManager
是最终的,总的来说它似乎正在走出去防止我们弄乱这些参数。这是有原因的吗?我是否应该根据从 Tink 源 and/or 中搜集的代码重构我自己的修改版本,只是使用反射来绕过 private
,还是存在隐藏的非正交性来绊倒我并使结果不安全?
创建者将“难以滥用”作为设计目标,特别是接口的“安全保证”理念。 (https://github.com/google/tink/blob/master/docs/SECURITY-USABILITY.md)
"For example, if the underlying encryption mode requires nonces and is insecure if nonces are reused, then Tink does not allow the passing of nonces by the user."
我知道这在这种情况下是如何应用的,但是 是 一个已弃用的 class (com.google.crypto.tink.hybrid.HybridKeyTemplates
) 可以满足您的描述。它有一个 public 方法 createEciesAeadHkdfKeyTemplate
接受所有内部参数 (https://github.com/google/tink/blob/master/java_src/src/main/java/com/google/crypto/tink/hybrid/HybridKeyTemplates.java#L127)
Google Tink 支持“混合加密”——一种使用非对称密钥加密对称密钥、使用对称密钥加密明文并将两个密文捆绑为一条消息的便捷方法。
不过,貌似基本支持两组参数组合:
EciesAeadHkdfPrivateKeyManager.eciesP256HkdfHmacSha256Aes128GcmTemplate();
EciesAeadHkdfPrivateKeyManager.eciesP256HkdfHmacSha256Aes128CtrHmacSha256Template();
在内部,这些映射到例如
public static final KeyTemplate eciesP256HkdfHmacSha256Aes128GcmTemplate() {
return createKeyTemplate(
EllipticCurveType.NIST_P256,
HashType.SHA256,
EcPointFormat.UNCOMPRESSED,
AesGcmKeyManager.aes128GcmTemplate(),
KeyTemplate.OutputPrefixType.TINK,
EMPTY_SALT);
}
交换似乎相当简单,例如AesGcmKeyManager.aes128GcmTemplate()
对于 AesGcmKeyManager.aes256GcmTemplate()
,除了 createKeyTemplate
是私有的,并且使用包私有方法,并且 EciesAeadHkdfPrivateKeyManager
是最终的,总的来说它似乎正在走出去防止我们弄乱这些参数。这是有原因的吗?我是否应该根据从 Tink 源 and/or 中搜集的代码重构我自己的修改版本,只是使用反射来绕过 private
,还是存在隐藏的非正交性来绊倒我并使结果不安全?
创建者将“难以滥用”作为设计目标,特别是接口的“安全保证”理念。 (https://github.com/google/tink/blob/master/docs/SECURITY-USABILITY.md)
"For example, if the underlying encryption mode requires nonces and is insecure if nonces are reused, then Tink does not allow the passing of nonces by the user."
我知道这在这种情况下是如何应用的,但是 是 一个已弃用的 class (com.google.crypto.tink.hybrid.HybridKeyTemplates
) 可以满足您的描述。它有一个 public 方法 createEciesAeadHkdfKeyTemplate
接受所有内部参数 (https://github.com/google/tink/blob/master/java_src/src/main/java/com/google/crypto/tink/hybrid/HybridKeyTemplates.java#L127)