Jeff,
PKCS#5 scheme 2 (PBKDF) with AES is also very popular now. The
particular algorithm for key generation is also mandated by FIPS so it
would likely be a very useful addition.
Regards,
David.
PS. a word of caution, no-one actually mandates how a string gets
converted into a byte array for feeding into PBKDF. I'd recommend
supporting both UTF8 and a straight 8 bit representation.
On 20/04/14 07:14, Jeff Stedfast wrote:
For those that don't already know, since October or so of last year,
I've been working on adding S/MIME and PGP support for my open source
MIME library, MimeKit, using BouncyCastle.
It is at this point very close to being something I'd feel comfortable
with releasing as a 1.0 version. However, there are a few things that
I, as someone who cannot consider himself a crypto expert, need some
guidance on.
First and foremost is the encryption of private keys for S/MIME.
I've written an interface along with a default implementation based on
SQLite for storing X.509 certificates, CRLs, and private keys.
The Background:
My original approach had been to use pkcs12 files for storing this
data, but it soon became too cumbersome due to the need to track
information such a the encryption algorithms supported by the various
mail agents (when you receive a signed S/MIME message, it includes
metadata such as the encryption algorithms supported by the agent that
signed it which you are then supposed to use to determine the most
suitable encryption algorithm to use when encrypting to that user in
the future).
The Question:
Now that the background information is out of the way... the way that
I am currently encrypting the private keys is by using PBE w/ SHA-1 &
3-key 3DES CBC (I think I more-or-less followed what pkcs12 was doing).
With all of the scare surrounding Heart Bleed, I've had to change a
lot of my online passwords and decided to use a password manager. From
what I can tell, some of these password managers use AES + SHA-256 and
it has made me wonder if I should be doing the same?
The argument I've read in favor of SHA + 3-key 3DES CBC is that it's a
fairly strong, yet slow algorithm which is good in the sense that it
would be significantly more expensive for someone to try and use brute
force. While I know enough to understand that DES (especially
encrypting via DES 3 times) is expensive compared to AES, is it the
right choice for this sort of thing?
Thanks,
Jeff
