WIP

Author: CMCDragonkai

test-bootstrapping.ts

@@ -1,6 +1,6 @@
 import * as jest from 'jest';
 import * as jose from 'jose';
-import { hkdf, webcrypto } from 'crypto';
+import { hkdf, KeyObject, webcrypto } from 'crypto';
 import * as bip39 from '@scure/bip39';
 import { wordlist } from '@scure/bip39/wordlists/english';
 import * as utils from '@noble/hashes/utils';
@@ -342,45 +342,362 @@ async function main () {
   // Let's generate a random DEK first
   // It will be 256 bits, as we will be using AES256GCM
   // Which is a 32 byte key
+
   const dataEncryptionKey = getRandomBytesSync(32);
 
+  // DEK JWK
+  const dekJSON = {
+    alg: "A256GCM",
+    kty: "oct",
+    k: base64.base64url.baseEncode(dataEncryptionKey),
+    ext: true,
+    key_ops: ["encrypt", "decrypt"],
+  };
+
+  console.log('IMPORT DEK');
+
+  const dekKey = await jose.importJWK(dekJSON, dekJSON.alg, false) as Uint8Array;
+
+  console.log(dekKey);
+
+  // KeyLike is KeyObject in nodejs or CryptoKey in browsers
+  // There are improved security features when using these objects instead of Buffer
+  // They can be passed to other threads using `postMessage`
+  // the object is cloned...
+
+  // You can do KeyObject.from(CryptoKey)
+
+  // console.log(dekKey.type);
+  // console.log(dekKey.symmetricKeySize);
+  // console.log(dekKey.export({ format: 'jwk' })); // lol look at this
+
+  // dekKey.equals (compares another key object)
+  // dekKey.symmetricKeySize
+  // dekKey.type - public, private, secret
+
+  // Note that KeyObject is node specific
+  // CryptoKey however is more general...
+  // maybe we should use that?
+  // dekKey.asymmetricKeyType
+  // You just have to use `importKey`
+  // but this is not that important
+  // Ok we have the dekKey
+  // It's time to encrypt this...
+  // And use this for encryption...
+  // If we wanted to use it for encryption, let's see how we would do this?
+
+  // iv would be random
+  // createCipher
+
+  // But because JOSE uses platform native
+  // and we want to use webcrypto API to avoid platform native
+  // Here we would need to import the key
+  // We can use webcrypto's importation of the key
+  // OR we can use directly from the buffer
+  // But this reads the JSON as well and extracts it
+
+  const dekCryptoKey = await webcrypto.subtle.importKey(
+    'jwk',
+    dekJSON,
+    'AES-GCM',
+    true,
+    ['encrypt', 'decrypt']
+  );
+
+  console.log(dekCryptoKey);
+
+  const iv = getRandomBytesSync(16);
+
+  // This gives us a way to encrypt and decrypt now
+  const cipherText = await webcrypto.subtle.encrypt(
+    {
+      name: 'AES-GCM',
+      iv,
+      tagLength: 128,
+    },
+    dekCryptoKey,
+    Buffer.from('hello world')
+  );
+
+  console.log('CIPHERTEXT', cipherText);
+
+  // The IV and the tag length must be shared
+  // The ersulting data must be combined
+  // [iv, authTag, cipherText]
+  // however the authTag is already embedded in the cipherText
+
+  // This bundles it together
+  // we can also just use this within the system
+  // but I think the nodejs Buffer API is still better
+  // we just need the feross API... etc
+
+  const combinedText = new Uint8Array(iv.length + cipherText.byteLength);
+  const cipherArray = new Uint8Array(cipherText, 0, cipherText.byteLength);
+  combinedText.set(iv);
+  combinedText.set(cipherArray, iv.length);
+
+  console.log('COMBINED', combinedText);
+
+  // extracting it out of the combined text
+  const iv_ = combinedText.subarray(0, iv.length);
+  // The auth tag size will be consistent
+
+  const plainText = await webcrypto.subtle.decrypt(
+    {
+      name: 'AES-GCM',
+      iv: iv_,
+      tagLength: 128
+    },
+    dekCryptoKey,
+    cipherText
+  );
+
+  console.log(Buffer.from(plainText).toString());
+
+
+
+  // ---
+
+  console.log('NOW WE HAVE THE DEK')
+  console.log('WE ARE GOING TO ENCRYPT OUR JWK');
+  // dekJSON will be the JWK
+  // we will encrypt this like above
+  // It's time to use dir or ECDH-ES or somethig else
+
+  // This dekJSON is a symmetric key
+  // However we are going to do KEM
+  // by encrypting the dekJSON JWK file data
+  // with our ed25519 key
+  // To do so, we will first
+  // acquire the shared secret via DX
+  // Then pass it to HKDF-Extract with a static salt (for domain separation)
+  // Then pass it to HKDF-Expand - with static info to produce the key which is used
+  // for direct encryption of the JWK here
+
+  // This is the DH KX, getting us the shared secret
+  // this is the "z" value, it's a "shared secret" between me and me (in the future)
   const x25519sharedsecret = await nobleEd.getSharedSecret(
     rootKeyPair.privateKey,
     rootKeyPair.publicKey
   );
 
-  // This is 32 bytes
-  console.log(x25519sharedsecret);
-
   // Now we use hkdf-extract
 
-  // The salt also has to be auto generated...
-  // but i really don't think we need to do this
-  // It's not some password
-  // It's the actual derived key from ed25519
-  // so what's the point of the salt here?
-
+  // Produce a pseudo random key
+  // this is deterministic
+  // Because we are using the same shared secret above
+  // we are going to do this ONCE without a salt
+  // then produce multiple subkeys
   const PRK = nobleHkdf.extract(
     nobleSha512,
     x25519sharedsecret,
-    Buffer.from('some password')
   );
 
   // This is 64 bytes
-  console.log(PRK);
-
-  // But maybe we should be using JWK here again
-  // And use Key Wrapping but this time with ed25519
-  // Well here is the problem
-  // The DEK is randomly generated
-  // Now we are trying to encrypt it
-  // encrypting it rquires a key symmetric key too?
-  // So encrypted JWK is...?
-  // Cause the salt is needed And where we saving the salt
-  // Or not do it aall?
-  // Let's import it into JWK first
-
-  // I think we don't need the salt, simply because no precomputation attack is possible here
+  // Whether it produces 64 bytes or 32 bytes dpends on the input hash
+
+  console.log('PRK from HKDF-extract', PRK);
+  const PRK2 = nobleHkdf.extract(
+    nobleSha512,
+    x25519sharedsecret,
+    Buffer.from('domain separated')
+  );
+  console.log('PRK from HKDF-extract', PRK2);
+
+  // The info is useful here...
+  // For separating to different keys
+  const dbKeyKW = nobleHkdf.expand(
+    nobleSha512,
+    PRK,
+    Buffer.from('DB KEY key wrap/key encapsulation mechanism'),
+    32
+  );
+
+  // And this is 32 bytes
+  console.log('DBKEYKW', dbKeyKW);
+
+  // Ok great now we have the CEK to be used
+  // the question does JWA have this mechanism built in?
+  // Rather than us defining it?
+  // dir means direct encryption
+
+  // alg: dir
+
+  // The reason if we use AES KW
+  // it means the CEK itself is encrypted...
+  // The CEK encrypts the actual plaintext
+  // But the CEK itself is encrypted with AESKW
+
+  const dekJWE = new jose.FlattenedEncrypt(
+    Buffer.from(JSON.stringify(dekJSON), 'utf-8')
+  );
+
+  // Ok so what this does, is that it auto generates a CEK
+  // that CEK uses A256GCM to encrypt the actual DEK above
+  // But then takes a symmetric A256KW to encrypt the CEK
+  // This is where it doesn't make sense to do this
+
+  // We cannot use the Ed25519 private key
+  // We cannot use the shared secret
+  // We cannot use the PRK
+  // We can use the OKM from HKDF to do this (since it can be used as a symmetric key)
+  // But here, it's a bit of a waste
+  // Cause it's like
+  // We are using a symmetric key to encrypt a symmetric key to encrypt a symmetric key
+  // OKM -> CEK -> DEK
+  // sym    sym    sym
+  // It's just a bit dumb
+
+  dekJWE.setProtectedHeader({
+    alg: 'A256KW',
+    enc: 'A256GCM',
+    cty: 'jwk+JSON'
+  });
+
+  const inputE = getRandomBytesSync(32);
+
+  // You have to have a 256 bit key here to do the job
+  const encryptedDEKJWK = await dekJWE.encrypt(
+    inputE
+  );
+
+  // I wonder how this actually works
+  console.log(encryptedDEKJWK);
+
+  console.log(
+    'WHAT IS THIS',
+    await jose.flattenedDecrypt(
+      encryptedDEKJWK,
+      inputE
+    )
+  );
+
+  // Let's try something different
+
+  const dekJWEAgain = new jose.FlattenedEncrypt(
+    Buffer.from(JSON.stringify(dekJSON), 'utf-8')
+  );
+
+  dekJWEAgain.setProtectedHeader({
+    alg: 'dir',
+    enc: 'A256GCM',
+    cty: 'jwk+JSON'
+  });
+
+  const encryptedDEKJWKAgain = await dekJWEAgain.encrypt(dbKeyKW);
+
+  // Notice there's no `encrypted_key` property, the CEK is therefore empty
+  console.log(encryptedDEKJWKAgain);
+
+  console.log(jose.decodeProtectedHeader(encryptedDEKJWKAgain));
+
+  const decryptedAgain = await jose.flattenedDecrypt(encryptedDEKJWKAgain, dbKeyKW);
+
+  console.log(decryptedAgain.plaintext.toString());
+
+  // This is why there was meant to be a keyring database
+  // But this database is just disk based, no db is involved at all
+  // If the root key ever changes, you don't change the DEK
+  // But you do need to decrypt the JWK and re-encrypt it
+
+  // With AES KW, you can do the same...  but only teh CEK
+  // but the CEK is just somewhat smaller... it's not ereally that different
+
+  // alg: ECDH-ES+A256KW - this technically what we are doing...
+  // enc: A256GCM - to do the actual encryption
+  // how do use this?
+  // except it's using CONCAT KDF
+
+  // ECDH-ES is direct key agreement mode
+  // but it uses Concat KDF, so I don't think they are using HKDF
+
+  // It seems there's an extra RFC at 8037 to allow the usage of ED25519...
+  // but it has to use x25519... you have to convert it first
+  // perhpas it sort of works
+  // But it continues to use Concat-KDF
+  // Actually let's see if this works atm
+
+
+  const dekJWEWithEC = new jose.FlattenedEncrypt(
+    Buffer.from(JSON.stringify(dekJSON), 'utf-8')
+  );
+
+  dekJWEWithEC.setProtectedHeader({
+    alg: 'ECDH-ES',
+    enc: 'A256GCM',
+    cty: 'jwk+JSON',
+  });
+
+  // console.log(rootKeyPair);
+
+  // You get a public x25519, and nothing else
+  const publicX25519 = nobleEd.curve25519.scalarMultBase(rootKeyPair.privateKey);
+  console.log('original', rootKeyPair.privateKey);
+  console.log('PUBLIC X25519', publicX25519);
+
+  const y = {
+    alg: 'X25519',
+    kty: 'OKP',
+    crv: 'X25519',
+    x: base64.base64url.baseEncode(publicX25519),
+    ext: true,
+    key_ops: ['encrypt']
+  };
+
+  console.log('Y', y);
+
+  const x25519keylike = await jose.importJWK(y) as jose.KeyLike;
+
+  console.log(x25519keylike);
+
+  // dekJWEWithEC.setKeyManagementParameters({
+  //   epk: x25519keylike
+  // });
+
+  console.log('BEFORE WTF');
+
+  // // Do we encrypt with the public key?
+  // // Or enrypt with the private key?
+  const result = await dekJWEWithEC.encrypt(x25519keylike);
+
+  console.log('WTF?', result);
+
+  console.log(jose.decodeProtectedHeader(result));
+
+  // I'm not sure if this makes sense
+  // unless you derive the private key too
+
+  const z = {
+    alg: 'X25519',
+    kty: 'OKP',
+    crv: 'X25519',
+    x: base64.base64url.baseEncode(publicX25519),
+    d: base64.base64url.baseEncode(rootKeyPair.privateKey),
+    ext: true,
+    key_ops: ['decrypt']
+  };
+
+  console.log('Z', z);
+
+  const privatex25519 = await jose.importJWK(z) as jose.KeyLike;
+
+  console.log('PRIVATE X25519', privatex25519);
+
+  const omg = await jose.flattenedDecrypt(result, privatex25519);
+
+
+  console.log('TH shared secret', base64.base64url.baseEncode(x25519sharedsecret));
+
+  console.log(omg.plaintext.toString());
+
+
+
+
+
+
+
+  // const jwe = new jose.FlattenedEncrypt(Buffer.from(privateKeyJSONstring, 'utf-8'));
+
 
   // 2 options
   // alg: dir - https://datatracker.ietf.org/doc/html/draft-ietf-jose-json-web-algorithms-18#section-4.5 - directly using a symmetric shared secret using ECDH and HKDF?