headers
Ralf Hauser | 5 Jan 2004 14:06
Picon
Picon

filenames of encrypted attachments visible ? How hard would it be to hide?


To my understanding,

If I send a message with attachments, the attachment filename is visible
without cryptanalysis.
Would it be hard to give the encrypted file a random name and only upon
decryption, give it back its real name?

http://www.ietf.org/rfc/rfc2440.txt doesn't appear state anything on this
issue.

Isn't that kind of giving away information that could be easily protected -
or did I miss something?

Rgds
	Ralf

Sample use case: Some investment banker uses PGP and sends around an
attachment with the name "UnfriendlyTakeoverOfListedCorpXYZ.doc.asc" - isn't
that kind of an invitation to insiders?
Sure, it wouldn't be hard to rename the file before sending, but this kind
of negligence is happening all over... and I hope applications like gpg/pgp
could eventually become fool-proof/fail-safe to this level?
Permalink | Reply | 0 comments |
headers
Adrian von Bidder | 5 Jan 2004 14:31
Picon

Re: filenames of encrypted attachments visible ? How hard would it be to hide?

[sorry. ralf, of course I meant to answer to the lists]

On Monday 05 January 2004 14:06, Ralf Hauser wrote:
> To my understanding,
>
> If I send a message with attachments, the attachment filename is visible
> without cryptanalysis.
> Would it be hard to give the encrypted file a random name and only upon
> decryption, give it back its real name?
>
> http://www.ietf.org/rfc/rfc2440.txt doesn't appear state anything on this
> issue.
>
> Isn't that kind of giving away information that could be easily protected -
> or did I miss something?

Hi,

You did miss rfc3156 (PGP/MIME). The structure of these (encrypted) emails is:

============================
From: whatever
To: whatever
Subject: whatever
Date: whatever
Content-Type: multipart/encrypted;
  protocol="application/pgp-encrypted";
  boundary="Boundary-02=_5Plx/pJ9Yq8C9E0"

--Boundary-02=_5Plx/pJ9Yq8C9E0
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian G. Peterson | 5 Jan 2004 14:40
Gravatar

Re: filenames of encrypted attachments visible ? How hard would it be to hide?


Ralf Hauser said:
>
> To my understanding,
>
> If I send a message with attachments, the attachment filename is visible
> without cryptanalysis.
> Would it be hard to give the encrypted file a random name and only upon
> decryption, give it back its real name?
>
> http://www.ietf.org/rfc/rfc2440.txt doesn't appear state anything on this
> issue.
>
> Isn't that kind of giving away information that could be easily protected
> -
> or did I miss something?
>
> Rgds
> 	Ralf

Ralf,

This is totally an implementation detail.

Many mail programs that integrate PGP or GnuPG already *do* obfuscate the
filename, calling it encrypted.dat.asc or data.asc or
somerandomstring.asc.  If the asc file has an embedded filename, any
OpenPGP compatible client should be able to retrieve the file name upon
decryption.
(Continue reading)

Permalink | Reply | 0 comments |
headers
vedaal | 5 Jan 2004 15:10

Re: filenames of encrypted attachments visible ? How hard would it be to hide?


On Mon, 05 Jan 2004 05:06:54 -0800 Ralf Hauser <ralfhauser <at> gmx.ch> wrote:
>
>To my understanding,
>
>If I send a message with attachments, the attachment filename is
>visible
>without cryptanalysis.
>Would it be hard to give the encrypted file a random name and only
>upon
>decryption, give it back its real name?

there is a simple workaround you might be interested in:

armor the attachment (without encryption) and include the armored attachment
as part of the plaintext of the message, and then encrypt the entire
message

not only the filename, but even the fact that you are sending an attachment,

will not be apparent
(although it may be guessed at by the size of the message)

vedaal

Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Grigg | 5 Jan 2004 15:55

cleartext signatures - consistent naming


Searching on the draft 2440bis-09.txt, I find
several variations of the cleartext signature
naming:

    signatures following clearsigned messages.  p48
    particularly important when computing a cleartext signature
    This is used only in clear-signed messages. p49
    7. cleartext signature framework
    another way to clear sign messages ...
    The cleartext signed message consists of:
    ...

It seems that the word "cleartext" is the dominant
form, followed by signing in some appropriate verb
form.

It would be nice if the parts outside section 7
(lines 1,3 above) also used that convention, to
make searching easier.

iang
Permalink | Reply | 0 comments |
headers
Ian Grigg | 5 Jan 2004 16:24

cleartext signed messages - UTF-8 - stripping the whitespace


I'm working on some code that deals with cleartext
signed messages over UTF-8 [1].

In debugging the treatment of UTF-8, I looked at
the definition of mods that OpenPGP does to the
cleartext (paras 3,5) for signature treatment [2]:

    As with binary signatures on text documents, a cleartext signature
    is calculated on the text using canonical <CR><LF> line endings.
    The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
    SIGNATURE-----' line that terminates the signed text is not
    considered part of the signed text.

    ....
    Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of
    any line is ignored when the cleartext signature is calculated.

Here are the questions:

1.  In UTF-8, are there such things as line
    endings that are not of <CR> and/or <LF> form?

2.  Are there UTF-8 whitespace encodings that
    are not in the definitions above?

    I.e., not in "spaces, and tabs, 0x09" .

3.  What was the original deep dark motivation
    for stripping whitespace from the end of lines
(Continue reading)

Permalink | Reply | 2 comments |
headers
Adrian 'Dagurashibanipal' von Bidder | 5 Jan 2004 20:57
Picon

Re: cleartext signed messages - UTF-8 - stripping the whitespace

On Monday 05 January 2004 16:24, Ian Grigg wrote:

[...]
>     Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of
>     any line is ignored when the cleartext signature is calculated.

> 2.  Are there UTF-8 whitespace encodings that
>     are not in the definitions above?
>
>     I.e., not in "spaces, and tabs, 0x09" .
>
> 3.  What was the original deep dark motivation
>     for stripping whitespace from the end of lines
>     anyway?
>
> 4.  Do we care if UTF-8 has some weird whitespace/
>     line endings?

IIRC from previous discussions (I wasn't around for years when PGP was 
introduced to the world...): some mailers (MUAs and MTAs) used to strip 
whitespace occasionally or do other weird things.

Those old mailers would probably either treat all non-ASCII whitespace and 
line-endings as normal characters, or not be 8-bit clean anyway and so cause 
problems in any case. So the answer to (4) is probably a clear no.

cheers
-- vbi

--

--
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ian Grigg | 6 Jan 2004 18:29

Re: cleartext signed messages - UTF-8 - stripping the whitespace


Adrian 'Dagurashibanipal' von Bidder wrote:
> 
> On Monday 05 January 2004 16:24, Ian Grigg wrote:

...
> > 3.  What was the original deep dark motivation
> >     for stripping whitespace from the end of lines
> >     anyway?
> >
> > 4.  Do we care if UTF-8 has some weird whitespace/
> >     line endings?
> 
> IIRC from previous discussions (I wasn't around for years when PGP was
> introduced to the world...): some mailers (MUAs and MTAs) used to strip
> whitespace occasionally or do other weird things.

Thinking about it, I've come across editors and
desktops that do something similar, they add spaces
to the end of lines in arbitrary fashions, and
sometimes modify newlines (take away, add) at the
end of files (but newlines are adequately protected
already in the draft).

> Those old mailers would probably either treat all non-ASCII whitespace and
> line-endings as normal characters, or not be 8-bit clean anyway and so cause
> problems in any case. So the answer to (4) is probably a clear no.

So, the upshot is that only the defined US-ASCII
whitespace chars should be included in the
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Shaw | 12 Jan 2004 20:58

The last word (hopefully) on back-signatures


Apologies for the delay in this.  I've had a lot on my plate recently.
In November, I posted two proposals for comment on the "stolen
signature"/back-signatures problem.  Here now is my final proposal
with the various comments taken into account:

First to briefly recap the purpose for this, there is a minor problem
in the current subkey design where a signing subkey can be taken from
an existing key, and bound to the attacker's primary key with a
binding signature issued by the attacker's key.  The attacker cannot
use this stolen key to issue a signature of course, but can claim that
an existing signature was issued by him.

The proposed fix is to add an additional signature into the mix -
currently we have only a binding signature issued by the primary key
on the signing subkey.  I suggest we add a signature (the
"back-signature") issued by the subkey on the primary key.  This
prevents the attack as the attacker cannot issue this signature, and
thus cannot claim ownership of an existing signature.  The
back-signature design seemed to enjoy greater approval than the other,
as well as having the nice detail that it could automatically protect
signatures issued before the back-signature was added.

The specifics (suggestions - I'm not wedded to this particular
language):

1) Define a new type of signature subpacket that consists of a regular
   signature contained in a subpacket.

    Add to section 5.2.3.1 ("Signature Subpacket Specification"):
(Continue reading)

Permalink | Reply | 2 comments |
headers
Adrian von Bidder | 13 Jan 2004 09:24
Picon

Re: The last word (hopefully) on back-signatures

On Monday 12 January 2004 20:58, David Shaw wrote:
> I have
> code for GnuPG that follows this basic design, and it works well.

Will it be possible to convert existing subkeys? AFAICT, putting the 0x19 
signature in an unhashed packet, this should be relatively painless. (Will 
keyservers properly deal with subkeys with the additional packet suddenly 
appearing?)

cheers
-- vbi

--

-- 
featured product: vim - http://vim.org
Permalink | Reply | 1 comment |

Gmane