I'm learning this along with you. But this is what I think I know so
far. If you do a test in the message box:
encrypt "mysecret" using "aes256" with password "mypass";put it
You get this:
Salted__«!óÈ<cr>/rm55ı it @ˇrȨßQ -- (there's a return in there)
The salt is prepended to the encrypted value (the "hash") so the
receiver knows what it is. The dictionary says that the salt and the
password are combined and scrambled before the encryption is actually
done, thus making the password longer, more random, and more secure.
Without the password, an observer can't decrypt the string. They need to
know both.
Except...hackers have provided lists of all possible combinations of
salted passwords up to 14 characters long ("rainbow tables".) So you
don't want to use short combinations or common passwords or it might
show up in one of those lists. (I assume if you have a very long and/or
random password then it would be okay to have a short salt, or vice
versa, since the two are combined.)
Brian says that the default random salt is short (8 chars) and Kee says
it is safest to provide 32 chars or more. So instead of letting LC
auto-generate a salt, you could provide your own. Bob said he does that.
If you decide to strip out the salt value from the front of the
encrypted string, then your receiver would need to know what it is.
Kee says it is common for online services to store a unique salt value
for each user, along with the encrypted string that was generated with
that salt when the password was first created. The password itself is
not stored. When a user logs in, the service looks up their salt value,
uses that salt to encrypt the password the user just sent, and compares
the computed one to the one stored in the database. (Since no actual
passwords are ever kept, breaches or employees can't know what they are
either.)
In any case, the salt alone is not enough to do decryption. Kee says a
long enough salt makes decryption virtually impossible because the
number of scrambled combinations becomes astronomical, too many to
pre-compute.
That's what I've pieced together, I welcome any corrections. This has
been a useful thread because I had a vague idea of how it worked but not
many particulars.
On 6/6/18 10:37 PM, prothero--- via use-livecode wrote:
Hmmm....
If the salt is included in the encrypted text, doesn’t that enable anyone who
intercepts it to decrypt it more easily, invalidating the purpose of using the
salt in the first place.
Or, if the server decrypting the text uses a standard, but secret, salt that is
known by both parties, it seems more reasonable to me.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
