Any plans for GnuPG to implement decrypting to RAM?
Just wonder if GnuPG, similar to PGP, would implement decrypting files to RAM rather than swap, or to allow user to pick location. -- Kevin Hilton ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Any plans for GnuPG to implement decrypting to RAM?
On Tue, Feb 05, 2008 at 10:36:41PM -0600, Kevin Hilton wrote: > Just wonder if GnuPG, similar to PGP, would implement decrypting files > to RAM rather than swap, or to allow user to pick location. What does decrypt to swap mean? For that matter, what does decrypt to RAM mean? Decryption: gpg -o /pick/your/own/destination -d file-to-decrypt.gpg gpg -d file-to-decrypt.gpg > redirect-to-a-file gpg -d file-to-decrypt.gpg | pipe-to-whatever-you-want It's in the manual. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Anti-Tempest Fonts, Where?
Hideki Saito wrote: Makes me curious, how relevant is it these days, especially with age of (presumably) lower emission LCD screen? An unshielded monitor cable puts out a lot of RF, regardless of what kind of monitor it's plugged into. LCDs can be Van Ecked, just as can CRTs. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Anti-Tempest Fonts, Where?
Makes me curious, how relevant is it these days, especially with age of (presumably) lower emission LCD screen? On Feb 5, 2008 11:00 AM, David Shaw <[EMAIL PROTECTED]> wrote: > On Sat, Feb 02, 2008 at 06:16:23AM +0100, George Orwell wrote: > > man gpg > > > > the above cmd mentions anti tempest fonts. what does this mean > > exactly? where are the anti-tempest fonts? i've searched the > > net for them and cannot find them. the only mention of soft > > tempest fonts were within a .zip containing image files claimed > > to be for example only. > > > > do tempest resistant fonts exist? > > No. Or at least, not any longer. There was a font package available > a few years ago that was an offshoot of some work done by Markus Kuhn > and Ross Anderson at the University of Cambridge. More recently, they > improved the attack enough that the fonts were no longer effective. > > See > http://www.cl.cam.ac.uk/~mgk25/emsec/softtempest-faq.html > > I'll update the manual so it does not reference the fonts any longer. > > David > > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Hideki Saito ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: can you see any problem with this?
Yes I think I can live with those characteristics of the system. Thanks for your analysis! -Adrian -Original Message- From: David Shaw <[EMAIL PROTECTED]> Date: Tue, 5 Feb 2008 13:50:56 To:Adrian Thurston <[EMAIL PROTECTED]> Cc:gnupg-users@gnupg.org Subject: Re: can you see any problem with this? On Tue, Feb 05, 2008 at 01:28:08PM -0500, Adrian Thurston wrote: > My application is here: > > http://www.cs.queensu.ca/~thurston/fif/ > > I'm encrypting messages and making them publicly available over static > HTTP. Anyone who knows the right URL can grab a message and I don't want > recipients to be identifiable. > > Another issue is that the number of recipients and the size of messages > may both get very large. A single encrypted message is therefore very > attractive. In that case, doing something like this may work for you: gpg -o output.gpg -R recipient1 -R recipient2 -e thefile.txt gpgsplit output.gpg for i in *.pk_enc do cat $i *.encrypted > `echo $i | sed -e 's/\-001\.pk_enc//'` done You'll end up with a directory full of files, one per recipient, and each a valid OpenPGP message, but all of them protected via throw-keyid. I'll leave it as an exercise for the reader to determine which file goes with which recipient ;) Caveats: If Alice and Baker both get a message, and Alice knows which file Baker got, Alice can decrypt Baker's message using her own session key, thus revealing to Alice that Baker got the same message that Alice did. The "non-identifiable" feature with -R (aka throw-keyid) is only as good as throw-keyid is, which is pretty good but not perfect. You may or may not care about these caveats. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Anti-Tempest Fonts, Where?
On Sat, Feb 02, 2008 at 06:16:23AM +0100, George Orwell wrote: > man gpg > > the above cmd mentions anti tempest fonts. what does this mean > exactly? where are the anti-tempest fonts? i've searched the > net for them and cannot find them. the only mention of soft > tempest fonts were within a .zip containing image files claimed > to be for example only. > > do tempest resistant fonts exist? No. Or at least, not any longer. There was a font package available a few years ago that was an offshoot of some work done by Markus Kuhn and Ross Anderson at the University of Cambridge. More recently, they improved the attack enough that the fonts were no longer effective. See http://www.cl.cam.ac.uk/~mgk25/emsec/softtempest-faq.html I'll update the manual so it does not reference the fonts any longer. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: can you see any problem with this?
On Tue, Feb 05, 2008 at 01:28:08PM -0500, Adrian Thurston wrote: > My application is here: > > http://www.cs.queensu.ca/~thurston/fif/ > > I'm encrypting messages and making them publicly available over static > HTTP. Anyone who knows the right URL can grab a message and I don't want > recipients to be identifiable. > > Another issue is that the number of recipients and the size of messages > may both get very large. A single encrypted message is therefore very > attractive. In that case, doing something like this may work for you: gpg -o output.gpg -R recipient1 -R recipient2 -e thefile.txt gpgsplit output.gpg for i in *.pk_enc do cat $i *.encrypted > `echo $i | sed -e 's/\-001\.pk_enc//'` done You'll end up with a directory full of files, one per recipient, and each a valid OpenPGP message, but all of them protected via throw-keyid. I'll leave it as an exercise for the reader to determine which file goes with which recipient ;) Caveats: If Alice and Baker both get a message, and Alice knows which file Baker got, Alice can decrypt Baker's message using her own session key, thus revealing to Alice that Baker got the same message that Alice did. The "non-identifiable" feature with -R (aka throw-keyid) is only as good as throw-keyid is, which is pretty good but not perfect. You may or may not care about these caveats. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Anti-Tempest Fonts, Where?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 George Orwell wrote: > do tempest resistant fonts exist? First, it's not "tempest resistant". TEMPEST is the name of the NSA's standard on Van Eck-resistant hardware. What you're talking about is Van Eck surveillance. I know, I know, PGP Corporation calls it "Tempest resistance". They're wrong, too. Anyway, taking off the pedantry hat... I am unaware of any empirical evidence that suggests PGP's Van Eck-resistant fonts really offer much, if any, security against Van Eck surveillance. If you're dealing with people who are willing to park a van down the block and dedicate a crew of surveillance experts and a few thousand bucks of directional antennas and custom-built FPGAs at you, my best advice is to (a) run away and (b) build a Faraday cage. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iFYEAREIAAYFAkeooC4ACgkQf2XByo0Cu7M8WgDbBHkrkNUpHMFZfykVffOsaTFw 9E3JVJ1mXBHmPgDdEdXJcN3vftBtGKw3va7zIPmNgVS/GmVFShYAWYkBHAQBAQgA BgUCR6igLgAKCRC3APSC/q+BCZ2ECACMdFOEH47rTF03Cm834FWFNnegnGs8UGXD z/uBEtrO212nIBSKXqEfLxL0137dnx8Y9e6NmU4XfxS5DhbpWY2baqiuJcSGVx7S VSQPHffe1QO31ehlWEChHysKQDZRC+TGpyg/d6JWx+QVn8iixq5qB4N9qIRUrLAK SV1pV4kA8TCPVCh/V8VfR77wdTjE4y5/vIn1iXcVpIZyieZUF3/5yYxN9fLU4m8H UJI7BZTd3KU5PnDmA0X/xPbQaf4fITq+BBc22omDsLu5UEdWpXxw/R92J+1+0op7 uoqxqh3Hq51GoIsItirFTGLvLElcYAKBZKHWeeauxktOcnrjwRrH =3//e -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: can you see any problem with this?
My application is here: http://www.cs.queensu.ca/~thurston/fif/ I'm encrypting messages and making them publicly available over static HTTP. Anyone who knows the right URL can grab a message and I don't want recipients to be identifiable. Another issue is that the number of recipients and the size of messages may both get very large. A single encrypted message is therefore very attractive. Thanks, Adrian David Shaw wrote: > On Tue, Feb 05, 2008 at 12:02:48PM -0500, Adrian Thurston wrote: >> Hi, >> >> I'd like to serve messages that have been encrypted to a large number of >> people, however I don't want to reveal the list of recipients so I'm >> going to use --throw-keys. >> >> But speed at the decryption end is a concern, so I thought I would break >> up an encrypted message into packets and when a client requests it serve >> up only the packet that corresponds to the session key encrypted to >> them, then the content packet. I haven't tried it yet, but it seems as >> though it should work. I'd like to know if there is any non-obvious >> reason why it is a bad idea. > > It's hard to really answer this as there isn't enough information to > say one way or another. > > Speaking strictly to your question, and not the "is this wise" > question, if I understand it, you are proposing encrypting to a large > number of people, breaking the resultant encrypted message into many > PKESK packets (one per recipient) and one encrypted packet. Then, > send each recipient their own PKESK plus the encrypted packet. > > So, yes, that would work. GPG even ships with the tools to make such > a message. And it's safe to do so with the caveat that every user > will have the same encrypted message and be able to decrypt it. On > the one hand, no big deal, becuase you sent everyone the same message, > so you clearly wanted them to have it. On the other hand, it gives > Alice the ability to know that Baker got the same message that Alice > did. Whether that is important or not depends on what you are doing. > > Also, given that you are only sending each recipient their own PKESK, > why bother to use --throw-keyid ? It might be easier to just encrypt > the whole message to each recipient individually rather than do all > the packet surgery. > > David > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Safe decryption with GnuPG?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Krzysztof Żelechowski wrote: > GnuPG claims it locks memory pages so that they are never dumped. On systems where that's supported, sure. On systems where that's not supported, it doesn't. Ergo, tread carefully. > (although I am quite surprised > because the requirements are quite obvious to me; > for what is the benefit of encryption > when a bad robot can read over your shoulder?) If your hardware is compromised then you are absolutely screwed, and there is nothing you can do about it. Bang, period, game over, end of sentence, end of discussion. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iFYEAREIAAYFAkeop6MACgkQf2XByo0Cu7OxvwDfeijBBMNF/zNFxk+faY5nERLG 6pT/D0jGRqHUdADfWJNvfqN7oPk1vNRBiXeIyQ0AVoV1BJT9y91soYkBHAQBAQgA BgUCR6inowAKCRC3APSC/q+BCefVB/9hzIe10SvQlTThBAEZoGvD4s4HrIEWyIOo j45mAzB63Z6TZyWwozjQsK8IVN2+TNY4fkOfmZSqo2P3O7Oz3dQ+0VY9FcCV2n1g FqBZ1WuxEYMYJ37cLLbhN2s3fYKoBPW4Cv0atScC9hjeDyB7lUO5Gdm3BVw1XhPd KI8Ke6syImfx1niXgTs3J2ZkkQueUkKvz/yGKeevAP+u8fg9U9NymQnKMlbyxPaf oNkOdm64eJc0NMbA/KLwOoFgEv9CZpbRoZ8LeS9nZ3zpTtA+vlv/kivzR/aTZnR5 t7ttR64NXq5lnQOuiUxq8XyBwWhlmscXPiOg7H6X4QmqF0L7Zqmf =fDSZ -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: can you see any problem with this?
My system can be described as encrypted news feeds. I considered that approach and I like it because it's doesn't require taking apart PGP messages. The problem is that in my system I need the ability to revoke access to any single user. With a session key unique to each message I can just re-encrypt and drop a user. If the session key comes separately I need to ensure that the clients always have the current symmetric key. The easiest way to do that is to just send it with each message. But then I've just got ... well you see :) Adrian Robert J. Hansen wrote: > Adrian Thurston wrote: >> But speed at the decryption end is a concern, so I thought I would break >> up an encrypted message into packets and when a client requests it serve >> up only the packet that corresponds to the session key encrypted to >> them, then the content packet. I haven't tried it yet, but it seems as >> though it should work. I'd like to know if there is any non-obvious >> reason why it is a bad idea. > > At first blush it seems like a case of there being way too much hammer > for the nail you have in mind. > > 1. Compose a single message: "the magic words are... [insert passphrase > here]". > > > 2. Write a script to encrypt each message to each recipient's key and > mail it to them. If this takes more than 20 lines of Perl, something's > wrong. > > 3. Compose your future traffic as normal, but symmetrically encrypt it > and send it on to your recipients. > > > ... Admittedly, I don't know the particulars of your environment, so > this might be inappropriate for your needs. But it's the first thing > that comes to mind as I read your description of what's happening. > > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: can you see any problem with this?
On Tue, Feb 05, 2008 at 12:02:48PM -0500, Adrian Thurston wrote: > Hi, > > I'd like to serve messages that have been encrypted to a large number of > people, however I don't want to reveal the list of recipients so I'm > going to use --throw-keys. > > But speed at the decryption end is a concern, so I thought I would break > up an encrypted message into packets and when a client requests it serve > up only the packet that corresponds to the session key encrypted to > them, then the content packet. I haven't tried it yet, but it seems as > though it should work. I'd like to know if there is any non-obvious > reason why it is a bad idea. It's hard to really answer this as there isn't enough information to say one way or another. Speaking strictly to your question, and not the "is this wise" question, if I understand it, you are proposing encrypting to a large number of people, breaking the resultant encrypted message into many PKESK packets (one per recipient) and one encrypted packet. Then, send each recipient their own PKESK plus the encrypted packet. So, yes, that would work. GPG even ships with the tools to make such a message. And it's safe to do so with the caveat that every user will have the same encrypted message and be able to decrypt it. On the one hand, no big deal, becuase you sent everyone the same message, so you clearly wanted them to have it. On the other hand, it gives Alice the ability to know that Baker got the same message that Alice did. Whether that is important or not depends on what you are doing. Also, given that you are only sending each recipient their own PKESK, why bother to use --throw-keyid ? It might be easier to just encrypt the whole message to each recipient individually rather than do all the packet surgery. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Safe decryption with GnuPG?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Krzysztof Żelechowski wrote: > The decrypted information must not make it to any persistent medium GnuPG is almost certainly the wrong tool for your job. GnuPG has little control over low-level operating systems details like swap files. It is possible for cleartext to be stored in some manner. > (I understand gpg '-d' already guarantees it > as long as it manages the decrypted text, > but what happens after it leaves gpg?) [many other requirements snipped] Many of your requirements belong in the application stack alongside or above GnuPG, but are pretty much unrelated to GnuPG. After it leaves GnuPG it's no longer GnuPG's problem. Many of your requirements are also impossible to meet. I don't mean "impossible" as in "it would require a lot of engineering", I mean "impossible" as in "it's like violating the Second Law of Thermodynamics". > Can you direct me to some implementation meeting these requirements? There exists no such implementation. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iFYEAREIAAYFAkeonoYACgkQf2XByo0Cu7Or6ADcDcxgGCAxE2/Dp6NkFzwXBNg4 MI15KpzntdSaJADgkHHfzS/T0/3BnLSkZCVQ0OJ5OFYmxl1Nw4cypIkBHAQBAQgA BgUCR6iehgAKCRC3APSC/q+BCS9PB/sEIUftJVfX2hYNijy+ml6IAPYhGhIl73eP si/FvVWVP9WIYAOIz4Q68x1en+zXOncQc8cTUO8HB8hJeuWwe8Zoi/V2cB8nJ9Q1 +mwAcY7q7QuipRJhCpMG/pIS+BY6lDrDWDS1FOlWajDiZnO9Yo81PNCp85B+SC3B d69h2f6PBJY45DWHfQR224k/hEx9C522FlyPJVN6ZIn7fHSZonb4iTUyZ7Gh5mqW AOwBGPfyxYcAiXaBJPvOrdBV3b9kg0Gzf+rCRBDLpJsgmWssQOdGrRIXcOuW9n0C L94jJamwjgpP4YdTuirG4IZDwdcOw5vBoqjNrLpkvK8aoPWnf2AN =b/yU -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Safe decryption with GnuPG?
Sorry, but what you're asking for is impossible. The decrypted information must not make it to any persistent medium (I understand gpg '-d' already guarantees it as long as it manages the decrypted text, but what happens after it leaves gpg?) That's the business of the viewer. In particular, it should be converted to a human-viewable bitmap and the computer-readable representation must be immediately erased. This doesn't buy you much, especially since there's OCR and the computer generated bitmap is likely to be very regular. 3. Only the information I need should be displayed. How does the viewer know which information you need? The bitmap must not be updated automatically (the containing window must not display it when it is in the background, whatever it means). (It would be best to forget the bitmap altogether and regenerate it upon request, but it seems to be a hard thing to do because the gpg output stream is not scrollable backwards). Updated automatically? Not sure I see what you mean here. The bitmap itself should not make it to any persistent medium and it should be scrambled, if possible, in the volatile memory. Scrambling isn't of much use. If someone can read your memory they can read the key, which must lie somewhere in memory as well. It should not be possible to make a snapshot of the graphic in the window with any programmatic means (you can of course make a picture of the screen with a camera). This is impossible, unless you have: 1) trusted hardware, DRM style, or 2) a specifically built OS to ensure it. The application should be as lightweight as possible (for source code audit). Good luck, you're proposing an application that would have to take full control of video RAM to ensure noone can read it, that would have to do all sorts of graphical manipulation to generate a bitmap from a text, etc. --David. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: can you see any problem with this?
Adrian Thurston wrote: > But speed at the decryption end is a concern, so I thought I would break > up an encrypted message into packets and when a client requests it serve > up only the packet that corresponds to the session key encrypted to > them, then the content packet. I haven't tried it yet, but it seems as > though it should work. I'd like to know if there is any non-obvious > reason why it is a bad idea. At first blush it seems like a case of there being way too much hammer for the nail you have in mind. 1. Compose a single message: "the magic words are... [insert passphrase here]". 2. Write a script to encrypt each message to each recipient's key and mail it to them. If this takes more than 20 lines of Perl, something's wrong. 3. Compose your future traffic as normal, but symmetrically encrypt it and send it on to your recipients. ... Admittedly, I don't know the particulars of your environment, so this might be inappropriate for your needs. But it's the first thing that comes to mind as I read your description of what's happening. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Anti-Tempest Fonts, Where?
man gpg the above cmd mentions anti tempest fonts. what does this mean exactly? where are the anti-tempest fonts? i've searched the net for them and cannot find them. the only mention of soft tempest fonts were within a .zip containing image files claimed to be for example only. do tempest resistant fonts exist? Il mittente di questo messaggio|The sender address of this non corrisponde ad un utente |message is not related to a real reale ma all'indirizzo fittizio|person but to a fake address of an di un sistema anonimizzatore |anonymous system Per maggiori informazioni |For more info https://www.mixmaster.it ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Safe decryption with GnuPG?
Dear friends: I have a file that I encrypted for myself and I want to read some information from it. The file is a text file and I need to read several lines of it. The following requirements must be met: 1. The decrypted information must not make it to any persistent medium (I understand gpg '-d' already guarantees it as long as it manages the decrypted text, but what happens after it leaves gpg?) 2. The decrypted text must not be stored in volatile memory any longer than it is needed. In particular, it should be converted to a human-viewable bitmap and the computer-readable representation must be immediately erased. 3. Only the information I need should be displayed. 4. The bitmap must not be updated automatically (the containing window must not display it when it is in the background, whatever it means). (It would be best to forget the bitmap altogether and regenerate it upon request, but it seems to be a hard thing to do because the gpg output stream is not scrollable backwards). 5. The bitmap itself should not make it to any persistent medium and it should be scrambled, if possible, in the volatile memory. 6. It should not be possible to make a snapshot of the graphic in the window with any programmatic means (you can of course make a picture of the screen with a camera). 7. If more information is requested, it should be displayed in small chunks. The program should be fully unaware of the content of the chunks that are not being displayed. (That probably means a garbage-collected language cannot be used). 8. The application should be as lightweight as possible (for source code audit). Can you direct me to some implementation meeting these requirements? Best regards, Chris ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
can you see any problem with this?
Hi, I'd like to serve messages that have been encrypted to a large number of people, however I don't want to reveal the list of recipients so I'm going to use --throw-keys. But speed at the decryption end is a concern, so I thought I would break up an encrypted message into packets and when a client requests it serve up only the packet that corresponds to the session key encrypted to them, then the content packet. I haven't tried it yet, but it seems as though it should work. I'd like to know if there is any non-obvious reason why it is a bad idea. Thanks, Adrian ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Can you clarify when data compression is used?
On Mon, Feb 04, 2008 at 11:12:02PM -0600, Robert J. Hansen wrote: > I suspect--although I do not know--that a similar motivation drove > GnuPG's decision to leave DSA-1024 as the standard. That's basically the reason. While GPG fully supports DSA2 signatures today, there are a large installed base that cannot handle them. Because of this, we decided to fully accept DSA2 keys and signatures from elsewhere, but won't generate a new DSA2 key unless the user opts in with --enable-dsa2. > Now that RFC4880 has come out, supplanting RFC2440, I imagine the way is > clear to make all new keys DSA-2048 or DSA-3072. After all, now it's > part of the standard. The way is clear, and we'll get there eventually, but the installed base is still pretty old. Using --rfc4880 or --openpgp does enable DSA2, but the default is still off. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Using notations on data signatures
On Tue, Feb 05, 2008 at 02:29:01PM +, Phil Brooke wrote: > Hi, > > I'm a bit confused about --sig-notation. Suppose I detach-sign a file; is it > reasonable to use notations to briefly comment on it? e.g., > --sig-notation [EMAIL PROTECTED]"This loan application is approved." > (Not dealing with loans really, but needed some example) Yes, that is a reasonable use of a notation. Notations (and especially user notations) are basically the escape hatch in the OpenPGP design: they're intended for adding stuff to signatures. What stuff if up to the adder. See also --sig-policy-url for another, but more standard, way to add information about a signature. > Is the notation part of the signed data (whereas the comment headers aren't) > so that tampering with the notation is evident? Yes. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Using notations on data signatures
Hi, I'm a bit confused about --sig-notation. Suppose I detach-sign a file; is it reasonable to use notations to briefly comment on it? e.g., --sig-notation [EMAIL PROTECTED]"This loan application is approved." (Not dealing with loans really, but needed some example) Is the notation part of the signed data (whereas the comment headers aren't) so that tampering with the notation is evident? Thanks, Phil. __ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
