[ANN] lithcrypt - A library for encrypting and decrypting byte slices using a password.

[Richard Lyman]

This is the first time I've written code for encryption/decryption, and it was quite fun.

Because of that, it's entirely possible I've made some rookie mistakes.

I'm very interested in any suggestions about making the encryption/decryption process more stable or secure.

For example, the default key size used when I generate the key through scrypt is 32 bytes. If I understand the process correctly, that means using AES-256... and I've read[1] that AES-256 may not be much better than AES-128 even though it takes longer. Would a switch to a smaller key size, resulting in higher speed, still leave this libraries defaults as secure?

I've added this on github to help facilitate feedback: https://github.com/richard-lyman/lithcrypt

[1] - http://www.schneier.com/blog/archives/2009/07/another_new_aes.html

[Jeff Hodges]

For the archives, here's a very good solution to this same problem done by experts: <http://godoc.org/code.google.com/p/go.crypto/nacl/secretbox> and <http://godoc.org/code.google.com/p/go.crypto/nacl/box>.

(This isn't a call-out. Security is hard and important to get right, so providing folks with known good solutions while posting up new ones is a good idea.)

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Maxim Khitrov]

Nothing wrong with this as a learning exercise, but the general advice
is to never invent your own encryption schemes. Use existing
libraries, such as nacl in go.crypto [1]. A few notes from a quick
code review:

* You don't need a 1024-bit salt (128 bytes); 128 to 256 bits would be
perfectly sufficient.

* If this is meant to be used as a library, you don't want to
fmt.Println errors and then call os.Exit. Return an error to the
caller instead.

* rand.Read in getRandom is not guaranteed to fill the provided slice.
You need to use io.ReadFull(rand.Reader, result).

* encoding/binary would be a much better way of storing encryption
parameters in the []byte.

* Decrypt will panic if the provided payload is too short. This should
probably be an error.

* If you want, try adding authentication using Encrypt-then-MAC mode,
which should be very easy to do with your existing code.
Authentication is required to prevent an attacker from modifying the
ciphertext [2].

I don't remember what the performance difference between AES-128 and
-256 is, but once Go 1.1 is released, both should take advantage of
AES-NI on CPUs that support these instructions. After that, the
bottleneck will likely be the chaining mode (try benchmarking CFB vs
CTR, I think the latter is faster). In terms of security, I don't know
what the current consensus is.

- Max

[1] https://code.google.com/p/go/source/browse/nacl?repo=crypto
[2] https://en.wikipedia.org/wiki/Authenticated_encryption

[Péter Szilágyi]

Hello,

256 bit is significantly slower than 128 bit. I've attached a chart for information purposes run on a T9400 with OpenSSL. Please don't reuse it elsewhere.

Regarding AES security, 256 bit if far more secure than 128, and 128 bit is more than enough, unless you have some extremely sensitive stuff (for the reference, there is one attack that targets AES-256, but that requires a handful of related keys, so if your keys are random, you're all set).

With regard to the AES mode of operation, CTR is parallelizable whilst CFB is not.

Cheers,

  Peter

[Damian Gryski]

If you need cross-language support, https://github.com/jedisct1/libsodium has a list of compatible implementations.

Also, http://keyczar.org from the Google Security Team has C++/Java/Python support, and (shameless self-promotion) Go support at https://github.com/dgryski/dkeyczar .There is also a C# port at https://github.com/jbtule/keyczar-dotnet .

Damian