newbold
commented
3 years ago Sorry for the delay in responding here. I think the true technical (or rather pedantic) answer to your question is that it's not actually possible to determine if any given payload is a valid cipher until it’s actually decrypted—which is exactly what the site script is doing. When it recognizes a payload as a Salty cipher, it's only because a valid key was also provided and the payload was decrypted successfully with that key. Absent a key, or if the supplied key doesn't successfully decrypt the payload, the script assumes that the payload is plaintext.
This really comes down to my design decision to be clever about offering a single form for both encryption and decryption, and the assumption that people would use the form instead of URLs with things pre-populated. My thinking was that presumably any given end user would know if they're trying to decrypt a known cipher, or if they're seeking to encrypt something new. But you've demonstrated how there are always tons of other valid use cases floating around out there, any any given single design isn't going to always elegantly meet them.
If you're looking to do something where you'd be routinely sharing URLs with pre-loaded valid ciphers and then prompting someone to supply a key, I'd suggest a purpose-built script for just that use case. It'll work a lot better than trying to kludge that behavior into the existing site script. If you'd like me to whip one up for you, just say the word!
If you pass a url-encoded compact salty cipher "blahblah" to the web UI like
?payload=blahblah, before entering the key and pressing "go", the web UI autodetector indicates it's "plain text", not a salty cipher. Is there a way to indicate this correctly even when passing via url param?