aes256 encryption inconsistancy

When encrypting claims using holder_ecies, we symmetrically encrypt the claim attestations and issue a key to both the vivid and user identity for ownership. In a number of cases, these keys are unable to decrypt the attestation. There are also some occurences of non-deterministic behavior where the vivid and user decrypted keys will be different from eachother. Example:

//////////////////////VIVID////////////////////////////////
decrypted key:  {"salt":"48a0933a813d384ef9b6ff2860c5da77","iv":"1e9a58d999432abf7a41f49a19e8fd16"}
formatted key:  { salt: '48a0933a813d384ef9b6ff2860c5da77',
  iv: '1e9a58d999432abf7a41f49a19e8fd16' }
//////////////////////USER////////////////////////////////
decrypted key:  {"salt":"6b666be9ead0869a4082de46603faf9a","iv":"b2b1ba9e938f300cfb8ef6c22a89da05"}
formatted key:  { salt: '6b666be9ead0869a4082de46603faf9a',
  iv: 'b2b1ba9e938f300cfb8ef6c22a89da05' }

in the example above for claim_id = 8uIECytlSjB4NbVa in stage, we have two different keys for the attestation. The vivid one successfully decrypts the payload and the user one does not.

While this is acceptable given the different initiation vectors, there is some peculiarity that one works and the other doesnt. There are also cases where both keys are different and neither works.

Moonlight-io / asteroid-sdk-js

aes256 encryption inconsistancy #68