AW: [Issue 4145] Master passphrase and encrypted credentials cache

Hi, Gregs,

Von: Greg Stein [mailto:gstein_at_gmail.com]

> On Mon, Mar 26, 2012 at 11:45, Greg Hudson <ghudson_at_mit.edu> wrote:
> >...
> > Unfortunately, there's more complexity in an encrypted password store
> >than you probably anticipated, and it's definitely possible to lose
> >some or most of your intended security properties if you get it wrong.
> >
> > The choice of best cipher algorithm today is very simple (AES,
> > although you'll have to pick the key size from 128/196/256 bits), but
>
> AES-256 in CBC mode was my buddy's suggestion.

I hope that expert really is an expert.

Playing with crypto on your own is never a good idea. And choosing the right algorithm is the least important thing to think about when using cryptography. In most cases, using a crypto algorithm directly plainly is the wrong thing to do.

In one of my former jobs, we tried to design our own crypto protocol (some kind of "lightweight" SSL for UDP and SMS), and it was more than one year of tweaking of a group of roughly a dozen bright people, and in addition several semi-public reviews in some crypto discussion groups until we were sure that we'd shaken out most of the problems.

Some nice writeup for that subject I found some months ago:

"If You're Typing The Letters A-E-S Into Your Code, You're Doing It Wrong"
http://chargen.matasano.com/chargen/2009/7/22/if-youre-typing-the-letters-a-e-s-into-your-code-youre-doing.html

So we really should have good reasons to do it on our own, and then try very hard to make sure that we do it "right". :-)

> > you do need to decide whether you want to be cipher-agile. Basically,
> > if AES becomes a weak choice down the road (and it probably will,
> > though it could be decades), is it better to be able to swap out the
> > algorithm inside the password storage system, or better to just plan
> > to swap out the system entirely for a redesigned one? Either position
> > is defensible.
>
> I'd suggest going with a single choice and leave it at that. It will be
> good into the future, for as long as Subversion has existed in the past.
> Security-conscious people can immediately switch once we provide a new
> subsystem in ten years. Muggles will just naturally migrate as the update
> their svn installation.

We could use some marker-tag or header naming the algorithm, so upgrades can be done in a future-proof way, but actually implementing one single algorithm should be enough.

> > If you don't use CTR mode, you'll need to pick a reversible padding
> > function for the plaintext so that it matches a multiple of the
> > cipher's block size. This is pretty simple.
>
> In my wiki update, I mentioned 32 bits of random prefix (makes dictionary
> attacks even harder), and pad with NUL characters. AES uses
> 16 byte blocks, and keys of 16/24/32 bytes.

Padding with NUL characters opens a known plaintext window at the end of the passphrase. Maybe it's better to pad with random characters.

Hmm, I remember someone saying it's not easy to get crypto right, right? :-)

If there is no existing, well-known and trusted solution we can use (copy), we should at least try to get some review from some crypto experts for the design and the implementation.

Best regards

Markus Schaber

-- 
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com 
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915