Tink ersetzt einzelne Schlüssel durch Keysets – Sammlungen von Schlüsseln mit IDs, von denen einer als primär markiert ist – und Algorithmen durch benannte Templates wie ECDSA_P256 oder ED25519. Die Primitive (PublicKeySign, PublicKeyVerify) rotieren Schlüssel transparent; das ist der Sinn des Designs und zugleich die Quelle seiner Überraschungen bei der Interoperabilität. Keysets werden als Tink-JSON oder binäres Protobuf gespeichert, nicht als PEM.
Das Standard-Template ECDSA_P256 stellt ein Ausgabepräfix voran: 0x01 und die 4 Byte lange Schlüssel-ID, gefolgt von einer DER-Signatur. Das JDK lehnte eine solche Signatur mit Invalid encoding for signature ab, und genauso wird es jeder Verifizierer außerhalb von Tink tun. Templates, deren Name auf _WITHOUT_PREFIX oder _RAW endet, lassen das Präfix weg, aber die Namen verbergen auch die Kodierung: ECDSA_P256_RAW erzeugte 64 Byte r‖s nach IEEE P1363, kein DER – die Signatur bestand die Prüfung mit SHA256withECDSAinP1363Format des JDK und scheiterte mit SHA256withECDSA. Wähle das Template nach der genauen Kodierung, die die Gegenseite erwartet, wie es das Beispiel mit ECDSA_P256_IEEE_P1363_WITHOUT_PREFIX tut, und prüfe die Bytes mit dem Konverter DER ⇄ Raw.
Ein fremder öffentlicher Schlüssel wird über SignaturePemKeysetReader importiert, und der so entstandene Schlüssel prüfte nur DER-Signaturen: Dieselbe rohe Signatur, die Tinks eigener P1363-Schlüssel akzeptierte, scheiterte am aus PEM importierten Schlüssel, bis sie in DER umkodiert wurde. Signaturen verwenden zufällige Nonces, s wird nicht normalisiert, und die Prüfung akzeptiert High-S; ungültige Eingaben lösen GeneralSecurityException: invalid signature aus.
Tink für Java 1.24.0 bietet Templates für ECDSA auf P-256, P-384 und P-521, für Ed25519 und für RSA (PKCS#1 v1.5 und PSS); ein Template für ML-DSA oder SLH-DSA ist in diesem Release nicht registriert (Name ML_DSA_65 does not exist). Für Post-Quanten-Signaturen auf der JVM greifst du heute zu Java JCA oder Bouncy Castle.