Am 15.07.2013 um 22:42 schrieb Mariano Martinez Peck <marianop...@gmail.com>:
> Ahh another question, sorry. With this cipher a "salt" would make almost no > sense since I already need a key? > or it make sense to put a "salt" together with the string to ecnrypt? > That is up to you. That is what I was trying to explain to you. You always need a key/secret to encrypt. A salt is just a little more of information that diverses that outcoming value of a hash. A hash is a one way calculation from an input string to an output string in a uniform way. Meaning the same input with same algorithm is always the same output. One way to test a cryptographic string is using rainbow tables. These are big tables consisting of the outcome of hash calculations (fast compare vs. slow calculate). By adding a salt you make it harder to have these tables because you still need to calculate or need to expand the tables of results. But as a salt is an input to the hashing function it only works if the salt is included in the input _and_ the output. Meaning you need to add the salt to the output. In the unix passwd file for instance the first two character of the password hash is the salt. You take it from encrypted string and encrypt the password with the salt to get the output you can compare with the encrypted string (the string with salt stripped off). So in any algorithm you can add a salt and prefix the output with the same salt. The difference between algorithms is how expensive they are to calculate. The best algorithm takes an awful time to compute. In this case if you send the right password it takes an acceptable amount of time to verify (one calculation) but if someone tries to brute force your password it will take way too long to make it feasible to try. To encrypt something between two parties some information needs to be shared. If the algorithm use is shared you need to tranfer the password in cleartext to the second instance and the second instance can encrypt it the same way and compare. Sharing a secret between the parties you can transfer the encrypted string because the other part can decrypt the string and can compare the password (but you have to transfer the secret somehow). In an asymmetric environment where there is a key pair where everything one key encrypts the other key can decrypt you just can share the other key to the second instance and you are able to transfer an encrypted string. So whatever you do you need to decide what approach to use and what information is best to share. If you look on SSL you have everything in combination. First there is an asymmetric key exchange (expensive) that is used to exchange a shared secret. After the negotiation the network will be encrypted using the shared secret which is much less expensive saving CPU cycles. Norbert > > On Mon, Jul 15, 2013 at 5:39 PM, Mariano Martinez Peck > <marianop...@gmail.com> wrote: > > > > Blowfish is a 8 byte block cipher so for shorter strings I'll need to pad > the byte array, and for longer strings I'll need to make it use cipher block > chaining: > (https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher-block_chaining_.28CBC.29) > > > Ok, I imagined something like that. Thanks for the explanation. > For my usecase, I think this is not the more critical thing since I would use > a 8 character password for sure :) > > > > If you change #decryptString:with: to: > > Blowfish class>>decryptString: aString with: aKey > |decryptedData | > decryptedData := (self new ecbDecrypt: aString asByteArray with: aKey > asByteArray ). > ^String fromByteArray: decryptedData asByteArray . > > Then this workspace code should work: > > | enc encryptedString dkey decrString | > key:='mySecretKey'. > enc:=Blowfish encryptString:'12345678' with: key. > encryptedString := enc asByteArray asString. > Transcript show: ' encrypted: ', encryptedString; cr. > decrString:=Blowfish decryptString: encryptedString with: key. > Transcript show: ' decrypted: ', decrString; cr. > > > > Thanks!! That worked. Now...there is no problem with the encoding then? > Because I would need to store/retrieve the string from a file stream...so I > didn't know if I should use a TextConverter or not. > > Thanks in advance, > > > But with the password 'test' it will always fail because I'm not yet padding > the byte array to a multiple of 8 bytes before encrypting it. > > > > Thanks for your patience > > > Paul > > > > -- > View this message in context: > http://forum.world.st/Pharo-dev-Recommendation-for-password-encryption-tp4698499p4698789.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > > > > -- > Mariano > http://marianopeck.wordpress.com > > > > -- > Mariano > http://marianopeck.wordpress.com
