Re: netrc.el now supports encoded files

[Simon Josefsson <jas@extundo.com>]

"Steven E. Harris" <seh@panix.com> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> I'm not sure the current netrc.el approach should be advertised as
>> secure, there is more to file encryption than using some block
>> cipher in CBC mode, and deriving the key and iv from a password. It
>> is more like obfuscation. OTOH, obfuscation is what people seem to
>> want.
>
> Now I'm confused. If encrypting the file with a symmetric cipher
> doesn't count as "secure," what more would it take to make this system
> secure? What's the difference between obfuscation and security in this
> case?

I think one attack the current approach doesn't cover for is a
chosen-ciphertext attack.  In other words, the encrypted data is not
integrity protected.  So the attacker can replace, e.g., the final
encrypted block without being detected.  Incidentally, in the authinfo
format, the password is often the last data, so the corruption caused
in CBC mode by replacing a block doesn't have to occur.  To finish the
attack, the decrypted (garbage) password has to be leaked somehow, but
this isn't completely unlikely.  Another attack is cut'n'paste of
cipher blocks.  Consider if the user has two accounts, with a 8
character password (i.e., one block length), one on a secure server
(i.e., SSL) and one insecure (i.e., cleartext LOGIN), and the insecure
one is listed first in the .authinfo file -- the attacker can replace
the last block with the one read for the first server, thus causing
the user to send the password for the secure server to the insecure
server.  When Gnus is about to contact the secure server, it will only
read garbage in the file (because CBC mode propagate errors), but then
it may be too late.

I believe gnupg uses integrity protection, that counter these
problems.