I can see you replied with the attitude of “I am smarter than you”, but
you just succeeded in showing your incompetence.
Lol.
Your passwords are just 7.6 bits above a system broken 2 decades ago.
Do you realize that means the effort (basically the time and energy) to crack
the password by brute force is *elevated* to the power 7.6? The numbers of
different passwords I gave are right (even though they do not look as "smart"
as their base-2 logarithms, i.e., the related entropies): check them if you
want. Now if you sincerely believe the NSA will waste months of their
computing power to crack your password, here is a solution: use five words.
At one trillion guesses per second, the NSA needs 6118 years to crack the
password (in average, knowing the password is five words in
/usr/share/hunspell/en_US.dic).
I proposed this as a method to memorize a longer password incrementally, and
I suggested 96 bit keys.
Indeed. But your whole method ultimately is to make up and remember four
sentences of four words each, actually more given your example (you need to
remember the words that do not become letters in the password: "has",
"fingers", "in"), plus what words are misspelled and how ("Jand"), plus what
letter to capitalize ("will" with a small "w", "Jand" with a capital J), not
to mention the characters '+' and '/' ('base64' can output them and they are
not easily put in a sentence) and the order of the four sentences.
But I am a nice guy. That is why my post above considered that the
memorization efforts, remembering four characters in the password with your
solution vs. remembering four properly spelled words, are the same in both
cases, hence the entropy comparisons it made.
In Linux /dev/random (/drivers/char/random.c) the raw data from the entropy
sources are passed through the same mixing algorithm used for /dev/urandom.
Moreover, both devices use the same entropy sources.
I do understand that /dev/random and /dev/urandom do the exact same thing
when there is enough noise in the entropy pool... so it only makes sense to
discuss the choice between /dev/random and /dev/urandom when this pool is
empty. Here is an excerpt from 'man urandom', which makes my point:
A read from the /dev/urandom device will not block waiting for more entropy.
As a result, if there is not sufficient entropy in the entropy pool, the
returned values are theoretically vulnerable to a cryptographic attack on the
algorithms used by the driver. Knowledge of how to do this is not available
in the current unclassified literature, but it is theoretically possible that
such an attack may exist. If this is a concern in your application, use
/dev/random instead.
No, it doesn't, because of leap seconds.
Sure. But there still are 31 million seconds in a year (don't you point out
the approximation I make here?, leap years?, etc.), my point.
