From: Mariano Martinez Peck



On Mon, Feb 17, 2014 at 7:25 PM, Ron Teitelbaum <ron at usmedrec.com> wrote:

Hi Mariano, 

Before I give you an answer, you should never ever ever not even for any
reason, ever, did I mention ever, store a user's password.  You can hash a
password, which means you store the hash value of the password.  You can
make it more secure by salting the hash or embedding your own key to the
hash, or doing a number of other things.  But you should always store an
encrypted hash and never a recoverable password.  The way this works is that
your user knows the password and can generate a hash at any time that you
can compare.  You store the hash of the password to compare.  The reason for
this should be obvious.  You don't want anyone to have access to that
password.  Not even programmers.  Your program doesn't need it either since
the user can generate that hash for you at any time.  It really is all you
ever need to store.

 

 

Hi Ron,

 

Thanks for the advice. I have been warned about this in the past so I am NOT
using this for storing passwords. Instead, there are instVars from certain
objects that are "password protected" because they represent some sensible
data. So these fields need to be encrypted/decrypted. The user needs to
supply a password for editing/viewing them. These fields were
encrypted/decrypted with Blowfish. And the key for the blowfish is the "
SecureHashAlgorithm new hashMessage: aString" of the password used to
protect them...

 

Anyway.... I do need encrypt/decrypt and it should be fast. I have just
tried ARC4 and seems to be fast. I have a few questions:

 

- If I make the ARC4 key larger is it likely to be safer? 

Safer depends mostly on how you use store the key and how you transfer
secrets.  I gave you the largest key for ARC4 so making it larger is not
really an option.  Oops Sorry no I didn't (this is a good example of why
crypto needs to be simple to be used properly!)  use nextBytes: not nextBits
for a larger key.  You may want to use a 40 bit key, see below.

 

Some of the things you need to do are salt your data.  This allows you to
store a different value each and every time the data in encrypted even if
the data itself doesn't change.  Never send the key in the open, it should
also be encrypted (so that the same network packets sent again never open
any locks).  

 

How you store the key is important, but only as important as your security
profile.  For example if you wanted to protect the data against governments,
you are out of luck.  If you wanted to protect your data against large
powerful actors, then you would need to store your password in memory only,
and change it a multiple times a second (by re-salting and encrypting).  If
the program is tampered with or shuts down all the data is permanently lost
in memory.  You could have a master key (stored offline) to recover from
disk.  Now that is an extreme example, but you have to keep in mind that
your program is only as good as your key storage.  If you can store your key
offline and start your system with it, then salt and stretch it for regular
operations, you are pretty secure.  If you just add your key to an ivar on a
class running in smalltalk, you are probably not very secure.  Your security
profile will probably be in between the extremes but it is definitely worth
thinking about.  Two way auth is also a good way to go (like google
authenticator).  I personally like SAML.  It allows you to handle
authentication externally and your program doesn't need to handle secrets.
AD is also another way to add good security to your system without having to
throw the solution all yourself.  

 

- How does ARC4 compare to blowfish from security point of view? Is blowfish
much more secure or not that much?

 

If you really care about the cipher use Rijndael instead.  That is our
implementation of AES.  Blowfish was a contender for AES but was not picked.
It's a very good program but it's not as well reviewed as AES.  When AES was
selected it of course went through a huge amount of review.  It also is the
current back bone of SSL (TLS).

 

RC2 is best if you plan to export your security code (use 40 bit key size).
It is also vulnerable to some attacks but it's still good for most uses
(which is why it's a good choice for export).  Governments like encryption
they can break.  

 

If you can use approved software instead writing your own, you are much
better off.  Using cryptography is not the same thing as implementing it.
Implementing it requires government restrictions, registration, and
regulations.

 

Hope that helps and doesn't scare you off.  Cryptography is really fun, and
very cool.  Just be careful to follow the rules and do things properly.

 

Thanks in advance!

 

 

 

If you are looking for a simple cypher for something other than a password
how about ARC4 from www.squeaksrouce.com/Cryptography 

 

|key cText pText|

key := SecureRandom picker nextBits: 254. 

cText := (ARC4 new key: key) encrypt: 'This is a very secure but meaningless
string' asByteArray.

pText := (ARC4 new key: key) decrypt: cText.

^pText asString

'This is a very secure but meaningless string'

 

It's pretty simple.  To get the plainText back all you need is the key.  

 

All the best,

 

Ron Teitelbaum

 

From: Pharo-dev [mailto:pharo-dev-bounces at lists.pharo.org] On Behalf Of
Mariano Martinez Peck
Sent: Monday, February 17, 2014 4:17 PM
To: Pharo Development List; glass at lists.gemtalksystems.com; The
general-purpose Squeak developers list
Subject: [Pharo-dev] FFI blowfish for encrypting / decrypting [WAS] Re: How
to encrypt a password?

 

 

On Thu, Nov 21, 2013 at 3:53 PM, Paul DeBruicker <pdebruic at gmail.com> wrote:

Mariano Martinez Peck wrote

> Hi Paul, and just to be sure I understand...none of them could work as a
> two-way encryption, right?
> The only one is your Pharo's version of Blowfish but that only works with
> 8
> chars long. Is it like this? Or is there any other two-way encryption?
>
> Thanks!
>

> --
> Mariano
> http://marianopeck.wordpress.com


Yes that's right.  The PasswordHashingFFI stuff is all one way encryption.
Blowfish is two way, and the current implementation only works for 8 byte
chunks.  I stopped working on it when the Smalltalk bcrypt implementation I
wanted proved to be 5000x times slower than the FFI version. Someone needs
to add the CBC part to Blowfish to encrypt longer strings.  I do not know of
another in image two way encryption scheme, but there may be something in
the Cryptography repo.  I'm not sure.

 

Hi Paul,

 

Sorry for the cross posting. 

 

I was using the Smalltalk version of the Blowfish you did to encrypt and
decrypt things. But now I realize it is very very slow for the usage I need.
You seem to have faced the same problem. 

 

I am encrypting pieces of 8 characters long. But I wonder if the decryption
is available as well in FFI version? I see #ffiCrypt:with:   but nothing to
decrypt...

 

Thanks in advance 




 

-- 
Mariano
http://marianopeck.wordpress.com





 

-- 
Mariano
http://marianopeck.wordpress.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140218/244b12a8/attachment.htm