Re: Re: kwallet crypto misuse

[Daniel Kahn Gillmor <dkg () fifthhorseman net>]

On 01/02/2014 08:03 AM, cve-assign () mitre org wrote:
> > http://gaganpreet.in/blog/2013/07/24/kwallet-security-analysis/
>
> > KWallet uses QDataStream, which encodes QString objects (used in
> > KWallet maps) as UTF-16. So, the string "abcd" will be stored as
> > "\0a\0b\0c\0d", which gives four bytes of information per block.
>
> Does anyone know whether the KWallet user interface could make it
> possible to enter passwords containing 16-bit characters (i.e.,
> characters that cannot be represented using 8 bits)? If that would not
> be possible, then this issue could potentially qualify for an
> additional CVE assignment.

according to its man page, kwalletcli itself assumes strings are input
at UTF-8.  This is not exactly "16-bit characters", but it's certainly
possible to input characters that are beyond unicode codepoint U+7f (or
U+ff if you prefer that limit).

kwalletaskpass also uses whatever keyboard entry mechanism your X11
session is configured for, and can easily accept whatever characters you
can generate with your keyboard -- much of the world uses keyboards
where at least some key combinations (e.g. €, which is U+20AC) generate
characters outside of the standard 7-bit ASCII range.  I had no trouble
entering a passphrase with ♥ (U+2665) just now.

Of course, none of this suggests that the cleartext of these strings is
evenly distributed bitwise (or byte-wise).  It clearly isn't.  That
said, very little cleartext *is* high-entropy in this way.  Do you think
MITRE or other folks should be recommending pre-whitening the strings
before encrypting them (e.g. by compressing them before encrypting)?
compressing before encryption smells like a possible gateway to
something like a CRIME attack in some circumstances, so i think this
proposal in general might be riskier than we'd like.

Regards,

        --dkg

Attachment: signature.asc
Description: OpenPGP digital signature