refactor(randwords): remove

[ee7]

This was unused, and the word list needed better filtering to be viable.

[viega]

As discussed, I support the removal, though there's a stray 'endif' removed that is not related; I didn't check if that affects compilation, but I expect it would.

[miki725]

cc @drraid you had some ideas how to generate better password for co-sign vs base64. Not sure if cleaning up random words to use for password generator in chalk would make more sense

[viega]

Why is base 64 a problem?

…

On Wed, Apr 3, 2024 at 10:53 AM Miroslav Shubernetskiy < ***@***.***> wrote: ***@***.**** commented on this pull request. cc @drraid <https://github.com/drraid> you had some ideas how to generate better password for co-sign vs base64. Not sure if cleaning up random words to use for password generator in chalk would make more sense — Reply to this email directly, view it on GitHub <#64 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABELGQNPU3WYC6EIVOT36Z3Y3QJVLAVCNFSM6AAAAABD7WH5RGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSNZXGA4DGOJQGQ> . You are receiving this because your review was requested.Message ID: ***@***.***>

[miki725]

I think @drraid comment came out of the chalk messaging:

https://github.com/crashappsec/chalk/blob/66a5bb4b979e9b94f881abf929363db164cba975/src/attestation/embed.nim#L24-L28

Write this down. In future chalk commands, you will need
to provide it via CHALK_PASSWORD environment variable.

writing down base64 is not ideal I think vs a collection of words so it was mostly a UX thing, not a security issue but he can comment better on his thoughts

[viega]

It would take 5 minutes to migrate to a smaller wordlist with an RFC behind it. Might make sense to do; I’m stuck in meetings but maybe later afternoon will hit you up on slack.

…

On Wed, Apr 3, 2024 at 10:58 AM Miroslav Shubernetskiy < ***@***.***> wrote: I think @drraid <https://github.com/drraid> comment came out of the chalk messaging: https://github.com/crashappsec/chalk/blob/66a5bb4b979e9b94f881abf929363db164cba975/src/attestation/embed.nim#L24-L28 Write this down. In future chalk commands, you will need to provide it via CHALK_PASSWORD environment variable. writing down base64 is not ideal I think vs a collection of words so it was mostly a UX thing, not a security issue but he can comment better on his thoughts — Reply to this email directly, view it on GitHub <#64 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABELGQKVARG5XXH6VAMNIFLY3QKKFAVCNFSM6AAAAABD7WH5RGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZUHA2TKOJTHA> . You are receiving this because your review was requested.Message ID: ***@***.***>

[ee7]

If we did want to move to a smaller wordlist instead, the EFF wordlists are pretty good for some applications:

We based our list off of data collected by Ghent University's Center for Reading Research. The Ghent team has long studied word recognition; you can participate yourself in their online quiz to measure your English vocabulary. This list gives us a good idea of which words are most likely to be familiar to English speakers and eliminates most of the unusual words in the original Diceware list. This data also includes "concreteness" ratings for each words, from very concrete words (such as screwdriver) to very abstract words (such as love).

We took all words between 3 and 9 characters from the list, prioritizing the most recognized words and then the most concrete words. We manually checked and attempted to remove as many profane, insulting, sensitive, or emotionally-charged words as possible, and also filtered based on several public lists of vulgar English words (for example this one published by Luis von Ahn). We further removed words which are difficult to spell as well as homophones (which might be confused during recall). We also ensured that no word is an exact prefix of any other word.

Our long list has an average length of 7.0 characters per word, and 12.9 bits of entropy per word, yielding an efficiency of 1.8 bits of entropy per character. Our short list has an average length of 4.5 characters per word, and 10.3 bits of entropy per word, yielding 2.3 bits of entropy per character. Our typo-tolerant list is much less efficient at only 1.4 bits of entropy per character. However, using a future autocomplete software feature, only three characters would need to be typed per word, in which case this would be the most efficient list to use at 3.1 bits of entropy per character typed.