3
$\begingroup$

Given that macOS uses Yarrow as a PRNG, and Yarrow is only capable of 160 bit outputs (/dev/random on macOS is actually Yarrow) are keys generated on macOS weaker than Linux?

Even BSD has switched to Fortuna.

Is this is big gaping hole in Modern macOS security?

https://en.m.wikipedia.org/wiki/Yarrow_algorithm

EDIT:

I have looked through the source and it seems as if they switched to a DRBG NIST generator?

https://opensource.apple.com/source/xnu/xnu-4903.221.2/osfmk/corecrypto/ccdbrg/src/ccdrbg_nisthmac.c.auto.html

There are very few references to Yarrow in the 10.14 XNU code compared with older versions of the Kernel, but 10.14 still contains this string in key.c :

/* Our PRNG is based on Yarrow and doesn't need to be seeded */
That said if you looked at older XNU Yarrow is littered everywhere.

Source code for XNU:

Lots of Yarrow references in XNU 2782 - macOS 10.11

Very few Yarrow references in XNU 4903 - macOS 10.14

So, are Apple still using Yarrow?

Update: Apple are using Fortuna.

Improve this question
$\endgroup$
4
  • $\begingroup$ Does it block like Linux when entropy runs out/is insufficient? $\endgroup$
    – Paul Uszak
    Jun 16, 2019 at 20:47
  • 2
    $\begingroup$ Nope! Neither dev/random or urandom block. $\endgroup$
    – Woodstock
    Jun 16, 2019 at 21:53
  • 2
    $\begingroup$ Only FreeBSD switched to Fortuna with SHA-256. OpenBSD and NetBSD use ChaCha20 as the core primitive. $\endgroup$
    – Aaron Toponce
    Jun 16, 2019 at 22:52
  • 1
    $\begingroup$ @PaulUszak Once sufficient entropy has been collected, it never "runs out". $\endgroup$
    – forest ♦
    Jun 17, 2019 at 6:24

2 Answers 2

Reset to default
-1
$\begingroup$

  1. Whilst the estimation of input entropy is regarded as conservative (as is Linux's), not blocking means that information theoretic secure output cannot be achieved. So any key or keys generated in an (output length) > (input entropy) situation can theoretically be inverted/predicted. It is not mathematically impossible, only computationally difficult (at present). Tomorrow or the day after it may become possible.

    We can't predict the future, but one consequence of macOS is that it cannot be used to generate a one time pad. Therefore macOS keys can be viewed as being less secure than /dev/random Linux keys in this (rare) use case. That means it's one small crack, rather than a gaping hole, and exists irrespective of the 160 bit key space.

  2. Above excepted, given side channel attacks and side of side channel attacks, I suggest that there is no holistic security difference between a 256 bit key and a 160 bit key (the problems with SHA1/3DES aside). Mathematically $2^{256} > 2^{160}$. But given all current and future side channels, I can't see a practical real world difference when trying to preserve a secret.

Holistic security: security in the whole given all aspects of a political, economic, social and technological analysis (PEST). E.g. What's the difference between key sizes when Australia has now outlawed unbreakable encryption? E.g. Why brute force a key when a key logger/camera is less costly to install? E.g. Or hack the phone rather than the $n$ bit app?

Improve this answer
$\endgroup$
17
  • 2
    $\begingroup$ What exactly is the definition of Holistic security doing at the bottom of this answer? It does not appear to be related... $\endgroup$
    – Ella Rose
    Jun 17, 2019 at 2:12
  • 1
    $\begingroup$ Paul, there is no way there will be a 160-bit SHA-1 preimage "tomorrow". Computationally difficult does not mean "well, we think it's pretty hard", it means "this will not happen before the sun burns out". $\endgroup$
    – forest ♦
    Jun 17, 2019 at 7:25
  • 1
    $\begingroup$ @Woodstock I'd be very happy at 128 bits. Look at the effort required to brute force 128 bits. Holistically, it's total useless. No one's going to try. I'll just locate you, break into your house and steal your PC. Or take the original papers lying on your desk, and make it look like a drug burglary. Look at all other breaches. There's a million side/side of side channels that mean the brute force effort threshold is a lot lower than 256 bits. $\endgroup$
    – Paul Uszak
    Jun 17, 2019 at 12:34
  • 2
    $\begingroup$ @Woodstock Careful. Uszaks feed on positive attention. They are an invasive species that thrive in an environment where it takes five down votes to cancel out the rep gained from one up vote. To the untrained eye they mimic the native fauna very well. It's in noone's interest to leave scraps out for the Uszak. They will keep coming back for more food and never develop the skills to earn compliments in the wild. -- Sorry. This platform isn't really suited for back and forth conversation. I wish it were, then I could say something more helpful than "caveat lector". $\endgroup$
    – Future Security
    Jun 17, 2019 at 23:39
  • 2
    $\begingroup$ @PaulUszak While it may have been written in a rather abrasive tone and it may have been better to simply point out the Dunning–Kruger effect, it's not a problem to point out that the community often disagrees with you or that the downvote/upvote dynamics often hide the community's opinion on some of your posts. Your answer has many factual inaccuracies and falsehoods, and Future Security was just warning OP. $\endgroup$
    – forest ♦
    Jun 18, 2019 at 3:24
6
$\begingroup$

A 160-bit seed is plenty for a cryptographically-secure PRNG. We are not going to be able to count to 2160 any time soon, so there is no need to worry that this is a "gaping hole". While in theory Linux's random driver may have a larger keyspace, it's not going to make a difference in real life. Fortuna does have advantages over Yarrow, but a larger key size is not what's important. What really matters is resistance to side-channel attacks and adequate entropy collection at boot time.

By default, Yarrow-160 actually uses 3DES in counter mode to generate the random output, which gives it approximately 112 bits of security. Fortuna uses any other block cipher in counter mode, but typically 128-bit AES. The Linux randomness driver uses ChaCha20. It starts out with 320 bits of secret material (a 256-bit key and a 64-bit nonce). Each reseed updates the 256-bit key. So yes, Linux has a larger keyspace. No, this doesn't matter in practice. Yarrow, Fortuna, and Linux's CRNG are all secure.

Improve this answer
$\endgroup$
5
  • $\begingroup$ Thank you very much. If I understand you though, does that mean on macOS it’s technically not possible to generate a trusty cryptographically secure key greater than 160bits? I.e 256bit aes keys generated on macOS are weaker than on other systems despite being “256” bits physically? $\endgroup$
    – Woodstock
    Jun 17, 2019 at 7:05
  • 1
    $\begingroup$ @Woodstock More like 112 bits, if my understanding of its Yarrow-160 implementation is correct. $\endgroup$
    – forest ♦
    Jun 17, 2019 at 7:24
  • $\begingroup$ so all keys generated on macOS only have a bit strength of 112bits?! $\endgroup$
    – Woodstock
    Jun 17, 2019 at 8:55
  • 3
    $\begingroup$ Regarding whether or not it's possible to generate 256-bit keys with Yarrow-160, if the internal state of the generator is >= 256-bits, then you can make multiple calls to the generator, and combine them for a theoretically secure 256-bit key. $\endgroup$
    – Aaron Toponce
    Jun 17, 2019 at 17:45
  • $\begingroup$ @forest JFYI Apple released new docs, stating they moved to Fortuna: support.apple.com/en-ie/guide/security/seca0c73a75b/web $\endgroup$
    – Woodstock
    Jan 8, 2020 at 17:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.