We should probably hop on the cryptography list: http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography I've cc'd it for now.
I still use the PasswordHashingFFI code on squeak/pharo and GemStone. Its pretty basic, but useful. With libxcrypt installed, & on linux, it lets a user hash passwords using bcrypt or SHA-512 (but the password hashing version). A primer on why you'd want to do that is here: http://codahale.com/how-to-safely-store-a-password/ . Another good, slow, password hashing algorithm is scrypt (https://en.wikipedia.org/wiki/Scrypt) but we don't have an FFI library for it yet. In addtiion to Hernan's Application Security project Pierce Ng has some projects he mentions on his blog: http://www.samadhiweb.com/tags/cryptography
Blowfish is a 2 way encryption algorithm which allows someone to encrypt something and then decrypt it later. The version I wrote only encrypts an 8 byte block at a time. Anything longer looks encrypted but isn't. To do longer things someone would need to add code that does cipher block chaining (CBC) (e.g. https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher-block_c…) I never added the CBC code because I wrote the Blowfish code while investigating having a Smalltalk bcrypt password hashing implementation. Bcrypt uses blowfish while hashing passwords for long term storage. The Smalltalk implementation ended up being more than 5,000x slower than the FFI version and not usable in practice. From my point of view right now the Blowfish code shouldn't be used for anything without adding the CBC code and even then a person may be better off using a newer algorithm than Blowfish for 2 way encryption because of both hardware and algorithm advances (e.g. the NaCl library you mention). That being said the Smalltalk Blowfish implementation does work for 8 byte blocks and is only Smalltalk, no FFI.
I think its a good idea for some tidying in the Cryptography ecosystem, but don't have a strong idea of what the end state (packages and their location on the internet) should be.
Hope this helps
On Nov 1, 2014, at 11:20 AM, Dale Henrichs <notifications(a)github.com> wrote:
> Paul (@pdebruic),
> Just this week, Sebastian (@HeSe) has blown the dust off the Cryptography project to support his port of Web-Sockets to GemStone.
> Since my inclination is to move projects off of GemSource and onto GitHub when we start active work, I started poking around the current state of Cryptography, since the last time that project had been touched was 4 years ago.
> On SqueakSource there is a Cryptography project that appears to have a newer versions of the Cryptography and PasswordHashingFFI packages. this project has a number of interestingly named packages that may or may not be useful to have ported to GemStone. The Blowfish package is interesting because there's a pretty recent version not to mention the fact that you've got a blowfish project up on github.
> In the pharo universe it seems that there is some recent activity with ApplicationSecurity and Nacl projects.
> I am a little baffled by the lay of the land as there seem to be quite a variety of apis available and I'm not sure which ones apply to which problems ...
> Soo ... I am curious about your thoughts on these various projects and the idea of consolidating the current work on GsDevKit ... part of the trick here is to define the "current work" and also look at where we "should be" ... Of course, I want to support existing packages that are used in existing projects and I'd like to start addressing performance issues ...
> I would like to support packages that are available on Pharo and Squeak and get them ported to GemStone... If GemStone needs to add fundamental capabilities at the image level then now is a good time as we start work on the 3.3 release ...
>  http://seaside.gemtalksystems.com/ss/Cryptography.html
>  #58
>  http://www.squeaksource.com/Cryptography.html
>  https://github.com/pdebruic/blowfish-smalltalk
>  http://www.smalltalkhub.com/mc/hernan/ApplicationSecurity/main
>  http://www.smalltalkhub.com/mc/tonyg/Crypto-Nacl/main
> Reply to this email directly or view it on GitHub.