Question about use of --cipher-algo AES & --openpgp

[Peter Lebbing]

I started writing this before HHH's last post. I'll trim it but some of
it could give insight.

Henry Hertz Hobbit wrote:
> I followed what some people were saying, and it appears that this is
> not the case!  Further, there is NOTHING in the RFC indicating whether
> we have that or not. In fact that RFC says absolutely nothing about
> a FILE header at all. If we don't always have at least three contiguous
> bytes some place within what could be considered to be the header
> (anything from 6 bytes on up to 32 or even 64 bytes) then we basically
> have nothing to grab onto to give to the file command.  It doesn't stop
> a lot of people from doing it though. The more I read the RFC, they
> just dumped the idea of having a file header entirely. That means you
> can probably kiss the idea of something like file using the magic
> database telling you that you have an OpenPGP file goodbye.  That is
> why I said what I said.

The RFC is very clear on what could be the first bytes. OpenPGP messages
and alike don't have a *file header* but they do have a packet header
and only a limited set of packets can be the first packet of the file. I
did notice something: Exporting secret keys is handled in the RFC, as is
best shown by the existence of the "BEGIN PGP PRIVATE KEY BLOCK" ASCII
Armor option. However, in chapter 10, it is omitted. But logical
thinking applies the rule that was mentioned somewhere else: a secret
key is a public key with extra luggage.

> Second, if you are on a Unix system, the following man command should
> tell you where your magic files are:
> 
> man magic
> 
> On most Linux systems, they will be in /usr/share/file
> I wrote to the group about that.  Read that and this before responding.
> BUT PLEASE RESPOND OUT OF GROUP.

Well as long as it is about identifying OpenPGP files I think it will be
on-topic in this group, the moment it moves to discussion about the
exact magic entry (and how good it is, considering false positives), it
becomes off-topic. If I'm wrong, someone may correct me.

> I think the whole OpenPGP standard just chucked the idea of a file
> header goodbye.  There is nothing to prevent them from doing that,
> but it isn't a good idea.  

Though I agree, you should understand where this format comes from. PGP,
starting from version 2.x! To be able to be somewhat backwards
compatible (parsing and creating), they based the whole format on what
PGP used. At least, that's my interpretation, I wasn't involved in
making the OpenPGP standard :).

OpenPGP messages don't have much to go on to identify them. But I tried
to make a recognition for your interest, symmetrically encrypted
messages with no "asymmetric recipients", only one or several passwords.
For this I just used the RFC, not even experience to go on. Other people
might see an error. However, my conclusion is that it cannot be done
with the extremely limited options of 'file'. For a very probable
packet, I need to match values ranging over 5 bytes. Since you can only
do one test, and some bytes can range over a lot of possibilities, I'd
need a numeric test with AND-masking applied. But only strings can be
matched on *5* bytes, and they can't be masked.

Here's how I recognise symmetrically encrypted messages:

These begin with either a Symmetrically Encrypted Data Packet
(deprecated, compatibility) or a Symmetric-Key Encrypted Session Key
Packet. There is one catch: it's conform spec to compress the entire
message. But let's suppose the implementation is nice enough to only
compress the embedded data of the message. Even then we run into a problem.

A Symmetrically Encrypted Data Packet can, with those basic tests of
'file', only be identified by it's packet tag. It's just not enough:
byte 0 & 0xFC = 0xA4 : Old format, packet tag 9
byte 0 = 0xC9 :	New format, packet tag 9

We get further with an ESK packet, luckily, and this is what you'll see
from recent OpenPGP implementations (right, everybody?).

Option 1:
byte 0 = 0x8C: Old format, packet tag 3, 1 octet length of packet
byte 2 = 0x4: SK-ESK packet version 4
byte 4 = 0,1 or 3: S2K specifier

Option 2:
byte 0 = 0x8D: Old format, packet tag 3, 2 octet length of packet
byte 3 = 0x4: SK-ESK packet version 4
byte 5 = 0,1 or 3: S2K specifier

You could continue the list for larger packet length specifiers (like
someone already pointed out, a small packet can still be specified with
a long specifier with leading 0's), new format packets, for public key
ESK packets, etcetera. If we could match more bytes in one match then we
would have at least 3 bytes identifying a file positively; that's fairly
okay I think. If this where possible:

0  belonglong&0xFF00FF00FC000000  0x8C00040000000000  OpenPGP File
0  belonglong&0xFF0000FF00FC0000  0x8D00000400000000  OpenPGP File

We'd match both options (with the added possibility of undefined S2K
specifier 2, but let's keep it simple).
However, then we run into a problem with new format packets, where the
structure depends on the value of the 2nd byte in the file. The real
solution obviously is more than 1 test.

When I started this, I hoped it'd be possible to match the file. I think
I've established though that it is impossible, which is also worth a bit.

Greets,

Peter.