Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: [key4.db] IV size for aes256-CBC

66 views
Skip to first unread message

Matthew N.

unread,
Mar 27, 2020, 2:57:29 PM3/27/20
to Louis Abraham, dev-tec...@lists.mozilla.org, rre...@redhat.com
Hi Louis,

The dev-tech-crypto mailing list I'm redirecting this to should be able to
get you an answer.

Thanks,
MattN


On Fri, Mar 27, 2020 at 8:51 AM Louis Abraham <louis....@yahoo.fr>
wrote:

> Hi,
>
> I'm the main developer of https://github.com/louisabraham/ffpass
> We are currently trying to accommodate the (not so) recent cryptographic
> changes in key4.db.
>
> If I understand correctly, key4.db contains a table metadata. The value
> item2 defines a cryptographic algorithm in the DER format.
>
> In the latest version of Firefox, this algorithm is PBES2, using
> aes256-CBC as the encryption algorithm.
>
> I'm facing a little problem when trying to execute aes256-CBC because the
> IV size is only 14 bytes (56 bits) instead of the 64 bits defined in the
> spec.
>
> Could you please help me to understand?
>
> Best,
> Louis
>

Robert Relyea

unread,
Mar 30, 2020, 12:28:55 PM3/30/20
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 :

Louis Abraham

unread,
Apr 1, 2020, 4:57:30 AM4/1/20
to Matthew N., dev-tec...@lists.mozilla.org, rre...@redhat.com, ke...@kerby.network
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

Le ven. 27 mars 2020 à 19:57, Matthew N. <Ma...@mozilla.com> a écrit :

> Hi Louis,
>
> The dev-tech-crypto mailing list I'm redirecting this to should be able to
> get you an answer.
>
> Thanks,
> MattN
>
>
> On Fri, Mar 27, 2020 at 8:51 AM Louis Abraham <louis....@yahoo.fr>

Louis Abraham

unread,
Apr 1, 2020, 4:57:30 AM4/1/20
to Matthew N., dev-tec...@lists.mozilla.org, rre...@redhat.com, ke...@kerby.network

Louis Abraham

unread,
Apr 1, 2020, 4:57:30 AM4/1/20
to Matthew N., dev-tec...@lists.mozilla.org, rre...@redhat.com, ke...@kerby.network

Louis Abraham

unread,
Apr 1, 2020, 4:57:31 AM4/1/20
to Matthew N., dev-tec...@lists.mozilla.org, rre...@redhat.com, ke...@kerby.network

Louis Abraham

unread,
Apr 1, 2020, 4:57:31 AM4/1/20
to Matthew N., dev-tec...@lists.mozilla.org, rre...@redhat.com, ke...@kerby.network

lauren...@gmail.com

unread,
Apr 27, 2020, 10:57:51 AM4/27/20
to mozilla-dev...@lists.mozilla.org
Hi Robert,

For PBKDF2, why the iteration value is only 1 by default ?
the recommandation is 10000: https://cryptosense.com/blog/parameter-choice-for-pbkdf2/

is it the value 1 in this ASN1 data ?

SEQUENCE {
OBJECTIDENTIFIER 1.2.840.113549.1.5.12 pkcs5 PBKDF2
SEQUENCE {
OCTETSTRING b'f92dde91809b8b00c6607b73f3d0321c80f930aa13f13da5293aede76ee92048'
INTEGER b'01' <----- iterations ?
INTEGER b'20'
SEQUENCE {
OBJECTIDENTIFIER 1.2.840.113549.2.9 hmacWithSHA256
}
}
}

Laurent,
author of https://github.com/lclevy/firepwd

Robert Relyea

unread,
Apr 28, 2020, 12:49:37 PM4/28/20
to dev-tec...@lists.mozilla.org
On 04/22/2020 01:21 AM, lauren...@gmail.com wrote:
> On Monday, March 30, 2020 at 6:28:55 PM UTC+2, Robert Relyea wrote:
> Hi Robert,
>
> For PBKDF2, why the iteration value is only 1 by default ?
> the recommandation is 10000: https://cryptosense.com/blog/parameter-choice-for-pbkdf2/
>
> is it the value 1 in this ASN1 data ?
>
> SEQUENCE {
> OBJECTIDENTIFIER 1.2.840.113549.1.5.12 pkcs5 PBKDF2
> SEQUENCE {
> OCTETSTRING b'f92dde91809b8b00c6607b73f3d0321c80f930aa13f13da5293aede76ee92048'
> INTEGER b'01' <----- iterations ?
> INTEGER b'20'
> SEQUENCE {
> OBJECTIDENTIFIER 1.2.840.113549.2.9 hmacWithSHA256
> }
> }
> }
>
> Laurent,
> author of https://github.com/lclevy/firepwd

There's a separate patch the increases is supposed to increase the
iteration count. I believe it landed after the AES changes.

bob


0 new messages