O que é o Tink?
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
A Tink é uma biblioteca de criptografia de código aberto escrita por criptógrafos e
engenheiros de segurança do Google. As APIs simples e seguras da Tink reduzem os
armadilhas com design centrado no usuário, implementação cuidadosa e revisões de código,
e testes extensivos. Consulte a seção Metas nesta página para
mais informações sobre quais objetivos o Tink foi projetado para cumprir.
A Tink ajuda usuários sem experiência em criptografia a implementar com segurança
criptográficas. No Google, a Tink já está disponível em centenas de produtos
e sistemas.
Por que usar o Tink?
Os motivos mais importantes para usar o Tink são:
É simples de usar
A criptografia é difícil de acertar. Com o Tink, você pode:
criptografar ou assinar dados com
as garantias de segurança integradas usando apenas algumas linhas de código. A Tink também pode
ajudam a alternar chaves ou a proteger chaves usando sistemas de gerenciamento de chaves externos
(KMSs).
É seguro
O Tink adiciona proteções de segurança a bibliotecas conhecidas, como a BoringSSL
e a Arquitetura de criptografia Java e as mostra diretamente nas interfaces,
para que auditores e ferramentas possam
encontrar lacunas rapidamente. A Tink também separa as APIs que
são potencialmente perigosos, por isso você pode monitorá-los.
É compatível
Os textos criptografados do Tink são compatíveis com as bibliotecas de criptografia existentes. Tinta
também oferece suporte à criptografia ou armazenamento de chaves em
Amazon KMS, Google Cloud KMS, Android Keystore e iOS Keychain.
Quem está usando o Tink?
O Tink é amplamente usado por muitas empresas, como Google, Square e Citadel,
além de centenas de clientes do Google Cloud e parceiros do Google Pay. Tink também
alimenta a biblioteca Jetpack Security, que protege muitos apps Android conhecidos
como Slack, Adidas, AirBnb e Nextdoor.
Objetivos do Tink
Quais são os principais objetivos do Tink em comparação com outras bibliotecas criptográficas?
quais são os principais mecanismos que o Tink usa para atingir esses objetivos?
Em resumo, o Tink tem dois objetivos:
- Promover a agilidade criptográfica: os usuários devem ser capazes de alterar chaves e
algoritmos de maneira simples.
- Ativar revisões de segurança: o Tink tem como objetivo permitir que os usuários escrevam códigos com
a segurança pode ser revisada localmente, fornecendo interfaces que oferecem
garantias de segurança.
Os principais mecanismos que a Tink usa para atingir esses objetivos são os seguintes:
- O Tink fornece primitivos e interfaces como abstrações importantes. Esses
abstrações permitem que os usuários escrevam códigos que não especificam a
algoritmo a ser usado, mas especifica a noção de segurança esperada.
- O Tink usa a noção de um "conjunto de chaves", ou seja, um conjunto de chaves
associadas a um primitivo específico. Isso faz com que os usuários escrevam códigos
que funciona com várias chaves.
- No Tink, as chaves não são especificadas apenas pelo material da chave, mas
o algoritmo criptográfico e todos os parâmetros. Isso significa que
uma chave do Tink sempre seleciona uma função criptográfica exclusiva dentre todas as funções possíveis.
funções que podem existir e não deixa espaço para interpretação.
As seções a seguir explicam esses conceitos em mais detalhes.
Agilidade criptográfica
Considere a engenharia de software no Google,
um livro sobre as lições aprendidas no campo da engenharia de software, com a
subtítulo "lições aprendidas com a programação ao longo do tempo". Nele, os autores vão para
um grande esforço para implorar as implicações do fato de que as coisas mudam. Isso
também afetou muito o design do Tink. Na criptografia, é importante
que se prepara para a mudança. As chaves vazarão e os algoritmos serão quebrados.
A capacidade de alternar chaves e algoritmos é crucial para muitos usuários, e
estar preparado é prudente.
Avaliações de segurança e propriedades locais
O Tink promove o uso de interfaces, como a AEAD, que permite
que os usuários criptografem dados. Entre outras garantias de segurança, uma AEAD
garante que várias criptografias da mesma string resultem em diferentes
os textos criptografados.
Para ver como isso pode ser usado, imagine que um engenheiro quer armazenar
em um cookie do usuário. Eles podem fornecer uma classe como esta:
class IdEncrypter {
public static IdEncrypter createFromAead(Aead aead);
public String encrypt(long id) throws GeneralSecurityException;
public long decrypt(String encrypted) throws GeneralSecurityException;
};
A transmissão de um Aead
recebe as seguintes propriedades:
- O código comunica que, para
IdEncrypter
fazer o trabalho, é necessário um
com as propriedades de segurança que um Aead
fornece.
Como alternativa, uma
DeterministicAead
não seria suficiente. O IdEncrypter
exige que duas criptografias do
mesmo ID são diferentes. Por outro lado, tendo como parâmetro uma instância de
um criptografador GCM AES (uma instância específica de um Aead
) seria excessivamente
rigoroso: qualquer Aead é suficiente para que o IdEncrypter
faça o trabalho, e não
precisam ter um algoritmo específico.
- Uma análise de segurança pode considerar esse ponto. Um revisor de segurança
não precisará passar por todo o repositório de código para verificar se
em algum lugar, alguém criou uma subclasse de
Aead
que não é segura para uso.
com IdEncrypter
. Em vez disso, a Tink fornece propriedades de segurança que todas
Os objetos Aead têm, e o revisor pode verificar se eles são suficientes.
Em particular, o segundo ponto requer muito cuidado. Os usuários costumam pedir para adicionar
algoritmos que "não são bem" um Aead
. O ponto anterior ilustra por que
Isso é perigoso: se houver alguma implementação de Aead
disponível
não fornecer as garantias de segurança necessárias, o IdEncrypter
poderá se tornar inseguro,
e o engenheiro responsável pela análise de segurança precisa examinar código adicional
para verificar se o objeto está instanciado corretamente.
Exceto em caso de indicação contrária, o conteúdo desta página é licenciado de acordo com a Licença de atribuição 4.0 do Creative Commons, e as amostras de código são licenciadas de acordo com a Licença Apache 2.0. Para mais detalhes, consulte as políticas do site do Google Developers. Java é uma marca registrada da Oracle e/ou afiliadas.
Última atualização 2025-07-25 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-07-25 UTC."],[[["\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."]]