google logo

Tink

Tink is a multi-language, cross-platform, open source library that provides cryptographic APIs that are secure, easy to use correctly, and hard(er) to misuse. (by google)

Stats

Basic Tink repo stats
0
11,241
9.7
3 days ago

google/tink is an open source project licensed under Apache License 2.0 which is an OSI approved license.

Tink Alternatives

Similar projects and alternatives to Tink based on common topics and language

  • GitHub repo boxcryptor-single-file-decryptor

    Open source code for basic Boxcryptor file decryption

  • GitHub repo Cryptomator

    Multi-platform transparent client-side encryption of your files in the cloud

  • GitHub repo aws-doc-sdk-examples

    Welcome to the AWS Code Examples Repository. This repo contains code examples used in the AWS documentation, AWS SDK Developer Guides, and more. For more information, see the Readme.rst file below.

  • GitHub repo Bouncy Castle

    Bouncy Castle Java Distribution (Mirror)

  • GitHub repo core

    JCrypTool Core Plug-ins (by jcryptool)

  • GitHub repo crypto

    JCrypTool Crypto Plug-ins (by jcryptool)

  • GitHub repo Graal

    GraalVM: Run Programs Faster Anywhere :rocket:

NOTE: The number of mentions on this list indicates mentions on common posts. Hence, a higher number means a better Tink alternative or higher similarity.

Posts

Posts where Tink has been mentioned. We have used some of these posts to build our list of alternatives and similar projects - the last one was on 2021-01-07.
  • Storing Sensitive Information in Django
    reddit.com/r/django | 2021-03-14
  • Building a Secure Signed JWT
    appears to be focused on cryptography and not token signing. Maybe more of a complement? I did see a section about digital signing: https://github.com/google/tink/blob/master/docs/PRIMITIVES.md#digital-signatures and don't see any reason you couldn't integrate tink to sign JWTs.
  • Independent Audit: Insights into the Source Code of Boxcryptor
    news.ycombinator.com | 2021-01-07
    4. Output AES-CBC-DECRYPT(KE, IV, C) with PKCS#5 padding.

    The core of the problem is that, while they use the HMAC to check that the ciphertext is authentic (which is a bit odd, given that they seem to claim that authenticity shouldn't matter), they never check that the IV is authentic (it's never computed in the HMAC).

    The way that AES-CBC decryption works, for first 16-bytes of the decryption is AES-BLOCK-DECRYPT(KE, first 16 bytes of C) XOR IV. As a result, if the IV isn't authenticated (which it's not), then any bit that the attacker flips in the IV will flip the corresponding bit in the ciphertext. Because PKCS#5 padding is used, given a padding oracle, an adversary could decrypt messages under 16 bytes in length.

    The moral of the story is DO NOT ROLL YOUR OWN CRYPTO! Rolling your own crypto can be fun and educational and informative, but DON'T DEPLOY IT!

    This bug should not have arisen, because the GitHub link in this blog post should've been to https://github.com/google/tink or https://github.com/jedisct1/libsodium or some library like them.