Robert Relyea
unread,Mar 30, 2020, 12:28:55 PM3/30/20You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Louis Abraham, Matthew N., dev-tec...@lists.mozilla.org, ke...@kerby.network
On 03/27/2020 12:21 PM, Louis Abraham wrote:
> Hi Matthew,
>
> Awesome, thanks and sorry for contacting the wrong list!
>
> Since then, I found the answer to the 14 bytes question:
>
https://hg.mozilla.org/projects/nss/rev/fc636973ad06392d11597620b602779b4af312f6#l6.49
> Basically the DER encoding is used instead for compatibility with a
> bugged implementation.
>
> I tried prepending |b'\x04\x0e'| to DER-encode the IV. However, the
> value I get makes no sense (and even has an incorrect padding
> according to pkcs7 <
https://tools.ietf.org/html/rfc2315>).
>
>
> Best,
>
> Louis
>
The IV length is still 16 bytes, but only 14 are randomly generated.
It's because the decoding code had a bug in it that requires the IV to
look like der encoded data, so the header needed to be added, but the
whole IV was used (including the 2 byte header) when encrypting/decrypting.
The goal of the AES-256 bit code was to encode AES-256 while allowing
older versions of NSS to still decrypt the new keys, since versions of
NSS may share their databases with other NSS applications running on
other machines.
bob
>
> Le ven. 27 mars 2020 à 19:57, Matthew N. <
Ma...@mozilla.com
> <mailto:
Ma...@mozilla.com>> a écrit :