Ace ants and ace ants
aid ace ace ace ace ace ants.
Ace ants aid ace apes.
The hungry white ape
aches in the ancient canyon.
Autumn colors crunch.
I'd also thought about having a generic library, that could be used for things like representing hashes/fingerprints etc (think: an alternative to the ssh key ascii art).
While I'd considered poetry (especially using rhyming dictionaries) -- my main idea so far is to just construct grammatically well-formed sentences. With a limited vocabulary, it should be easy enough...
And as touched upon in this post, it might make a nice alternative for verbally communicating 64-128 bits of random data -- say reading out a password while someone across the server room types it into a console.
[edit: eg, using a random haiku:
Hoarse dunes and slim germs
gulp pure ripe foul dead bland sole.
Firm trees bleed short heads.
[edit2: I should add that I considered adding a standard transform to the final password: capitalize the first letter, and terminate with a punctuation mark. It would add nothing to the entropy of the password, but might allow an "insecure" lowercase-only password to pass inane "strength" requirements, by mixing three character classes.]
An interesting fork: http://bcaller.github.io/abbrase/
Some comments: https://news.ycombinator.com/item?id=8059210
Letting users pick their passphrases from a list sacrifices a few bits of entropy in theory, and in practice gives much more usable mnemonics.
I'm not sure grammatical models are a definite improvement over Abbrase's naive bigram method -- part-of-speech constraints can make sentences more awkward than freeform associations.
Having 128 bit passwords feels like overkill. I'm not sure on the precise threat model for sites, but the worst case of someone getting your password hash should be ameliorated by not reusing passwords between sites and the password being stretched properly.
If you're actually deriving encryption keys directly from passwords, you'll probably be okay with 60 bits of password entropy and 30 bits of memory-hard stretching.
I should add, that my idea was to publish an RFC-style standard that worked both ways (from the password to number and back again) -- which is why mapping two letters to 256 bits was nice: it makes for short word lists. It might even, with some care, allow for localizing the actual word list to at least some other European languages (we're really only concerned with the two first letters).
> Having 128 bit passwords feels like overkill.
I agree. However, as a user can't be sure sites properly stretch passwords, I'd say 64-bits feels more comfortable.
For use-cases where one are protecting keys, it'd be good if the password wasn't the weakest brute-force target with too large a margin. Obviously, if you can manage to get 64-bits into a password suitable for everyday use, chaining two together for the (presumably rarer case of) master passwords should be viable.
But even 64 bits is a lot of entropy to be typing in, no matter how you encode it :-/
64 bits --> 6 English words
Basically you remember the haiku but when it comes to typing your password you convert it in an IP address using Hipku.
I guess an IPV6 address makes a really strong password, not breakable using a dictionary.
Any thoughts on the validity of this use case ?
I think the more interesting question is: if you manage to memorize the haiku -- will you be able to retain it longer than the ipv6 address? After typing in the address a few times a day, you'd have it memorized (at least in muscle memory). But what if this was something you either used rarely (passphrase for restoring backups for example). Would you remember the haiku even after you'd forgot the ipv6 address?
But in writing the above, I had to hit backspace at least once -- something that's a bit hard to catch when you're typing blind into a password entry field, like when typing in the pass-phrase for unlocking a LUKS partition, or logging into a console session. Or even typing in a login password in a graphical login manager, like the windows login prompt, or gdm/ldm/xdm etc.
And it also takes time. Especially if you only get it right on your third attempt.
If you use a pass phrase it will be easier to crack with a dictionary attack since at best you will put about 15 words in 64 chars.
Of course if you choose truly random characters you have 7 bits of entropy per character, so you would have the same strength with a 28-character password. But which is going to be easier to remember, 28 random characters or 64 characters of ordinary English?
Without the constraint of fitting an IPv6 address into a haiku, you wouldn't have to accept these compromises. I think it would be better to generate passwords that were a little longer (while still covering a 128 bit space) but much less ambiguous and easier to remember.
It would be pretty easy to do.
Let's use the two most forthcoming examples on hand, that is: the IPv6 address from this article's demo, A = 29A1:A600:F19B:B703:7080:5387:3685:A2AF, and the diceware example from xkcd/936, B = correct horse battery staple. Using the Shannon entropy calculator, we find that A has entropy H(X) = 3.55397. The same analysis of B returns H(X) = 3.49468.
Now that's Shannon entropy which calculates the entropy of an outcome in relation to itself, and not the entropy of an outcome from a set of potential outcomes. To do that, we might start with analyzing the number of potential outcomes an IPv6 address can take (340 undecillion) versus the number of words on our diceware list (~7,776 English words) by the number of words our diceware passphrase potentially uses.
In the case of IPv6, you have a 'finite' number of combinations, albeit of fixed length, whereas the unfixedness of diceware means that, theoretically, the scheme scales upward into infinity. That's probably not practical, and one could simply add additional sets to an IPv6 address in order to remove that advantage. So, where does that leave us?
Well, I'm not sure that I'd like to say, but at least I can examine things this way: using an IPv6 address is probably secure, but is the added overhead of a translating agent between your memorization utility and password input worth it? At least, when compared against something like a four word diceware passphrase, it seems the entropic gains perhaps aren't worth the additional computational overhead.
Another issue is that nearly all terminal emulators are (so far) too stupid to auto-highlight an IPv6 address on double-click. They all break on : -- highlighting only 16 bits of the address. Annoying.
> -cc characterclassrange:value[,...]
> This sets classes indicated by the given ranges for using in selecting by words. See the section specifying character classes. and discussion of the charClass resource.
(I haven't tried using this myself.)
aches in the ancient canyon.
Autumn colors crunch.
jumps in the ancient mountains.
Autumn colors rest.
yawns in the wind-swept wetlands.
Autumn colors blow.
haikus? Even if random?
Must be Hacker News.
(not my actual IP)
And there is no central Internet Corporation for Assigned Haiku. This is what namecoin was meant to be.
Chilled apes and fat sprats
aid bleak brave prone ace ace ants.
Ace ants aid sharp beaks.
Um, yes there is. It's an address; you get your address space from your upstream AS (probably your ISP), they get it from their RIR, and they get their addresses from IANA.