Did you know MacOS/iOS produces 160 bit secret key (not 256 bits)

snappy
snappy
Community Member
edited June 2019 in Mac

MacOS/iOS for the longest time ships with the Yarrow RNG which uses a combination of 3DES (112-bit security) and SHA1 (160-bit security). Therefore if you request 256-bits from the RNG you only get effective security of 160-bits. This is further confirmed by Apple's analysis of their FIPS publication thing https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp1944.pdf (pg 20 of 25) -

The cryptographic strength of the 192 and 256 bit AES keys as well as the ECDSA keys for the curve P-384, as modified by the available entropy, is limited to 160-bits.

I think this means if you generated your secret key with 1Password on a mac at some time then it only has 160-bit entropy (not 256 -bit as claimed), and it's unlikely that your master passphrase is >=160 bits. Same applies to any vault encryption etc.

We've been bamboozled by Apple + NIST.

Also, it might seem like in 10.14 and later versions of MacOS there's a switch to HMAC-DRBG which does provide 256-bit keys.

I found this out here: https://www.reddit.com/r/crypto/comments/c1e50o/macos_and_yarrow/erdylgi/

What do people think?

Edit: If what I'm saying is valid, then I think 1P should implement some kind of "linter" that'll detect the insecurity of 1P cryptographic keys based on the possible age of the database and potentially if it was created by MacOS (hoping this information might be stored) and regenerate them assuming Apple switches to HMAC-DRBG at some point, because there are claims in your security whitepaper which would no longer be true.


1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

Comments

  • Hi @snappy

    One point I seem to be missing... we don't claim the Secret Key to be 256 bits. We say that it is 128 bits:

    It has 128 bits of entropy, making it infeasible to guess no matter how much money or computing power an attacker has available.

    from: About your Secret Key

    Maybe when you say "Secret Key" you're talking about something else?

    Ben

  • snappy
    snappy
    Community Member
    edited June 2019

    One point I seem to be missing... we don't claim the Secret Key to be 256 bits. We say that it is 128 bits

    You're correct, I assumed it was 256 bits (and now disappointed - but I think I understand from a usability perspective that the secret key would be easier to visually represent). Looks like vault items are using 256 bit keys, but I guess there's a question whether it matters now if an attacker can brute-force the secret-key+passphrase (which could technically be stronger if the passphrase has 256 bits of entropy) or attack individual vault items.

  • Certainly a strong Master Password is still an important part of the equation. If you have any follow-up questions we'll be happy to do our best to address them. :)

    Ben

  • jpgoldberg
    jpgoldberg
    1Password Alumni

    That reddit thread is filled with lots of speculation and reading of tea leaves, and so I'd much rather wait for there to be clarity on the subject on what happens when n bytes of random data are requested from macOS and iOS.

    If, as speculated by some, that requesting 32 bytes (256) from the CSPRNG only gives us 20 bytes of entropy then we also need to know whether this is the case if we request one byte 32 times in a row. Or what happens when we request 12 or 16 bytes? Is every 20 bytes being stretched to 32 bytes? That is probably the worst case scenario.

    In the worst case scenario

    Let's suppose that the doomsayers are correct in their speculation, and that it is the worst case, in which every 20 bytes is stretched to 32 bytes. Now lets look at the most important cases where we call the CSPRNG.1

    • AES 256 bit keys for vaults. As 128 bits is all that we would really need, we have a very healthy margin for error
    • AES 256 for encrypted keys. We don't use keywrap, and so we are using the same AES-256 GCM that we use for vault data. Again, healthy margins for error.
    • RSA key generation. We create 2048 bit RSA keys. Although a 20/32 ratio may look bad here (1280 bits) with only a small margin for error, it is extremely unlikely that this could be used in an attack on RSA. The RNG has to be really bad (as many non-cryptographically secure ones are) for it to be usable for an attacker. That is guessing at the generated values is going to be much much more expensive then generalized number field sieve attacks on the 2048 bit modulus.
    • 12 byte GCM nonces. Although it would be a serious mistake to use sizes less than 12 bytes for GCM nonces, that doesn't mean that having only 60 bits of entropy is a problem. Indeed, the randomness requirements on GCM nonces is really about avoiding collisions. Predictability isn't a problem. Moving from 92 to 60 bits would lower the limit on the amount of data that we could safely encrypt under a single key/nonce pair, but our limit on the size of attachments is already going to be far below that limit.
    • 32 byte SRP ephemeral keys. The key that is derived from this, a session key, has entropy going into it from three sources. The 32 byte a chosen by the client, the 32 byte b chosen by the server, and the 16 byte session ID (not secret). Attacking this would mean solving Diffie-Hellman for either a or b on the 4096 bit modulus. As with RSA, there is no obvious way to turn that weakening in the key generation into an attack that is more efficient than other attacks.
    • ECDSA signing keys with P-256. Keys are 32 bytes giving a strength of 16 bytes. We only use these keys in very limited instances (though we have plans to make more use of them). Having an effective strength of 80 bits instead of 128 isn't something to be happy about, and if it turns out that there really is a problem in macOS/iOS key generation, then we will look for ways to mitigate that. But I'm not going to worry about that until we know that there actually is a problem.

    Again, that is all for the worst case. By and large, we have a sufficient margin for error in our key sizes; so even in this worst case, 1Password data is not placed in any practical risk.


    1. I will only talk about the most important, because there are times when we use it where we could get away with a non-cryptographically secure RNG, but we just use the CSPRNG everywhere to help avoid the mistake of using the wrong one. For example or coupon codes and UUIDs do not really need to be cryptographically secure, but we prefer to say "use a CSPRNG everywhere instead of having to decide on a case by case basis") ↩︎

  • snappy
    snappy
    Community Member
    edited June 2019

    That reddit thread is filled with lots of speculation and reading of tea leaves, and so I'd much rather wait for there to be clarity on the subject on what happens when n bytes of random data are requested from macOS and iOS.

    You missed the part where it came straight from the horses mouth (atsec for NIST (not Apple)). The reddit thread is completely optional.

    https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp1944.pdf

    Page 20 of 25 section 7,2:

    The cryptographic strength of the 192 and 256 bit AES keys as well as the ECDSA keys for the curve P-384, as modified by the available entropy, is limited to 160-bits.

    If you see an application using a 256-bit cryptographic key, you simply have to bruteforce the yarrow algorithm (160 bit keyspace) to get the output to generate the 256-bit key and you win. So the claim of producing a 256-bit security key on MacOS/iOS that uses these algorithms is simply incorrect. This applies to all cryptographic keys that rely on the RNG - RSA, SRP, etc. just bruteforce the yarrow keyspace and try the keys on the corresponding algorithm, and you're good to go.

  • snappy
    snappy
    Community Member

    I didn't respond to your second part regarding margin of error. I'm not trying to scare anyone. 160-bit security is still incredibly strong, I think even the original bitcoin proposal used RIPEMD-160 hash as a secondary hash function incase the security of SHA256 breaks. So I agree with the high margin of security - even in the quantum world for the constituent parts that use symmetric crypto (except secret key which gives a margin of 64-bit security).

    But I don't think anyone should accept being bamboozled by Apple & NIST, because now all your security claims for cryptographic keys of >160-bit security are no longer correct. In any sane modern OS when you ask the secure RNG for 32 bytes, you get close to 32 bytes of entropy. With Apple your entropy is capped at 20 bytes.

    As of 10.14.5 - the cryptographic RNG still uses yarrow according to random(4) manpage. So users are still probably being bamboozled.

    Also note: i'm not passing any blame to 1P - but I would hope that you take your security claims seriously.

  • snappy
    snappy
    Community Member

    Just a quick follow up. The person who initiated the original reddit thread questioning the CSPRNG used by MacOS emailed Craig Federighi directly and he responded that the they use a NDRNG (non-deterministic RNG [probably something that converts entropy to usable numbers]) to feed a DRBG (which appears to be AES CTR DRBG [1]) that produces output capped at 256-bit entropy.

    Apologies (esp. to you @jpgoldberg ), and again I didn't mean to fear monger, I was just trying to understand the extent of security claim w.r.t to their CSPRNG. I mean, I'm still convinced this was an issue, but they probably ditched all the old stuff when CoreCrypto came about, and Craig forgot to update the random(4) manpage.

    [1]: Section 7.1: The module uses a FIPS 140-2 approved deterministic random bit generator (DRBG) based on a
    block cipher as specified in NIST SP 800-90A. The default Approved DRBG used for random
    number generation is a CTR_DRBG with derivation function and without prediction resistance.[

  • Thanks for sharing that update @snappy. Glad to hear this appears to be more of a documentation issue than anything, at least at this stage.

    Ben

  • jpgoldberg
    jpgoldberg
    1Password Alumni

    Thanks for the follow-up @snappy. And no need to apologize. I had looked at the 2013 certification document (among the other tea leaves that were being read), but I also considered that that might be stating only 160 where guaranteed at the time. Note also that in 2013, 1Password was using 128 bit keys. I think you see what I mean now about needing to wait for the dust to settle to find out what is really going on.

    This, by the way, is one of many reasons why we don't try to build for FIPS mode. FIPS certification takes a very long time and is an extremely expensive process. Thus, updating the FIPS certified implementations happens very infrequently (even when bugs are discovered). Once you have FIPS certified implementations they end up frozen many years. You can't change them in the slightest without going the very long certification process again. So it is possible (but I'm speculating) that setting your Mac to run in FIPS-2 mode would go back to what is described in that 2013 document.

This discussion has been closed.