User:Nobletrout/PGP/INLINE

PGP / INLINE is a special coding for the encryption and signing of emails by a hybrid cryptosystem. PGP / INLINE-capable mail programs can reliably detect whether the e-mail and its attachments are PGP / GnuPG-encrypted and / or PGP / GnuPG-signed e-mails. PGP / INLINE is specified by the OpenPGP standard in RFC 4880 in section 6.2.

Alternative spellings include PGP-Inline and inline-PGP.

The name itself is not standardized. This format does not standardize the way in which encrypted e-mail attachments are encoded. However, it is possible to manually place several PGP messages in the body of the mail, whereby the recipient then also has to manually extract and decode them individually. Unencrypted e-mail attachments based on the MIME standard can be combined with a PGP / INLINE message. PGP / INLINE encrypts each attachment individually. A disadvantage of this is the unencrypted transmission of the names of the attachments, so that conclusions can be drawn about the content.

A PGP / INLINE mail looks something like this in its raw format: Return-Path:  Delivered-To: empfaenger@example.org Received: from mail.example.org (localhost [127.0.0.1]) by mail.example.org.com (ExampleMailer) with ESMTP id 3D39B2AAA00 for ; Mon, 17 Nov 2008 20:45:22 +0100 (CET) Message-ID: <223049802986@example.com> Date: Mon, 17 Nov 2008 20:45:20 +0100 From: Absender  User-Agent: ExampleMUA 1.0 MIME-Version: 1.0 To: Empfaenger  Subject: PGP/INLINE-Testmail Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit -BEGIN PGP MESSAGE- Charset: ISO-8859-1 Version: GnuPG v1.5.0 (GNU/Hurd) eM3IyLmXvKp7zVTTwEU6Sbws0mUqvi4XwqNTuBwcn/aNQe6lTj+u26Bd7+kmEH02 Lj0tgPsP6+4A5b7Rzbf/I08z12LUJjyVXw4M/rSzJkrcpLN24iB/IcT0g1+HdLJF [...] nGqQbYRqMi64GCZ+4m0cSvQaIF9WOhSQDXR4KndYSc8/jiV2D+Ru5JH8j8Zgih9R fha90PPvd01OPhfrRs/Awt61AvOV9stlO9ZTqO/dozl33FMW =xP1s -END PGP MESSAGE-

Risk of forgery with signed but unencrypted data
PGP / INLINE also supports signing data without it being encrypted. However, only the text content is signed (and thus protected against changes), but not the header lines. This harbors the risk that a clever modification of a header line will change the interpretation or presentation of the text content in such a way that another, but also valid, content is created.

Alternatives
Alternative encodings are PGP / MIME and S / MIME. The format of the encrypted e-mail or attachments is standardized for both alternatives. With both encodings, it is possible to encrypt a message as a whole, i.e. including the attachments. It is therefore difficult to draw conclusions about the content of a mail. However, S / MIME is not compatible with the PGP-based PGP / INLINE and PGP / MIME.