Closed exarkun closed 1 year ago
I've just had https://hackage.haskell.org/package/cryptonite-0.30/docs/src/Crypto.Cipher.AES.Primitive.html#initAES pointed out to me, where I see that actually AES is not wrapped around the key but around some internal state computed from the key.
So this doesn't make sense after all. Sorry for the noise.
Crypto.Cipher.AES.AES128
and friends are newtype wrappers aroundCrypto.Cipher.AES.Primitive.AES
(which is unexposed).Crypto.Cipher.AES.Primitive.AES
is a newtype wrapper aroundData.ByteArray.ScrubbedBytes
(indirected throughCrypto.Internal.ByteArray
).Crypto.Cipher.AES.AES128
's constructor is not exposed and if it were, the type it is wrapped around is not exposed, so there is no way to get theScrubbedBytes
it is wrapped around. Yet it would be useful to have access to these bytes in some cases - for example, if they need to be persisted in order to save the key for later re-use. This would essentially provide the inverse behavior tocipherInit
. Without this functionality, when a key is constructed, the original bytes given tocipherInit
need to be saved alongside the key since they cannot be recovered from the key.Could the
ScrubbedBytes
be exposed somehow? Since this would remove the need to carry the original bytes alongside each key, it would simplify some applications and remove the possibility of bugs where the key and sidecar bytes are inconsistent with each other.