What's the best simple way to encode Wordle's 5-letter solutions? Go-to would normally be rot13, but that reveals a lot about the word - e.g. if it has any repeated letters.
This is actually a really good problem. How to keep secrets in javascript from browser clients? Most simply don't bother and store every thing server side. But for games like wordle, if you wanted it to be pro level multiplayer competitive, you'd need some punk-busting tech in there ;)
Wouldn't you want to not give the client any information about the correct answer? I would think you would want to have a `POST` command that gives you the encoding guesses if you truly want to keep it out of the browser.
I'm thinking more about just casually writing it down e.g. in an email or FB post - the word for this day was "MROEN" - where the reader could decode MROEN easily, but just knowing MROEN wouldn't leak information. And this is more an abstract question than something with a practical use case.
If the client/reader can easily decode it then a motivated cheater/attacker can easily decode it.
Something like homomorphic encryption or a trusted enclave on the client could work here but unless there's money involved that's probably gross overkill.
I'd go with the server-side solution and API personally but if I had to pick a mechanism for client-side I'd probably do something like AES encryption with a generated key. The actual secret would look like garbage and the key wouldn't show up anywhere on the wire so the attacker would have to actually reverse engineer the key generator.
All that said most of the "attacks" I've seen on the wordle problem just optimize the guessing strategy which is way easier than trying to figure out de-obfuscation of the secret.
Pick an accesible online dictionary. Then use a pattern like the following:
- Lookup the definition of the word for the day. Take the first word in the definition.
- Lookup the definition of that word. Take the first word in its definition.
- Repeat, maybe?
- Use the first word in the definition as the key.
Easy to verify but hard to reverse.
You could probably just split the word up with random gibberish letters in between. Easy enough to write and takes time to figure it out if there's any pattern.
Maybe you could implement a provably-fair system similar to bitZino?
It just uses SHA256, you share the hash and at any later time prove fairness by letting the user rehash the secret themselves to compare against the original.
Do you need the whole solution or just a way to validate answers against them? The first n characters of a hash would work for the latter. For the former I'd encode it into something like base-122[0] or something else equally esoteric.
For simple sharing without giving it away, what about a RotN where N starts at an arbitrary value (13, for example) but increments for each successive character?
ALPHA
becomes
NZEXR
This way, repeats become opaque. Seems clear enough to share in the clear where _breaking_ the cipher isn't a big concern, just immediately recognizing the answer or patterns in it, is.
15 comments
[ 3.1 ms ] story [ 42.6 ms ] thread[1] - https://github.com/c9fe/txtmode.git
Something like homomorphic encryption or a trusted enclave on the client could work here but unless there's money involved that's probably gross overkill.
I'd go with the server-side solution and API personally but if I had to pick a mechanism for client-side I'd probably do something like AES encryption with a generated key. The actual secret would look like garbage and the key wouldn't show up anywhere on the wire so the attacker would have to actually reverse engineer the key generator.
All that said most of the "attacks" I've seen on the wordle problem just optimize the guessing strategy which is way easier than trying to figure out de-obfuscation of the secret.
It just uses SHA256, you share the hash and at any later time prove fairness by letting the user rehash the secret themselves to compare against the original.
Provably Fair Shuffling Through Cryptography
https://archive.is/qwImN
https://datatracker.ietf.org/doc/html/rfc7516/
[0]http://blog.kevinalbs.com/base122
ALPHA
becomes
NZEXR
This way, repeats become opaque. Seems clear enough to share in the clear where _breaking_ the cipher isn't a big concern, just immediately recognizing the answer or patterns in it, is.
Choose an arbitrary length plaintext (8-10 characters would suffice), encode it with the given word as the key.