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. _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
