Thomas C. Greene
23/12/04, 21:55
This might well affect more than Kmail on Linux, but i don't do windows so i
wouldn't know. I'm dealing with GnuPG 0.9.5, Kmail 1.5.1, KDE 3.1.1, and
kernel 2.4.20, all patched within the past week.
I do hope that this problem has been discussed previously, because if i'm the
first person to notice it, heaven help us. But if it *has* been discussed
previously, well, we've got some useless developers designing e-mail clients.
Here's the deal: i'm using GnuPG with Kmail, replying to an encrypted memo
from an anonymous source, and i've naturally got my paranoia level up. Being
a journo, i can't take any chances, so i don't keep my passphrase in memory.
It's a small inconvenience, but i don't mind. Of course it's a bloody long
passphrase, with plenty of special characters, numerals and spaces (or maybe
not, lol), and i get it wrong way more than half the time (hi Feds); but i
figure, hey, if someone wants to contact the press in confidence, they
deserve every possible precaution.
So i decrypt the incoming message (enter passphrase), and then i reply to it
(enter passphrase again). After numerous tries, i'm there, because, as i
said, i'm very much apt to forget this discombobulated passphrase, which i'm
sure i would forget permanently if there was any serious pressure on my weak
mind to remember it (hi again Feds).
At this point, i'm favorably impressed with Kmail's paranoia level. Really,
that's the kind of thing i like to see.
So i compose my reply, and i'm just about to click the Send button, when i
notice, quite by chance, that the reply is *not* encrypted by default, and i
am not warned about this fact. My reply, and my entire past exchange with
the source, is about to go out in fscking clear text!
I confirmed this behavior by sending encrypted memos between several of my own
e-mail accounts. You can indeed decrypt a memo and reply to it -- with
everything going out in clear text -- without *any* warning.
If you forward an encrypted memo as an attachment, the problem doesn't exist.
You have to enter the passphrase to decrypt the original, before and after
sending. Which is as it should be. If you forward it inline, there's no
option to decrypt the memo whether you want to or not: only the cyphertext is
reproduced, and there's no prompt to decrypt it. Which sucks, but is, at
least, not obviously insecure. (Note that these inconsistencies in behavior
imply a basically flawed design.)
But when you reply to an encrypted memo, there is a ludicrous snafu. (Of
course, you don't have to decrypt a memo to reply to it, and if you fail out
of the pw prompt, only the cyphertext of the original, and the clear text of
the reply, will be sent -- although without any warnings or options. Which
is not great, but not horrible.)
However, if you reply to a decrypted memo, and enter your passphrase when
prompted, you'll receive no warnings about the fact that everything will go
out in clear text automatically after that point.
Well, i'm sorry, but that just won't do. It's simply not good enough.
Fortunately, i caught it, but what if i hadn't?
If the Kmail team can't design a client that knows when decrypted text is
included in a reply, and encrypt it by default, or at least throw up a
warning, well, naive users are going to get hosed. I'm not even close to a
naive user, and i almost got hosed -- and more to the point, my *source*
almost got hosed.
I hope that fellow list members will try this with their crypto product of
choice and e-mail client of choice, and report back. Let's see how
widespread the problem is. There's no excuse for this behavior. It can
certainly be fixed, and, indeed, it should have been fixed ages ago --
unless, by some freak chance, i really am the first person to notice it,
which i very strongly doubt. I assume that this behavior has been observed
many times in the past. So why is it still happening on a recently-patched
system?
While it's always good for us to be paranoid, we shouldn't *have* to be
paranoid when using so-called "security" products. The *tool* should be
paranoid for us, and we should be the ones telling it to slack off.
with palpable disgust,
tom
===============
Thomas C. Greene
Associate Editor
The Register
http://www.theregister.co.uk
wouldn't know. I'm dealing with GnuPG 0.9.5, Kmail 1.5.1, KDE 3.1.1, and
kernel 2.4.20, all patched within the past week.
I do hope that this problem has been discussed previously, because if i'm the
first person to notice it, heaven help us. But if it *has* been discussed
previously, well, we've got some useless developers designing e-mail clients.
Here's the deal: i'm using GnuPG with Kmail, replying to an encrypted memo
from an anonymous source, and i've naturally got my paranoia level up. Being
a journo, i can't take any chances, so i don't keep my passphrase in memory.
It's a small inconvenience, but i don't mind. Of course it's a bloody long
passphrase, with plenty of special characters, numerals and spaces (or maybe
not, lol), and i get it wrong way more than half the time (hi Feds); but i
figure, hey, if someone wants to contact the press in confidence, they
deserve every possible precaution.
So i decrypt the incoming message (enter passphrase), and then i reply to it
(enter passphrase again). After numerous tries, i'm there, because, as i
said, i'm very much apt to forget this discombobulated passphrase, which i'm
sure i would forget permanently if there was any serious pressure on my weak
mind to remember it (hi again Feds).
At this point, i'm favorably impressed with Kmail's paranoia level. Really,
that's the kind of thing i like to see.
So i compose my reply, and i'm just about to click the Send button, when i
notice, quite by chance, that the reply is *not* encrypted by default, and i
am not warned about this fact. My reply, and my entire past exchange with
the source, is about to go out in fscking clear text!
I confirmed this behavior by sending encrypted memos between several of my own
e-mail accounts. You can indeed decrypt a memo and reply to it -- with
everything going out in clear text -- without *any* warning.
If you forward an encrypted memo as an attachment, the problem doesn't exist.
You have to enter the passphrase to decrypt the original, before and after
sending. Which is as it should be. If you forward it inline, there's no
option to decrypt the memo whether you want to or not: only the cyphertext is
reproduced, and there's no prompt to decrypt it. Which sucks, but is, at
least, not obviously insecure. (Note that these inconsistencies in behavior
imply a basically flawed design.)
But when you reply to an encrypted memo, there is a ludicrous snafu. (Of
course, you don't have to decrypt a memo to reply to it, and if you fail out
of the pw prompt, only the cyphertext of the original, and the clear text of
the reply, will be sent -- although without any warnings or options. Which
is not great, but not horrible.)
However, if you reply to a decrypted memo, and enter your passphrase when
prompted, you'll receive no warnings about the fact that everything will go
out in clear text automatically after that point.
Well, i'm sorry, but that just won't do. It's simply not good enough.
Fortunately, i caught it, but what if i hadn't?
If the Kmail team can't design a client that knows when decrypted text is
included in a reply, and encrypt it by default, or at least throw up a
warning, well, naive users are going to get hosed. I'm not even close to a
naive user, and i almost got hosed -- and more to the point, my *source*
almost got hosed.
I hope that fellow list members will try this with their crypto product of
choice and e-mail client of choice, and report back. Let's see how
widespread the problem is. There's no excuse for this behavior. It can
certainly be fixed, and, indeed, it should have been fixed ages ago --
unless, by some freak chance, i really am the first person to notice it,
which i very strongly doubt. I assume that this behavior has been observed
many times in the past. So why is it still happening on a recently-patched
system?
While it's always good for us to be paranoid, we shouldn't *have* to be
paranoid when using so-called "security" products. The *tool* should be
paranoid for us, and we should be the ones telling it to slack off.
with palpable disgust,
tom
===============
Thomas C. Greene
Associate Editor
The Register
http://www.theregister.co.uk