Open iFergal opened 9 months ago
Those codes were added originally to support key managmeent not for generic encryption. The CESR 2.0 code table (see https://github.com/WebOfTrust/keripy/discussions/612) already encludes new codes for generic encryption using sealed box. These allow variable length encryptions
| `4C` | X25519 sealed box cipher bytes of sniffable plaintext lead size 0 | 4 | 2 | |
| `5C` | X25519 sealed box cipher bytes of sniffable plaintext lead size 1 | 4 | 2 | |
| `6C` | X25519 sealed box cipher bytes of sniffable plaintext lead size 2 | 4 | 2 | |
| `7AAC` | X25519 sealed box cipher bytes of sniffable plaintext big lead size 0 | 8 | 4 | |
| `8AAC` | X25519 sealed box cipher bytes of sniffable plaintext big lead size 1 | 8 | 4 | |
| `9AAC` | X25519 sealed box cipher bytes of sniffable plaintext big lead size 2 | 8 | 4 | |
| `4D` | X25519 sealed box cipher bytes of QB64 plaintext lead size 0 | 4 | 2 | |
| `5D` | X25519 sealed box cipher bytes of QB64 plaintext lead size 1 | 4 | 2 | |
| `6D` | X25519 sealed box cipher bytes of QB64 plaintext lead size 2 | 4 | 2 | |
| `7AAD` | X25519 sealed box cipher bytes of QB64 plaintext big lead size 0 | 8 | 4 | |
| `8AAD` | X25519 sealed box cipher bytes of QB64 plaintext big lead size 1 | 8 | 4 | |
| `9AAD` | X25519 sealed box cipher bytes of QB64 plaintext big lead size 2 | 8 | 4 | |
| `4E` | X25519 sealed box cipher bytes of QB2 plaintext lead size 0 | 4 | 2 | |
| `5E` | X25519 sealed box cipher bytes of QB2 plaintext lead size 1 | 4 | 2 | |
| `6E` | X25519 sealed box cipher bytes of QB2 plaintext lead size 2 | 4 | 2 | |
| `7AAE` | X25519 sealed box cipher bytes of QB2 plaintext big lead size 0 | 8 | 4 | |
| `8AAE` | X25519 sealed box cipher bytes of QB2 plaintext big lead size 1 | 8 | 4 | |
| `9AAE` | X25519 sealed box cipher bytes of QB2 plaintext big lead size 2 | 8 | 4 | |
The Encrypter and Decrypter Classes will need to be updated to support the new codes
Ah okay they came recently for CESR 2.0 - so they just didn't reach Signify-TS yet. I can create a PR this week to add support - thanks!
@SmithSamuelM Do we need a new subclass of Matter
to hold plaintexts after decrypting, or Matter
is enough?
Matter would not do any decrypting. So you would need the decrypter sub class or the like. All Matter does is handle the conversions between the three formats, Text (QB64), Binary (QB2), and Raw (Code, Raw) using the code tables. Matter enables the primitive to be ser/des by a generator/parser.
@SmithSamuelM I mean in Decrypter.ts
- what class _x25519
should return after decrypting;
For instance, right now if a X25519_Cipher_Salt
is decrypted, we return a Salter
instance and for X25519_Cipher_Seed
, a Signer
instance - https://github.com/WebOfTrust/signify-ts/blob/development/src/keri/core/decrypter.ts#L72
for these variable length codes what will likely be returned are Bexter for the B64 encryptions and two new classes yet to be created that might be called Texter or Byter for arbitrary length bytestrings of text. and a new class for arbitrary length CESR Streamns. Name TBD.
The Matter codex table in
signify-ts
only supportsX25519_Cipher_Seed
andX25519_Cipher_Salt
.If it's OK, I'd like to add the other 18 or so -
X25519_Cipher_L0
->X25519_Cipher_QB2_Big_L2
[encrypter.ts
,decrypter.ts
,cipher.ts
,matter.ts
] so we can sign arbitrary data. (e.g. for KERI ESSR from Signify)My only question here is what class
Decrypter._x25519
should return for these codecs - justMatter
?