1# Tink's Security and Usability Design Goals 2 3The work on Tink is guided by the design goals discussed below. To get a quick 4overview of Tink design you can also take a look at 5[slides](Tink-a_cryptographic_library--RealWorldCrypto2019.pdf) from [a talk 6about Tink](https://www.youtube.com/watch?v=pqev9r3rUJs&t=9665) presented at 7[Real World Crypto 2019](https://rwc.iacr.org/2019/). 8 9* **Security** Tink is built on top of existing libraries such as BoringSSL 10 and Java Cryptography Architecture, but includes countermeasures to many 11 weaknesses in these libraries, which were discovered by Project Wycheproof, 12 another project from our team. 13 14* **Easiness** Most crypto operations such as data encryption, digital 15 signatures, etc. can be done with only a few lines of code. Tink's 16 interfaces abstract away from the underlying implementations. Interfaces are 17 usable without knowing the underlying class that implements it. 18 19* **Hard-to-misuse** Tink aims to eliminate as many potential misuses as 20 possible. For example, if the underlying encryption mode requires nonces and 21 is insecure if nonces are reused, then Tink does not allow the passing of 22 nonces by the user. Interfaces have security guarantees that must be 23 satisfied by each primitive implementing the interface. This may exclude 24 some encryption modes. Rather than adding them to existing interfaces and 25 weakening the guarantees of the interface it is possible to add new 26 interfaces and describe the security guarantees appropriately. 27 28* **Readability** Tink shows the security guarantees (e.g., safe against 29 chosen-ciphertext attacks) right in the interfaces, allowing security 30 auditors and automated tools to quickly discover usages where the security 31 guarantees don’t match the security requirements. Tink also separates APIs 32 for potential dangerous operations (e.g., loading cleartext keys from disk), 33 allowing discovering, restricting, monitoring and logging their usages. 34 35* **Extensibility** Tink makes it easy to support new primitives, new 36 algorithms, new ciphertext formats, new key management systems, etc. 37 38* **Agility** Tink provides built-in crypto agility. It supports key rotation, 39 deprecation of obsolete schemes and adaptation of new ones. For example, if 40 an implementation of a crypto primitive is found broken, you can switch to a 41 different implementation by rotating keys, without changing or recompiling 42 code. 43 44* **Interoperability** Tink produces and consumes ciphertexts that are 45 compatible with existing crypto libraries. Tink supports encrypting or 46 storing keys in Amazon KMS, Google Cloud KMS, Android Keystore, iOS 47 Keychain, and it is easy to add support for custom key management systems. 48 49* **Versatility** No part of Tink is hard to replace or remove. All components 50 are recombinant, and can be selected and assembled in various combinations. 51 For example, if you need only digital signatures, you can exclude symmetric 52 key encryption components. 53