Interop zwischen Knoten-jose (js) und jwcrypto (Python) mit EC-Schlüssel?

Question

Ich habe Schwierigkeiten, ein JWE in jwcrypto zu erzeugen, das dem in node-jose mit dem gleichen Schlüssel entspricht. Das Ziel besteht darin, einen Schlüssel in node-jose zu erzeugen und den Pubkey nach jwcrypto zu exportieren, um eine Nutzlast zu verschlüsseln, die dann von node-jose und entschlüsselt konsumiert wird.

Mein Test vollständig in node-jose funktioniert:

var jose = require("node-jose") 
var keyStore = jose.JWK.createKeyStore() 

keyStore.generate('EC', 'P-521').then(function (result) { 

    // Use exported key to encrypt something (so we see the same thing jwcrypto does)  
    jose.JWK.asKey(result.toJSON()).then(function(result) { 

     jose.JWE.createEncrypt(result).update('this is a test payload').final().then(function (result) { 

      jose.JWE.createDecrypt(keyStore).decrypt(result).then(function (result) { 

       // Result is good 
       console.log(result) 
     }) 
    }) 

}) 

Allerdings, wenn ich das gleiche in Python zu tun, Knoten-jose eine andere JWE produziert:

key = jwk.JWK(**json.loads(the_exported_key)) 

    # This key looks exactly the same as the exported key in node-jose 
    print(key.export(private_key=False)) 

    payload = "this is a test payload" 

    header = { 
     'alg': 'ECDH-ES', 
     'enc': 'A128CBC-HS256', 
    } 
    my_jwe = jwe.JWE(payload.encode('utf-8'), header) 
    my_jwe.add_recipient(key) 

Wenn der Knoten-jose versucht, my_jwe zu entschlüsseln, schlägt es mit "Error: no key found" fehl. Seltsamerweise (oder nicht, das ist das erste Mal, dass ich JWEs verwende ...), sind die beiden Verschlüsselungsergebnisse (siehe Beispiele unten). Ich denke, ich vermisse, wie jwcrypto zu bekommen, wie node-jose, nicht "Header" -Werte erfordern, aber wenn ich diejenigen ziehe, klagt es.

Knoten-jose Beispiel (Junk-Daten):

{ 
    ciphertext: "1e7YX6hNDJWJELhHTNXEOg", 
    iv: "oQZZq2smHX8u8MMwoC6NBA", 
    protected: "eyJhbGciOi".....(very long string), 
    tag: "3NfEqx9f2ivL8QodG5Duaw", 
} 

jwcrypto (Junk-Daten):

{ 
    ciphertext: "7ldKnkcsLZUy-SXFRv_HpkWOsb-YUUlNFv-4M5yZhCA", 
    iv: "1uErMiK_RWcaPXPCPq12Uw", 
    header: { 
     alg: "ECDH-ES", 
     enc: "A128CBC-HS256", 
     epk: { 
      crv: "P-521", 
      kty: "EC", 
      x: different from the exported key, I assume this is expected 'epk', 
      y: different from the exported key, I assume this is expected 'epk', 
     }, 
     kid: "JCU3sWKfirVybFbpy2NPOnq-4-43JiemRZLO5dmPMVo" 
    }, 
    tag: "51AMFyCJld5uPyMFLLl-sw", 
} 

Answer 1

Die Ergebnisse, die Sie mit jwcrypto oder Knoten-jose bekam aussehen kompatibel mit dem RFC7516. Der einzige Unterschied ist, dass node-jose Ihren Header im Member protected (Integrity Protected Header) gesetzt, während jwcrypto setzen Sie es in der header Mitglied (pro Empfänger ungeschützten Header).

Mein Verständnis ist, dass Knoten-jose einen Fehler auslöst, weil es den öffentlichen Schlüssel in der Kopfzeile (epk Mitglied) nicht finden kann. Es prüft nur die protected Mitgliedes und nicht die anderen Header (header und auch unprotected Mitglieder falls vorhanden), die mit den RFC7516 section 2 paragraph 4. nicht kompatibel ist:

let the JOSE Header be the union of the members of the JWE Protected Header, the JWE Shared Unprotected Header and the corresponding JWE Per-Recipient Unprotected Header

Aus meiner Sicht, wenn ein JWE für nur einen Empfänger erstellt wird, Es gibt keinen Grund, das Element epk (sowie die Elemente alg und enc) in einem ungeschützten Header festzulegen. Das Vorhandensein dieser ungeschützten Header verhindert die Verwendung der JWE Compact Serialization. Daher sollte das Verhalten von jwcrypto geändert werden.

Ich weiß nicht, wie diese beiden Bibliotheken arbeiten, aber es gibt zwei Möglichkeiten, um das Problem zu beheben:

• Kraft jwcrypto die Integrität geschützt Header statt den ungeschützt man verwenden (beste).
• Stellen Sie node.jose Berücksichtigung der anderen Header zu nehmen (gut aber einige Zeit dauern kann)