signature verification data

[auto15963931 at hushmail.com]

On Sun, 25 Mar 2012 13:18:37 +0000 Daniel Kahn Gillmor 
<dkg at fifthhorseman.net> wrote:
>On 03/25/2012 02:33 AM, auto15963931 at hushmail.com wrote:
>> When an encrypted file sent to me is both encrypted and signed,
>> when I use a command like this:
>>
>> gpg -o file-out -d file-in
>>
>>
>> I can see the signature verification data appear as standard
>> output, in the terminal, while the file-out contents are 
>separated
>> from it.  Is there a way to have the signature verification data
>> appended to the file-out text message itself or possibly some 
>other
>> way of preserving this verification data and keeping them 
>together?
>> I am referring to the command line interface, but I noticed that
>> GPA also keeps them separated. Thanks.
>
>you can use the --status-fd or --status-file arguments to direct 
>machine-readable signature verification messages wherever you 
>like.
>
>But sending it to the same file as the text is a bad idea.  Don't 
>do it.
>
>For example, here's me dumping the decryption to stdout so that it 
>flows 
>around the message:
>
>0 dkg at pip:~$ gpg --status-fd 1 -d <x >x.2
>gpg: Signature made Sun 25 Mar 2012 09:01:48 AM EDT
>gpg:                using RSA key 0xCCD2ED94D21739E9
>gpg: please do a --check-trustdb
>gpg: Good signature from "Daniel Kahn Gillmor 
><dkg at fifthhorseman.net>"
>gpg:                 aka "Daniel Kahn Gillmor <dkg at openflows.com>"
>gpg:                 aka "[jpeg image of size 3515]"
>gpg:                 aka "Daniel Kahn Gillmor <dkg at debian.org>"
>0 dkg at pip:~$ cat x.2
>[GNUPG:] PLAINTEXT 74 0
>test
>[GNUPG:] SIG_ID chNvlYWvyBS3mjoLtZ3oEC2SQho 2012-03-25 1332680508
>[GNUPG:] GOODSIG CCD2ED94D21739E9 Daniel Kahn Gillmor 
><dkg at fifthhorseman.net>
>[GNUPG:] NOTATION_NAME issuer-
>fpr at notations.openpgp.fifthhorseman.net
>[GNUPG:] NOTATION_DATA 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9
>[GNUPG:] VALIDSIG 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 2012-03-
>25 
>1332680508 0 4 0 1 10 01 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9
>[GNUPG:] TRUST_ULTIMATE
>0 dkg at pip:~$
>
>Here's why this is a bad idea:
>
>Once you've stuck the verification data into the same file as the 
>message, how do you tell which parts are message body ends and 
>which are 
>verification data?
>
>You might assume that all the lines prefixed with [GNUPG:] are 
>from the 
>gnupg signature verification process; but what if the original 
>message 
>contained such lines (e.g. what if you were piping this message 
>through 
>the signature verification process)?
>
>By combining the data you're trying to verify with the results of 
>the 
>verification, you open yourself to pretty easy exploitation from 
>anyone 
>who chooses to craft their message in a certain way.  For example, 
>i 
>could just insert lines in my message that imply a good signature 
>from 
>you, and place a well-formed (but bogus) cleartext signature 
>around 
>them.  Your verification process would emit my data into the file, 
>
>including my fake claims of verification.  Someone scanning that 
>file 
>later will believe that you signed it.
>
>So yes, there's a way to do what you're asking.  But you shouldn't 
>do it.

Daniel, hello.  Okay, I can accept that.  But I have a couple of 
questions still. First, in response to your scenario for the 
deception.  It sounds like a prudent recommendation if the 
intention was to deceive someone else; however, if the goal was to 
have a record only for myself so that I could later review it to 
see whether I had gotten a message that was legitimately signed, 
then my combining them does not seem capable of misleading me since 
the message, if it had been falsified with bogus signature 
information, would also contain accurate information from the real 
process, showing me whether the signature was valid or not.  Would 
it not?  I mean, if there had been no signature in the first place, 
then the validation process I put the message through would 
indicate as much. Nevertheless, I do prefer your suggestion and I 
intend to adopt it in all cases, if possible.

Secondly, I am having a little difficulty getting the signature 
validation information that I need. I can get the information when 
I am decrypting in a single file mode, but not when decrypting in 
batch mode. I need this to work in batch mode. I am working with it 
in a Windows OS. Here is the command I used in decryption of a 
single file:

(dir /b file-in >> status.log) & echo:<password>|gpg --verbose --
status-fd 1 file-in >> status.log 2>&1

Using that command my file is decrypted, and, along with the name 
of the file itself, the signature validation information and 
decryption information is put into the file named status.log.  
Specifically, the information that comes from using "--status-fd" 
as an option does indeed present the signature information needed. 
The reason I use the first part of the command (i.e., dir /b file-
in >> status.log) is so that the name of the file is also put into 
the status.log file, since the information coming from "--status-
fd", so far as I can tell, includes everything I need except for 
the name of the file it is pertaining to.

However, since I need this to work in a batch decryption process, I 
pretty much need to use a command like this (as far as I know 
anyway) within a For loop:

(dir /b %%G>>statuses.log) & gpg --batch --passphrase <password> --
verbose --status-fd 1 %%G >> statuses.log 2>&1

This works fine except that the informationcoming from "--status-
fd" omits the part about the signature.  In other words, this 
option "--status-fd" produces different output in batch mode from 
what it does in single-file mode.  It would great if I could get 
the name of the file being processed without having to use the 
first half of this two-part command, but I cannot see the file name 
without it, neither in batch mode or in single-file mode.

What I need, ideally, is the information provided by "--status-fd" 
option as it appears in single-file mode but while doing the 
process in batch mode, as well as the name of the file itself so 
that I can know which file the information pertains to when I later 
go back to review it.  Any ideas about that would be appreciated.  
Thanks.