This is a staging forum for AgileBits, not an official support forum. Visit http://discussions.agilebits.com instead.
Ron was wrong, Whit is right
Comments
-
Hi Ben,
The short answer is that 1Password users have nothing to worry about. We follow best practices in getting our random numbers:
[img]http://imgs.xkcd.com/comics/random_number.png[/img]
More seriously, since that paper came out, I started drafting a document describing the process, but it's not ready for public consumption yet. Anyway, we do use appropriate CSPRNGs (Cryptographically Secure Pseudo-random Number Generator) that are seeded (indirectly) through /dev/random.
Now that that's out of the way, I'd like to point out that nobody needs to worry about what that paper reported. For those who don't know, a recent paper claimed that up to 2% of website site certificates are broken, and provide poor security.
In sum there were three things that they said[list=1]
[*]Lot's of certificates have RSA moduli that are less than 1024 bits (and so breakable using feasible attacks today)
[*]Lots of component primes were generated with broken PRNGs, and there are actual collisions among moduli out there
[*]RSA is inherently more vulnerable to the second problem than discrete logarithms or elliptical curves.
[/list]
Now their argument for point 3 is just silly. I spent a lot of time trying to make sense of it, as did others. It just doesn't fly. Also their point 3 is where they get their dramatic title "Ron was wrong, Whit was right".
But let's look at 2, as that is where the most legitimate concern is. It turns out that when they shared their data with other researchers, a look at it showed that all of the bad public/private key pairs where on test, non-functional certificates anyway. That is, it turned out that all of the weak or broken certificates were things like self-signed certificates anyway. That is, they were not being used in ways in which there is any expectation that they would be trusted in the first place.
Please take a look at Dan Kaminisky's summary, after he had a chance to study the original data.
[url="http://dankaminsky.com/2012/02/17/primalfear/"]http://dankaminsky.c.../17/primalfear/[/url]
The whole thing is a non-issue.
This is not to say that there aren't serious problems with the trust models used for key authentication. But the particular paper muddies the discussion instead of shedding light on it.
Cheers,
-jFlag 0 -
Well, the part about it being easy to break [b][i]two[/i][/b] RSA keys if you know that they share one modulus was certainly attention-getting.
My main take-away from the reporting on that paper was that problems can arise when a PRNG is not seeded with sufficient entropy. This feeds into something that I have absolutely no feel for. I need to generate a password. I have three sliders--length, number of symbols, and number of numbers. I slide them around until I'm happy, while watching a dozen or more candidate passwords flash before my eyes.
Is 1Password dipping into /dev/random (or CryptGenRandom or the like on 1P/Win) repeatedly during this process? If it is, have I just materially depleted the system entropy pool? How would I know? And would there be any practical implications whatsoever?Flag 0 -
The short answer is that the rate at which we pull random numbers from system tools doesn't make a dent in the system's ability to provide quality randomness.
Ultimately the source is /dev/random, but it is managed through higher level tools.
Because the entropy that you get from physical measures contain substantial biases, /dev/random isn't just a collection of those measures. What it actually does is hash those measures (along with the output of /dev/random) to create internal entropy pools. Data from those pools are then used to seed a cryptographically secure PRNG. Reseeding takes place at least once every half second.
You would have to pull bits from /dev/random extremely quickly to ever worry about running it down. It only becomes an issue for people running statistical simulations, who need enormous amounts of statistically random numbers very quickly. Fortunately, those applications only require that the data meet certain statistical properties, but not need cryptographic security (unpredictability), so they can just seed a high quality PRNG without needed to slurp much from /dev/random.
Cheers,
-jFlag 0 -
Thanks for the explanation, Jeff. But I'm still not clear on what happens when I'm generating a password and hit the refresh button to see a different suggestion. Is it deterministic (just turning a PRNG one more crank) or not? [url="http://forum.agilebits.com/index.php?/topic/6781-feature-request-diceware-in-password-generator/page__view__findpost__p__55175"]My process[/url] for generating a diceware-style passphrase with 1Password involves using the refresh button to "re-roll the dice" for the next word. If those rolls are not fully independent, then my passphrases may not be as strong as they seem.
If (when?) a passphrase generator is added to 1Password, this particular concern will become moot, but I'd still be curious.Flag 0 -
Ben,
You are asking the wrong question. The question "is it a deterministic sequences" has the answer "if you are drawing few then thousands of bits per second it is entirely non-deterministic, but if you are drawing faster then some small portions of the sequence may be kinda-sorta deterministic, but still fully appropriate for all cryptographic purposes."
The question "is the randomness I get from 1Password's password generator secure enough to drive diceware password generation" then the answer is "yes, the randomness is more than adequate assuming that you appropriately address the fact that you are just getting strings".
Really, you shouldn't be using the 1Password generator as you do. It's entropy is fine, but you are making things too complicated and you have a real chance of introducing error in your process of using the strings (not random numbers) that the Generator produces as inputs to something else.
A great Diceware generator is available at [url="http://xkpasswd.net"]xkpasswd.net[/url]. Obviously you don't want to use a tool online, but from there you can download the perl module used for this.
If you simply want to get, say, 8 bytes of randomness on your Mac, just use the command
[CODE]openssl rand -hex 8[/CODE]
in a Terminal window. That will give hexadecimal output. Suppose you get
337a1597247a0d33
To convert that to decimal you would use
[CODE]printf '%d\n' 0x337a1597247a0d33[/CODE]
(Note that you have to add the '0x' before the number).
That will get you
3709300981989248307
Note that the leading digit of that number will not be uniformly distributed between 1 and 9.
Ben, I think it is great that you want to explore these kinds of things and tinker with them. But if you are really concerned about doing it right, don't roll your own. If your goal is to simply have fun with this stuff, then by all means continue.
Cheers,
-jFlag 0 -
Jeff—
I am a tinkerer, but I use the tools I know. Thanks for pointing me to openssl.
I don't like your suggestion of converting hex to dec, though. I have a gut sense that [i]none[/i] of the digits in a hex > dec conversion (or a hex > base 6 conversion, which strikes me as more logical than hex > dec) will be uniformly distributed. More physical constants start with a 1 than a 2, more start with a 2 than a 3, etc. The bias is most pronounced for the most significant digit, but it extends all the way down. It's a logarithm thing.
I'm sure there's a rule of thumb for how many leading digits one has to throw away before this bias can be safely ignored, but I don't know it, and I'd rather just avoid the issue.
Seems to me that one could could derive an unbiased series of "dice rolls" from [font=courier new,courier,monospace]openssl rand -hex [i]n[/i][/font] by converting the output string to octal and then tossing all zeros and sevens. Unless [font=courier new,courier,monospace][i]n[/i][/font] were divisible by 3, you'd also have to toss the most significant octal digit.
If one were to discard the dice metaphor and define the objective as randomly picking one word out of Reinhold's word list, just take 13 bits of output from openssl and toss any "roll" higher than 7,775.
But if I were designing a diceware-ish passphrase generator for 1Password, I'd probably dig around for a suitable list of 8,192 words.
Wouldn't you? <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/skype_wink.png' class='bbc_emoticon' alt=':wink:' />
—BenFlag 0 -
[quote name='benfdc' timestamp='1330041113' post='58426']
I am a tinkerer, but I use the tools I know.[/quote]
That's great, Ben. Just as long as you know that you will be limited by the fact that you are not always using the appropriate tool for the job.
[quote]
I don't like your suggestion of converting hex to dec, though. I have a gut sense that [i]none[/i] of the digits in a hex > dec conversion (or a hex > base 6 conversion, which strikes me as more logical than hex > dec) will be uniformly distributed.[/quote]
The base (and conversion between them) has doing to do with my point about the leading digit.
[quote]
More physical constants start with a 1 than a 2, more start with a 2 than a 3, etc. The bias is most pronounced for the most significant digit, but it extends all the way down. It's a logarithm thing.[/quote]
[url="http://en.wikipedia.org/wiki/Benford"]Benford's law[/url] was not the issue. My point about the leading digit was that the numbers that we would get would be uniformly drawn from 0 to 2[sup]64[/sup] or 0 to 18446744073709551616. The leading digit of that will always be 0 or 1 if you keep to all of the significant digits.
[quote]If one were to discard the dice metaphor and define the objective as randomly picking one word out of Reinhold's word list, just take 13 bits of output from openssl and toss any "roll" higher than 7,775.[/quote]
Yes. Note that this utility requires that you specify a number of bytes, so you would have to grab 16 bits, but that is the correct approach.
[quote]But if I were designing a diceware-ish passphrase generator for 1Password, I'd probably dig around for a suitable list of 8,192 words.
Wouldn't you?
[/quote]
Yep!
Cheers,
-jFlag 0 -
BTW, I can see how massaging octal digits out of openssl, or rolling actual dice and recording the results with pencil and paper, would be a more pure process than generating number sequences in 1Password. I can also see how either of those methods would have more geek cred. However, using 1Password strikes me as the [b][i]least[/i][/b] error-prone of the three, as well as the most convenient. Especially with the following refinement: create a pass phrase in a new login record rather than a new password record, saving after each roll. Now the rolls are recorded as password history!
Ease-of-use contributes to security, and 1Password has ease-of-use in spades.
The only advantage that I can see the perl module contributing would be automated word-lookup. If I were tasked with generating a whole batch of pass phrases at once, it might make sense. But I don't think I make a dozen in a year. I'm inclined to stick with 1Password.
But I really do appreciate your insights, Jeff. Thanks!
—BenFlag 0 -
[quote name='jpgoldberg' timestamp='1330054584' post='58433']
That's great, Ben. Just as long as you know that you will be limited by the fact that you are not always using the appropriate tool for the job.
[/quote]
I guess I still don't grasp why it is that 1Password would not be an appropriate tool for generating random digits.
[quote name='jpgoldberg' timestamp='1330054584' post='58433']
[url="http://en.wikipedia.org/wiki/Benford"]Benford's law[/url] was not the issue. My point about the leading digit was that the numbers that we would get would be uniformly drawn from 0 to 2[sup]64[/sup] or 0 to 18446744073709551616. The leading digit of that will always be 0 or 1 if you keep to all of the significant digits.
[/quote]
And my point is that the second digit in your conversion of 2[sup]64[/sup] to base ten is twice as likely to be a 7 as it is a 9, that the third digit is somewhat more likely to be a 3 than a 5, and so on. I think of it as a quantized form of Benford's law.
Converting from hex to octal won't produce this sort of bias.Flag 0 -
Ah. I didn't understand how you were using the strong password generator.
If you are using the generated passwords as parts of a diceware-like scheme, then instead of generating four or five separate passwords, why don't you just generate one really long one and break it up into pieces? Or have I continued to misunderstand your process?
Cheers,
-jFlag 0 -
[quote name='jpgoldberg' timestamp='1330117993' post='58443']
If you are using the generated passwords as parts of a diceware-like scheme, then instead of generating four or five separate passwords, why don't you just generate one really long one and break it up into pieces? Or have I continued to misunderstand your process?
-j
[/quote]
The digit slider on 1Password's random password generator tops out at ten, so one can get at most ten digits per roll. Checking the "avoid ambiguous characters" box knocks out three of the ten possible digits, but occurrences of a fourth must be manually discarded (I toss eights) in order to map the generator's output to the faces of a six-sided die. Four random ten-digit strings will usually yield six or seven diceware words.
Lookup is easy b/c I saved Reinhold's word list into Evernote. Typing a five digit sequence into Evernote's search box invariably pulls up the corresponding diceware word.Flag 0
