什么是 Tink?
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
Tink 是由密码学家和
安全工程师Tink 安全而简单的 API 可减少常见
以用户为中心的设计、仔细的实现和代码审核,
和广泛的测试。请参阅本页中的目标部分,了解
以便更深入地了解 Tink 旨在实现哪些目标。
Tink 可帮助没有加密背景的用户安全地实现通用
加密任务。在 Google,数百款产品中部署了 Tink
和系统。
为什么要使用 Tink?
使用 Tink 的最重要的原因如下:
简单易用
加密很难正确。借助 Tink,
加密或对数据进行签名
内置的安全保障机制,只需几行代码即可。Tink 还可以
帮助您使用外部密钥管理系统轮替密钥或保护密钥
(KMS)
安全可靠
Tink 在 BoringSSL 等知名库的基础上增加了安全保护
Java 加密架构,并直接在接口中显示这些策略,
以便审核人员和工具快速找出不足之处。Tink 还会将 API
都可能存在危险,因此您可以对其进行监控。
兼容
Tink 密文与现有加密库兼容。廷克
还支持加密或存储密钥
Amazon KMS、Google Cloud KMS、Android 密钥库和 iOS 密钥链。
谁在使用 Tink?
Tink 被包括 Google、Square 和 Citadel 在内的许多公司广泛使用,
以及数百个 Google Cloud 客户和 Google Pay 合作伙伴。Tink 还
为 Jetpack Security 库提供支持,该库可为许多热门 Android 应用提供保护
如 Slack、Adidas、AirBnb 和 Nextdoor。
Tink 目标
与其他加密库相比,Tink 的主要目标是什么?
Tink 使用哪些主要机制来实现这些目标?
简而言之,Tink 有两个目标:
- 提升加密敏捷性:用户应该能够更改密钥并
算法。
- 启用安全审核:Tink 的目标是允许用户编写
可提供清楚明确、
安全性。
Tink 实现这些目标的主要机制如下:
- Tink 以重要的抽象形式提供基元和接口。这些
抽象允许用户编写
算法,而是指定预期的安全概念。
- Tink 使用“密钥集”的概念,
特定基元的关联。这会导致用户编写代码
它支持多个键
- 在 Tink 中,密钥不仅由底层密钥材料指定,
加密算法以及所有参数。这意味着
Tink 密钥始终会从所有可能的
函数,并且没有解释的空间。
以下部分更详细地介绍了这些概念。
加密敏捷性
不妨考虑 Google 的软件工程。
一本讲述了软件工程领域所学经验的书,
副标题“从编程中学到的教训”。在该视频中,作者在
并竭尽全力地暗示事情会发生变化的意义。本次
而且在很大程度上影响了 Tink 的设计。在加密中
为改变做好准备密钥将会泄露,算法将被破坏。
能够退出按键和算法对于许多用户来说至关重要,
都是谨慎的。
安全审核和本地房源
Tink 提倡使用我们的 AEAD 接口等接口,
来加密数据除了其他安全保证外,AEAD
可以保证对同一字符串进行多次加密时,
密码。
为了解具体使用方法,假设一名工程师想要存储一些敏感的
用户 Cookie 中的 ID。它们可能会提供一个如下所示的类:
class IdEncrypter {
public static IdEncrypter createFromAead(Aead aead);
public String encrypt(long id) throws GeneralSecurityException;
public long decrypt(String encrypted) throws GeneralSecurityException;
};
传递 Aead
会获取以下属性:
- 该代码会告知,
IdEncrypter
需要一个
具有 Aead
提供的安全属性的加密架构。
或者
DeterministicAead
IdEncrypter
要求对
相同 ID 就有所不同。另一方面,将
AES GCM 加密器(Aead
的一个特定实例)会过于
严格:任何 Aead 都足以让 IdEncrypter
完成其工作,
需要是一种特定的算法。
- 安全审核会将这一点考虑在内。安全审核人员执行的是
而不必检查整个代码库
在某个位置,有人创建了
Aead
的子类,这种做法不安全
和IdEncrypter
。相反,Tink 提供的安全属性
Aead 对象已指定,并且审查人员可以检查这些对象是否足够。
具体而言,第二点需要非常谨慎。用户经常请求添加
“不太符合”Aead
。上一点说明了
这种做法比较危险:如果存在任何可用的 Aead
实现,
没有提供必要的安全保证,IdEncrypter
可能会变得不安全,
执行安全审核的工程师需要检查其他代码
检查对象是否已正确实例化。
如未另行说明,那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可,并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情,请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-25。
[null,null,["最后更新时间 (UTC):2025-07-25。"],[[["\u003cp\u003eTink is an open-source cryptography library designed for easy and secure implementation of common cryptographic tasks, even for users without a cryptography background.\u003c/p\u003e\n"],["\u003cp\u003eTink prioritizes security by adding protections on top of existing libraries like BoringSSL, using distinct APIs for potentially risky operations, and ensuring ciphertext compatibility with other libraries.\u003c/p\u003e\n"],["\u003cp\u003eTink promotes cryptographic agility by enabling easy key and algorithm changes, and it supports integration with external key management systems like Amazon KMS and Google Cloud KMS.\u003c/p\u003e\n"],["\u003cp\u003eDesigned with security reviews in mind, Tink utilizes interfaces with clear security guarantees and the concept of keysets for enhanced security and code clarity.\u003c/p\u003e\n"],["\u003cp\u003eGoogle, Square, and Citadel are among the many companies that utilize Tink, further demonstrating its reliability and widespread adoption within various applications and systems.\u003c/p\u003e\n"]]],["Tink, a Google-developed open-source cryptography library, simplifies secure cryptographic implementation for users, even without cryptography expertise. It's designed for simplicity, security, and compatibility, supporting key rotation and external Key Management Systems (KMS). Tink prioritizes cryptographic agility, enabling easy key and algorithm changes, and facilitates security reviews by providing clear interfaces and security guarantees. It uses primitives, keysets, and comprehensive key specifications to achieve these goals, ensuring secure, verifiable, and adaptable cryptographic operations.\n"],null,["# What is Tink?\n\nTink is an open-source cryptography library written by cryptographers and\nsecurity engineers at Google. Tink's secure and simple APIs reduce common\npitfalls through user-centered design, careful implementation and code reviews,\nand extensive testing. See the [Goals](#tink_goals) section on this page for\nmore insight into which objectives Tink was designed to fulfil.\n\nTink helps users without a cryptography background safely implement common\ncryptographic tasks. At Google, Tink has been deployed in hundreds of products\nand systems.\n\nWhy should I use Tink?\n----------------------\n\nThe most important reasons to use Tink are:\n\n- **It's simple to use**\n\n Cryptography is difficult to get right. With Tink, you can\n [encrypt](/tink/encrypt-data) or [sign data](/tink/digitally-sign-data) with\n built-in security guarantees using just a few lines of code. Tink can also\n help you rotate keys or secure keys using external Key Management Systems\n (KMSs).\n- **It's secure**\n\n Tink adds security protections on top of well known libraries like BoringSSL\n and Java Cryptography Architecture and shows them right in the interfaces,\n so auditors and tools can quickly find gaps. Tink also separates APIs that\n are potentially dangerous, so you can monitor them.\n- **It's compatible**\n\n Tink ciphertexts are compatible with existing cryptography libraries. Tink\n also supports [encrypting or storing keys](/tink/client-side-encryption) in\n Amazon KMS, Google Cloud KMS, Android Keystore, and iOS Keychain.\n\nWho's using Tink?\n-----------------\n\nTink is widely used by many companies, including Google, Square, and Citadel, as\nwell as hundreds of Google Cloud customers and Google Pay partners. Tink also\npowers the Jetpack Security library, which secures many popular Android apps\nlike Slack, Adidas, AirBnb, and Nextdoor.\n\nTink Goals\n----------\n\nWhat are the main goals of Tink compared to other cryptographic libraries, and\nwhat are the main mechanisms which Tink uses to achieve these goals?\n\nIn short, Tink has two goals:\n\n1. *Promote cryptographic agility*: Users should be able to change keys and algorithms in a simple way.\n2. *Enable security reviews*: Tink aims to allow users to write code whose security can be reviewed locally, by providing interfaces which give clear security guarantees.\n\nThe main mechanisms Tink uses to achieve these goals are as follows:\n\n1. Tink provides primitives and interfaces as important abstractions. These abstractions allow users to write code which does not specify the exact algorithm to be used, but instead specifies the expected security notion.\n2. Tink uses the notion of a \"keyset\", which is a set of keys that are associated with a particular primitive. This results in users writing code which works with multiple keys.\n3. In Tink, keys are not only specified by the underlying key material, but also the cryptographic algorithm, as well as all parameters. This means that a Tink key always selects a unique cryptographic function from all possible functions which can exist, and leaves no room for interpretation.\n\nThe following sections explain these concepts in more detail.\n\n### Cryptographic agility\n\nConsider [Software Engineering at Google](https://abseil.io/resources/swe-book),\na book about lessons learned in the field of software engineering, with the\nsubtitle \"lessons learned from programming over time\". In it, the authors go to\ngreat lengths to implore the implications of the fact that things change. This\nfact also impacted much of the design of Tink. In cryptography, it is important\nthat one prepares for change. Keys will leak, and algorithms will be broken.\nBeing able to switch out keys and algorithms is crucial for many users, and\nbeing prepared is prudent.\n\n### Security reviews and local properties\n\nTink promotes the use of interfaces, such as our AEAD interface, which allows\nusers to encrypt data. Among [other security guarantees](https://developers.google.com/tink/aead#security_guarantees), an AEAD\nguarantees that multiple encryptions of the same string result in different\nciphertexts.\n\nTo see how this can be used, suppose an engineer wants to store some sensitive\nID in a user cookie. They might provide a class such as this: \n\n class IdEncrypter {\n public static IdEncrypter createFromAead(Aead aead);\n\n public String encrypt(long id) throws GeneralSecurityException;\n public long decrypt(String encrypted) throws GeneralSecurityException;\n };\n\nPassing an `Aead` obtains the following properties:\n\n1. The code communicates that for `IdEncrypter` to do its job, it requires an encryption scheme with the security properties an [`Aead` provides](https://developers.google.com/tink/aead#security_guarantees). Alternatively, a [`DeterministicAead`](https://developers.google.com/tink/deterministic-aead) wouldn't be enough -- the `IdEncrypter` requires that two encryptions of the same id are different. On the other hand, taking as parameter an instance of an AES GCM encrypter (one particular instance of an `Aead`) would be overly strict: any Aead is enough for `IdEncrypter` to do its job, and it does not need to be one specific algorithm.\n2. A security review can take this point into account. A security reviewer does not need to go through all of the entire code repository to check if somewhere, someone made a subclass of `Aead` which is not secure for use with `IdEncrypter`. Instead, Tink provides security properties which all Aead objects have, and the reviewer can check that these are sufficient.\n\nIn particular the second point requires a lot of care. Users often ask to add\nalgorithms which are 'not quite' an `Aead`. The previous point illustrates why\nthis is dangerous: if there is any implementation of `Aead` available which does\nnot provide the required security guarantees, `IdEncrypter` can become insecure,\nand the engineer performing a security review needs to examine additional code\nto check that the object is instantiated correctly."]]