Die Bibliothek Tink für Multiplattform-Kryptografie

Sicher von Anfang an

Seit JDK 1.4 ist die Java Cryptografy Extension (JCE) Teil von Java. Über die Java Cryptografy Architecture (JCA) werden durch Kryptografie-Provider verschiedene kryptografische Konzepte implementiert. Als Funktionalitäten bietet die JCE an: Chiffren-Sammlungen zum Verschlüsseln (symmetrisch und asymmetrisch), Block- und Stream-Chiffren, Schlüsselmanagement für die Schlüsselgenerierung und Aushandeln von Schlüsseln, Message-Authentication-Codes zur Berechnung von Authentifizierungen für Kommunikationen, sichere Objekte und digitale Signaturen. Neben Bouncy Castle [CRaC] ist für Linux der Amazon Corretto Crypto Provider (ACCP) beliebt.

Um die Performance für wichtige Advanced Encryption Standards (AES) zu verbessern, wird mit JEP 164 [JEP164] die AES-Befehlssatzerweiterung des x86-Befehlssatzes von Intel- und AMD-Prozessoren beim Kompilieren unterstützt. Gleiches gilt für die RSA-Verschlüsselungen und GHASH-Hashing mit dem JEP 246 [JEP246] für x64-Befehlssatzerweiterungen für kryptografische Tokens.

Eine gute Zusammenfassung der Security-Updates von Java 9 bis 21 findet sich im Security-Kapitel des Oracle JDK Migration Guide [MIGSEC]. Was in Zukunft geplant ist, findet man in den Java Enhancement Proposals (JEP) oder in der Oracle JRE and JDK Cryptographic Roadmap [JAVACRYPTROAD]. Mit Java 21 [SDG21] wird der im JEP 452 [JEP452] spezifizierte Key Encapsulation Mechanism (KEM) umgesetzt. Als Algorithmen werden der RSA Key Encapsulation Mechanism (RSA-KEM) und das Elliptic Curve Integrated Encryption Scheme (ECIES) unterstützt.

Abb.1: Java-Sicherheitsbibliotheken (JAVASEC)

Bisher verschlüsselte der Sender die Nachricht mit seinem privaten Schlüssel und der Empfänger entschlüsselte die Nachricht mit dem öffentlich verfügbaren Schlüssel. Bei diesem asymmetrischen Public-Key-Verschlüsselungsverfahren (z. B. beim RSA oder Elliptischen Kurven) muss der private Schlüssel geheim gehalten werden, der öffentliche Schlüssel aber jedem zugänglich sein, der eine verschlüsselte Nachricht an den Besitzer des privaten Schlüssels senden will. Dabei muss sichergestellt sein, dass der öffentliche Schlüssel auch wirklich dem Empfänger zugeordnet ist. Oft wird dazu das Diffie-Hellman-Verfahren [HOWSHARE] für den Schlüsselaustausch eingesetzt.

Asymmetrische Verschlüsselungsverfahren haben den Vorteil, dass sie das Geheimnis (Alices öffentlicher Schlüssel in Abb. 2) möglichst klein halten.

Abb.2: Asymmetrische Verschlüsselungen mit öffentlichem Schlüssel und Entschlüsseln mit privatem Schlüssel

Im Gegensatz dazu muss bei einem symmetrischen Kryptosystem jeder Benutzer alle Schlüssel geheim halten, was einen mit höherer Benutzerzahl steigenden Aufwand bedeutet. Im Vergleich zu symmetrischen Algorithmen arbeiten die asymmetrischen Algorithmen sehr langsam, weshalb oft hybride Verfahren eingesetzt werden.

Abbildung 3 zeigt, wie ein Schlüsselgenerator mit dem Diffie-Hellman-Algorithmus [JAVASECNAME] öffentliche und private Schlüssel erstellt.

Abb. 3: Schlüsselgenerator mit dem Diffie-Hellman-Algorithmus in Java

Der Code dazu für eine Umschlagsverschlüsselung (KEM) ist im Listing auf [JAVAKEM, JAVAJCA] dargestellt.

m ,Den dazugehörigen Java-Code zum Verpacken der Sendernachricht mit dem öffentlichen Schlüssel und dem Entpacken mit dem privaten Schlüssel des Empfängers zeigt Listing 1.

// Receiver side
var kpg = KeyPairGenerator.getInstance("X25519");
var kp = kpg.generateKeyPair();
// Sender side
var kem1 = KEM.getInstance("DHKEM");
var sender = kem1.newEncapsulator(kp.getPublic());
var encapsulated = sender.encapsulate();
var k1 = encapsulated.key();
// Receiver side
var kem2 = KEM.getInstance("DHKEM");
var receiver = kem2.newDecapsulator(kp.getPrivate());
var k2 = receiver.decapsulate(encapsulated.encapsulation());
// Function works
assert Arrays.equals(k1.getEncoded(), k2.getEncoded());

Das Public-Key-Encryption-Schema (PKE), wie es beim Diffie-Hellman-Schlüsselaustausch aus den späten 70ern verwendet wird, ist im Post-Quanten- und Cloud-Zeitalter bedroht. Hier kommt das Schlüsselkapselverfahren (KEM) zum Einsatz. Im Unterschied zu einer Schlüsselvereinbarung wie beim Diffie-Hellman-Schlüsselaustausch hat die spätere Aufdeckung des Hauptschlüssels beim Schlüsselkapselverfahren keine Folgen. Da der Sitzungsschlüssel, der aus dem öffentlichen Schlüssel des Empfängers mit einem Verkapselungsalgorithmus und einem über einen ungeschützten Kanal übermittelten weiteren Schlüssel erzeugt wurde, kann der Sender mit dem Entkapselungsalgorithmus und seinem privaten Schlüssel ebenfalls den geheimen Sitzungsschlüssel erzeugen. Für eine zusätzliche Sicherheit kann dieser Sitzungsschlüssel noch signiert werden, um sicherzustellen, dass dieser nicht verändert wurde. Anstatt seinen kryptografischen Schlüssel über das unsichere Internet zu schicken, kann man dazu einen weiteren Kanal, wie E-Mail oder SMS, verwenden. Ein ähnliches Verfahren hat sich inzwischen für den Identitätsnachweis mit der Zwei-Faktor-Authentisierung (2FA) als Standard durchgesetzt.

Für die von NIST bereits ausgewählten Post-Quanten-Kryptografie-Algorithmen (PQC), wie (asymmetrische Verschlüsselung), Dilithium (digitale Signatur) und SPHINCS+ (kryptografische Hashfunktion), bietet aktuell für Java nur Bouncy Castle 1.77 Unterstützung an. Erst vor Kurzem hat Apple dieses Verfahren mit seinem PQ3-Protokoll in iOS 17.4 für seine iMessenges implementiert. Die KEM API besteht aus drei Funktionen: Eine erzeugt das Schlüsselpaar, eine kapselt den Schlüssel und die dritte entkapselt diesen wieder.

Beliebt ist bei den Cloud-Anbietern eine Umschlagsverschlüsselung [AWSDEK, GCPDEK]. Damit wird der Datenschlüssel erzeugt, indem der Master-Schlüssel mit einem weiteren Schlüssel verschlüsselt wird. So wird verhindert, dass der Datenschlüssel (DEK) im Klartext übertragen wird und direkt verwendet werden kann. Der Master-Schlüssel (key encryption key, KEK) liegt extra abgesichert in einem Schlüsselmanagement-Dienst. Der Datenschlüssel kann deswegen ohne Risiko direkt bei den mit ihm verschlüsselten Daten abgelegt werden (s. Abb. 4).

Abb. 4: Umschlagsverschlüsselung beim Datenschlüssel bei AWS

Ein weiterer Vorteil eines Schlüsselmanagement-Dienstes ist, dass die Master-Schlüssel regelmäßig rotiert werden können. Die Datenschlüssel bleiben als abgeleitete Schlüssel trotzdem gültig (s. Abb. 5).

Abb. 5: Der Masterschlüssel wird unabhängig vom Datenschlüssel in einem zentralen Schlüsselmanagement-Dienst gespeichert

Beim bekannten AWS-Cloud-Anbieter gibt es den Schlüsselmanagement-Dienst KMS. Vom AWS-Schlüsselmanagement-Dienst werden vier Schlüsselarten [AWSKMS] unterstützt: vom Kunden gemanagte Schlüssel, von AWS gemanagte fremde und AWS eigene Schlüssel und externe vom Kunden gemanagte Schlüssel [EKM]. Damit hat man viele Möglichkeiten, zwischen Kontrolle und Komfort beim Schlüsselmanagement zu wählen. Schlüssel erzeugt man mit dem AWSKMSClientBuilder des AWS SDK for Java 2.x [AWSSDK].

Tink mit Java-Beispielen

Möchte man jedoch unabhängig von Cloud-Anbieter und Plattform arbeiten, bietet sich die Google-Bibliothek Tink [TINK] an. Tink ist eine mehrsprachige, plattformübergreifende Open-Source-Bibliothek, die sichere und einfach zu verwendende kryptografische APIs bereitstellt und von Kryptografen und Sicherheitstechnikern bei Google seit 2017 verwaltet wird. Deren Sicherheit wird permanent auditiert und auch wissenschaftlich begleitet [TINKJSEC]. Tinks Designziele bezüglich Security und Usability sind unter [TINKDESIGN] beschrieben. Die Verwendung der Bibliothek ist auch mit Beispielen [TINKJEXP] gut dokumentiert. Anders als Bouncy Castle ist Tink kein Provider in JCA, sondern eine eigenständige vereinfachte kryptografische API.

Neben Java [TINKJ] (ab Version 8) werden als Programmiersprachen C++, Go, Objective-C und Python mit sehr ähnlicher API unterstützt. Bei den Algorithmen und Primitives hängt Objective-C den anderen Programmiersprachen hinterher. Für C++ wird bereits der erste PQC-Algorithmus mit Kyber unterstützt.

Wer es genau wissen möchte, kann das unter [TINKEYS] pro Programmiersprache nachlesen. Für die Verschlüsselung in C++ kann entweder die OpenSSL- oder die BoringSSL-Bibliothek verwendet werden. Für Java gibt es eine eigne Bibliothek, die in einer speziellen Variante auch für Android verfügbar ist. Außerdem gibt es für die Cloud-Anbieter AWS [TINKJAWS] und Google [TINKJGCP] Erweiterungen, um mit deren Schlüsselmanagement zu arbeiten. So kann man Tink vom mobilen Client bis in die Cloud verwenden. Alle sechs Monate erscheint eine neue Version. Die aktuelle für Java ist 1.12. Um Tink in Java zu verwenden [TINKJSETUP], kann man es in Maven als Abhängigkeit einbinden:

<dependency>
<groupId>com.google.crypto.tink</groupId>
<artifactId>tink</artifactId>
<version>1.12.0</version>
</dependency>

Eine Motivation für die Entwicklung von Tink war die Erfahrung aus dem Wycheproof-Testprojekt [WYCHEP] für Crypto-Bibliotheken, dass die Verwendung von deren kryptografischen APIs [CogniCrypt, SECCODE2017] oft sehr komplex war, sodass viele Parameter, mangels Wissens und ausreichender Dokumentation, oft falsch und damit unsicher verwendet wurden. Um die Nutzung zu vereinfachen, verwendet Tink die in Tabelle 1 aufgeführten Primitives (fertig vorkonfigurierte kryptografische Bausteine, die die Details der zugrunde liegenden Algorithmen enthalten).

Die Primitives aus Tabelle 1 werden wie folgt initialisiert:

KeysetHandle keysetHandle = KeysetHandle.generateNew(
AeadKeyTemplates.AES256_GCM);
keysetHandle = KeysetHandle.generateNew(
StreamingAeadKeyTemplates.AES128_CTR_HMAC_SHA256_4KB);
keysetHandle = KeysetHandle.generateNew(
MacKeyTemplates.HMAC_SHA256_128BITTAG);
keysetHandle = KeysetHandle.generateNew(
SignatureKeyTemplates.ECDSA_P256);
keysetHandle = KeysetHandle.generateNew(
HybridKeyTemplates.ECIES_P256_HKDF_HMAC_SHA256_AES128_CTR_HMAC_SHA256);

Die authentifizierte Verschlüsselung mit verknüpften Daten (AEAD, Authenticated Encryption with Associated Data) bietet Klartext-Vertraulichkeit und ermöglicht die Überprüfung der Integrität und Authentizität. Für eine große Datenmenge wird die Streaming-AEAD-Variante verwendet.

Bei der deterministischen Verschlüsselung wird immer derselbe Geheimtext für einen bestimmten Klartext und Schlüssel erzeugt. Dies kann riskant sein, da ein Angreifer nur herausfinden muss, welcher Geheimtext einer bestimmten Klartexteingabe entspricht, um ihn zu identifizieren. Deswegen ist eine Hybridverschlüsselung besser. Diese kombiniert die Effizienz der symmetrischen Verschlüsselung mit dem Komfort der öffentlichen Schlüsselverschlüsselung. Zum Verschlüsseln einer Nachricht wird ein neuer symmetrischer Schlüssel generiert und zur Verschlüsselung der Klartextdaten verwendet. Der öffentliche Schlüssel des Empfängers wird hingegen nur für die Verschlüsselung verwendet. Der endgültige Geheimtext besteht aus dem symmetrischen Geheimtext und dem verschlüsselten symmetrischen Schlüssel.

Eine digitale Signatur wird verwendet, um die Authentizität und Integrität signierter Daten zu bestätigen. Zusätzlich wird aus den zu schützenden Daten und einem geheimen Schlüssel eine Prüfsumme als Nachrichtenauthentifizierungscode (MAC) berechnet. AEAD-Verfahren [AEAD] werden unter anderem in den Verschlüsselungsprotokollen SSH und TLS verwendet. Wir wollen uns Tink mit der authentifizierten Verschlüsselung mit verknüpften Daten (AEAD), der Umschlagsverschlüsselung und dem Google-Schlüsselmanagement näher anschauen.

Tink mit Schlüsselmanagementsystemen

Schlüsselmanagementsysteme erleichtern die Verwaltung von Schlüsseln. Sie erleichtern auch den Einsatz von identitätsoder ressourcenbasierten Richtlinien, wie für die automatische Schlüsselrotation. Tink unterstützt mehrere Schlüsselmanagementsysteme, wie Google Cloud KMS, wird AWS KMS, HashiCorp Vault, Android Keystore und Apple iOS KeyChain. Um die Verwendung zu vereinfachen, gibt es hier jeweils eigene Bibliotheken mit Wrapper-Klassen.

Tink mit AEAD

Es werden mehrere Beispiele mit Tink [TINKJEXP] ausgeliefert. Ein Beispiel für eine authentifizierte Verschlüsselung mit verknüpften Daten (AEAD) zeigt Listing 2.

public final class AeadExample {
...
// Register all AEAD key types with the Tink runtime.
AeadConfig.register();
// Read the keyset into a KeysetHandle.
KeysetHandle handle =
  TinkJsonProtoKeysetFormat.parseKeyset(
    new String(Files.readAllBytes(keyFile), UTF_8),
InsecureSecretKeyAccess.get());
// Get the primitive.
Aead aead = handle.getPrimitive(Aead.class);
// Use the primitive to encrypt/decrypt files.
 byte[] plaintext = Files.readAllBytes(inputFile);
 byte[] ciphertext = aead.encrypt(plaintext, associatedData);
 Files.write(outputFile, ciphertext);
 byte[] ciphertext = Files.readAllBytes(inputFile);
 byte[] plaintext = aead.decrypt(ciphertext, associatedData);
 Files.write(outputFile, plaintext);
}

Diese Klasse kann mit java AeadExample encrypt/decrypt key-file in-put-file output-file [associated-data]aufgerufen werden. Mit dem CLI-Werkzeug Tinkey [TINKEY] kann man sich mit tinkey -list-keytemplates vorhandene Schlüsselvorlagen anzeigen und damit zum Beispiel für AES ein Keyset aus einem vorher erstellten keyRingerstellen lassen:

tinkey create-keyset --key-template AES128_GCM --out-format JSON \
--out aead_test_keyset.json

Mit echo "some data" > testdata.txt erzeugt man Daten, die zum Verschlüsseln dienen. Dieses kann man wiederum für die AeadExample-Klasse zum Verschlüsseln verwenden:

java AeadExample encrypt _test_keyset.json
testdata.txt testdata.txt.encrypted

Gleiches geht für die andere Richtung beim Entschlüsseln:

java AeadExample decrypt test_keyset.json
testdata.txt.encrypted testdata.txt.decrypted

Dass diese identisch sind, kann man mit diff testdata.txt testdata. txt.decrypted überprüfen.

Tink mit Umschlagsverschlüsselung

Ein wichtiges Verfahren zum doppelten Schutz der Daten in der Cloud ist die Umschlagverschlüsselung, also die Verschlüsselung eines Schlüssels mit einem anderen Schlüssel. Der zum Verschlüsseln von Daten verwendete Schlüssel wird als Data Encryption Key (DEK) bezeichnet. Der DEK wird wiederum mit einem Key Encryption Key (KEK) verschlüsselt. Der KEK bleibt immer in dem Cloud KMS. Zur Verschlüsselung von Daten werden DEK lokal [TINK-CLOUD] generiert. Die Daten werden mit dem DEK verschlüsselt.

Der KEK wird verwendet, um den DEK zu verschlüsseln. Deswegen hat der DEK ohne einen KEK keinen Nutzen und kann ohne Gefahr direkt zu den damit verschlüsselten Daten gelegt werden, was seine Verwendung vereinfacht. Die Verschlüsselung geht genau andersherum. Die Umschlagverschlüsselung mit zwei Schlüsseln, die an zwei getrennten Orten liegen und auch getrennt verwaltet werden, garantiert ein effizientes, aber dennoch sehr sicheres Verfahren.

Zunächst braucht man die Google-GCP-IAM-Rolle Cloud KMS CryptoKey Encrypter/Decrypter (roles/cloudkms.cryptoKeyEncrypterDecrypter), um mit Cloud-KMS-Schlüsseln arbeiten zu können. Der Cloud-KMS-Schlüssel dient als Schlüsselverschlüsselungsschlüssel (KEK). Er wird zum Verschlüsseln von DEKs verwendet, die wiederum zum Verschlüsseln der Daten verwendet werden. Nachdem der KEK in Cloud KMS erstellt wurde, müssen Sie zum Verschlüsseln jeder Nachricht folgende Schritte ausführen:

• Generieren Sie lokal einen Datenverschlüsselungsschlüssel
• Verwenden Sie den DEK lokal zum Verschlüsseln der Nachricht.
• Nutzen Sie Cloud KMS, um den DEK mit dem KEK zu verschlüsseln (zu verpacken).
• Speichern Sie die verschlüsselten Daten und den zusammengefassten
  DEK.

Sie müssen diesen Umschlagverschlüsselungsprozess nicht von Grund auf implementieren, wenn Sie Tink verwenden. Wenn Sie Tink für die Umschlagverschlüsselung verwenden möchten, stellen Sie Tink einen Schlüssel-URI und Anmeldedaten bereit. Der Schlüssel-URI verweist auf Ihren KEK in Cloud KMS, und mithilfe der Anmeldedaten kann Tink den KEK verwenden. Tink generiert den DEK, verschlüsselt die Daten, verpackt den DEK und gibt dann einen einzelnen Geheimtext mit den verschlüsselten Daten und dem verpackten DEK zurück.

Tink unterstützt die Umschlagverschlüsselung in Python, Java, C++ und Go mit der einfachen AEAD-Verschlüsselung, wie wir sie im vorherigen Beispiel schon verwendet haben. Um die von Tink generierten DEKs mit Ihrem KEK in Cloud KMS zu verschlüsseln, müssen Sie den URI Ihres KEK abrufen. In Cloud KMS hat der KEK-URI folgendes Format:

gcp-kms://projects/<PROJECT>/locations/<LOCATION>/keyRings/
<KEY RING>/cryptoKeys/<KEY NAME>/cryptoKeyVersions/<VERSION>

Die Umschlagverschlüsselung mit dem Google-Cloud-KMS-Schlüssel gcp-kms://projects/tink-examples/locations/global/keyRings/foo/crypto-Keys/bar und den Credentials in der credentials.json-Datei führt dann die Schritte aus Listing 3 aus.

import com.google.crypto.tink.Aead;
import com.google.crypto.tink.KeyTemplates;
import com.google.crypto.tink.KeysetHandle;
import com.google.crypto.tink.KmsClients;
import com.google.crypto.tink.aead.KmsEnvelopeAeadKeyManager;
import com.google.crypto.tink.integration.gcpkms.GcpKmsClient;
// Generate the key material.
String kmsKeyUri =
 "gcp-kms://projects/tink-examples/locations/global/keyRings/foo/
cryptoKeys/bar";
KeysetHandle handle =
  KeysetHandle.generateNew(
    KmsEnvelopeAeadKeyManager.createKeyTemplate(
     kmsKeyUri, KeyTemplates.get("AES128_GCM")));
// Register the KMS client.
KmsClients.add(new GcpKmsClient()
  .withCredentials("credentials.json"));
// Get the primitive.
Aead aead = handle.getPrimitive(Aead.class);
// Use the primitive.
byte[] ciphertext = aead.encrypt(plaintext, aad);

Ausführlichere Beispiele finden Sie für Cloud KMS unter [TINK-JEE, TINKJGCP]. Dieses rufen Sie mit java EnvelopeAeadExample encrypt/decrypt kek-uri gcp-credential-file input-file output-file [associated-data] auf. Das Verschlüsseln geht dann mit den Konto-Verbindungsinformationen in:

my-service-account.json mit:
echo "some data" > testdata.txt
java EnvelopeAeadExample encrypt \
my-service-account.json \
gcp-kms://<my-key-uri> \
testdata.txt testdata.txt.encrypted

Das Entschlüsseln geht analog mit:

java EnvelopeAeadExample decrypt \
my-service-account.json \
gcp-kms://<my-key-uri> \
testdata.txt.encrypted testdata.txt

In Maven müssen Sie dazu neben Tink auch die passende Cloud-KMS-Clientbibliothek einbinden:

<dependency>
<groupId>com.google.crypto.tink</groupId>
<artifactId>tink</artifactId>
<version>1.12.0</version>
</dependency>
<dependency>
<groupId>com.google.crypto.tink</groupId>
<artifactId>tink-gcpkms</artifactId>
<version>1.9.0</version>
</dependency>

Wir haben hier gezeigt, wie Tink zusammen mit dem Cloud KMS verwendet werden kann. Ähnlich geht es mit Tink Java AWS KMS Extension [TINKJAWS] oder HashiCorp Vault.

Fazit

Die Google-Bibliothek Tink unterstützt mehrere Programmiersprachen, Plattformen und mehrere externe Schlüsselmanagementsysteme zum Verschlüsseln und Signalisieren. Damit können aktuelle kryptografische Verfahren, wie Key Encapsulation Mechanism (KEM), Key Derivation Function (KDF) und Authenticated Encryption with Associated Aata (AEAD), Data Encryption Key (DEK) verwendet werden. Mit dem KEM hält ein modernes Post-Quanten-Verschlüsselungsverfahren Einzug in Java. Mit der Tink-Bibliothek ist es möglich, viele kryptografische Aufgaben sicher und für verschiedene Szenarien einfach und sicher zu implementieren. Zusammen mit einem externen Schlüsselsystem ist Tink ein wichtiger Schritt hinsichtlich einer größeren digitalen Souveränität bei verschiedenen Cloud-Anbietern, aber auch mobilen Plattformen.

Weitere Informationen

[AEAD] Authenticated Encryption with Associated Data,
de.wikipedia.org/wiki/Authenticated_Encryption

[AWSDEK] AWS KMS Data Keys Envelope encryption,
docs.aws.amazon.com/kms/latest/developerguide/concepts.html#datakeys,
docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping

[AWSKMS] AWS KMS Special-purpose keys,
docs.aws.amazon.com/kms/latest/developerguide/key-types.html

[AWSSDK] AWS SDK FOR JAVA 2.X AWSKMSCLIENTBUILDER,
docs.aws.amazon.com/kms/latest/developerguide/programming-top.html

[CogniCrypt] CogniCrypt Eclipse-Kryptografie-Assistenten,
www.cognicrypt.de

[CRaC] Coordinated Restore at Checkpoint,
github.com/CRaC/docs#projects-with-crac-support

[EKM] Cloud encryption for AWS opens doors,
www.t-systems.com/de/en/insights/newsroom/expert-blogs/external-key-management-ekm-for-aws-586392

[GCPDEK] Umschlagsverschlüsselung mit GCP,
cloud.google.com/kms/docs/envelope-encryption

[HOWSHARE] How to Share a Key in Symmetric Cryptography?,
www.baeldung.com/cs/symmetric-cryptograph

[JAVACRYPTROAD] Oracle JRE and JDK Cryptographic Roadmap,
www.java.com/en/jre-jdk-cryptoroadmap.html

[JAVAJCA] Java Cryptography Architecture (JCA) Reference Guide Encapsulating and Decapsulating Keys,
docs.oracle.com/en/java/javase/21/security/java-cryptography-architecturejca-reference-guide.html#GUID-D6346359-6299-4D9C-82E5-E5ECFE37EDD9

[JAVAKEM] javax.crypto.KEM Class Documentation,
docs.oracle.com/en/java/javase/21/docs/api//java.base/javax/crypto/KEM.html

[JAVASEC] Java Security Libraries,
www.oracle.com/java/technologies/javase/javase-tech-security.html

[JAVASECNAME] Java Security Standard Algorithm Names,
docs.oracle.com/en/java/javase/21/docs/specs/security/standardnames.html

[JEP164] JEP 164: Leverage CPU Instructions for AES,
openjdk.org/jeps/164

[JEP246] JEP 246: Leverage CPU Instructions for GHASH and RSA,
openjdk.org/jeps/246

[JEP452] JEP 452: Key Encapsulation Mechanism API,
openjdk.org/jeps/452

[MIGSEC] Java Platform, Standard Edition Oracle JDK Migration Guide Security Updates,
docs.oracle.com/en/java/javase/21/migrate/security-updates.html

[SDG21] Na Meng et al., Java Platform, Standard Edition Security Developer’s Guide Release 21,
docs.oracle.com/en/java/javase/21/security

[SECCODE2017] Secure Coding Practices in Java: Challenges and Vulnerabilities, Tagung 2017,
doi.org/10.48550/arXiv.1709.09970

[TINK] Dokumentation von Tink,
developers.google.com/tink

[TINKCLOUD] Verschlüsselung auf Clientseite mit einem Cloud KMS,
developers.google.com/tink/client-side-encryption

[TINKDESIGN] Tink's Security and Usability Design Goals,
github.com/tink-crypto/tink/blob/master/docs/SECURITY-USABILITY.md

[TINKEY] Tinkey CLI, Befehlsreferenz,
developers.google.com/tink/tinkey-command-reference

[TINKEYS] Key types supported by language,
developers.google.com/tink/supported-key-types

[TINKJ] Tink Java Releases,
github.com/tink-crypto/tink-java/releases

[TINKJEE] Tink Java envelope encryption example,
github.com/tink-crypto/tink-java-gcpkms/tree/main/examples/envelopeaead

[TINKJGCP] Verschlüsselung auf Clientseite mit Tink und GCP Cloud KMS,
https://developers.google.com/tink/client-side-encryption?hl=de#java

[TINKJAWS] Tink Java AWS KMS extension,
github.com/tink-crypto/tink-java-awskms,
github.com/tink-crypto/tink-java-awskms/blob/main/examples/maven/src/main/java/com/helloworld/HelloWorld.java

[TINKJEXP] Tink Java examples, github.com/tink-crypto/tinkjava/tree/main/examples
https://github.com/tink-crypto/tinkjava/tree/main/examples/aead

[TINKJGCP] Tink Java Google Cloud KMS extension,
github.com/tink-crypto/tink-java-gcpkms

[TINKJSEC] Viet Tung Hoang, Yaobin Shen, Security of Streaming Encryption in Google's Tink Library, Paper 2020/1019, eprint.ia.cr/2020/1019

[TINKJSETUP] Tink Java set-up,
developers.google.com/tink/tink-setup

[WYCHEP] Project Wycheproof tests crypto libraries against known attacks,
github.com/C2SP/wycheproof