headers
Jānis Ročāns | 3 Apr 2009 23:52
Picon

openpgp signing encrypting to understand by PGP Desktop.


Good morning!
Last few days I was trying to understand data encryption and signing. I 
am using JAVA to collect data into String from database, and need to 
sent them automatically by e-mail in attachment encrypted and signed. I 
got them first signed, then encrypted, but the PGP Desktop finds it only 
encrypted. To verify, I need to decrypt, the result is a pgp file again, 
that now I can verify. But I believe, that this all i did is wrong, so 
can you tell me, how to make the signed and encrypted file fully 
recognized by PGP desktop? For newbie it is hard to understand all the 
things happening in these processes.
Thanks a lot,
Jānis Ročāns.
Permalink | Reply | 3 comments |
headers
Wim Lewis | 6 Apr 2009 00:18

Re: openpgp signing encrypting to understand by PGP Desktop.


On Apr 3, 2009, at 2:52 PM, Jānis Ročāns wrote:
> Last few days I was trying to understand data encryption and  
> signing. I am using JAVA to collect data into String from database,  
> and need to sent them automatically by e-mail in attachment  
> encrypted and signed. I got them first signed, then encrypted, but  
> the PGP Desktop finds it only encrypted. To verify, I need to  
> decrypt, the result is a pgp file again, that now I can verify. But  
> I believe, that this all i did is wrong, so can you tell me, how to  
> make the signed and encrypted file fully recognized by PGP desktop?

I might not correctly understand the problem, but no one else has  
spoken up, so I will jump in. I think what is happening is that, by  
signing and then encrypting, you are not generating exactly the same  
message format that PGP will when told to sign and encrypt at the  
same time.

What you want is a message with the following structure:

  [Public-key-encrypted session key]
  [Session-key-encrypted data:
     [Literal packet: "Blah blah blah..."]
     [Signature packet] ]

But what you are probably producing is:

  [Public-key-encrypted session key]
  [Session-key-encrypted data:
     [Literal packet: "[Literal packet: "Blah blah blah..."]
                       [Signature packet]" ] ]
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jānis Ročāns | 6 Apr 2009 21:18
Picon

Re: openpgp signing encrypting to understand by PGP Desktop.


Thanks,
This helped me! I just removed literal data generation from my source 
and PGP desktop understood it correctly!
Wim Lewis wrote:
>
> On Apr 3, 2009, at 2:52 PM, Jānis Ročāns wrote:
>> Last few days I was trying to understand data encryption and signing. 
>> I am using JAVA to collect data into String from database, and need 
>> to sent them automatically by e-mail in attachment encrypted and 
>> signed. I got them first signed, then encrypted, but the PGP Desktop 
>> finds it only encrypted. To verify, I need to decrypt, the result is 
>> a pgp file again, that now I can verify. But I believe, that this all 
>> i did is wrong, so can you tell me, how to make the signed and 
>> encrypted file fully recognized by PGP desktop?
>
> I might not correctly understand the problem, but no one else has 
> spoken up, so I will jump in. I think what is happening is that, by 
> signing and then encrypting, you are not generating exactly the same 
> message format that PGP will when told to sign and encrypt at the same 
> time.
>
> What you want is a message with the following structure:
>
>  [Public-key-encrypted session key]
>  [Session-key-encrypted data:
>     [Literal packet: "Blah blah blah..."]
>     [Signature packet] ]
>
> But what you are probably producing is:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Arturo 'Buanzo' Busleiman | 6 Apr 2009 21:31
Picon

Re: openpgp signing encrypting to understand by PGP Desktop.


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Sorry to hijack the thread... but if there's someone from PGP Inc here, I'd really like to see if
it'd be possible to obtain a license for development purposes... I'd like to integrate commercial
PGP into my Enigform firefox extension (Secure session management, http request/response signing,
etc)....

- --
Arturo "Buanzo" Busleiman / Arturo Busleiman  <at>  4:900/107
Independent Linux and Security Consultant - SANS - OISSG - OWASP
http://www.buanzo.com.ar/pro/eng.html
Mailing List Archives at http://archiver.mailfighter.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREKAAYFAknaWJEACgkQAlpOsGhXcE1GOwCfcInrleIJzQaIDIIKQKzzAbJN
nsAAnRIok3UiDyTwceoOvmX3KldZWoY0
=cpgz
-----END PGP SIGNATURE-----
Permalink | Reply | 0 comments |
headers
Daniel Kahn Gillmor | 28 Apr 2009 16:31

Preferred Key Server subpacket in non-self-signature?

I'm trying to understand the preferred key server subpacket [0] and how
one might reasonably respect it in an implementation without causing
potential for things that are the OpenPGP equivalent of "web bugs", but
while still keeping it useful.

While looking into this, it occured to me that the RFC doesn't
explicitly say that the Preferred Key Server subpacket must only reside
on a self-signature.  So, what would it mean if the Preferred Key Server
subpacket was included in a third-party certification?

For example, Alice has an OpenPGP with her User ID "Alice".  Bob meets
Alice, checks fingerprints, and certifies her User ID with a signature
type 0x10.  But his signature contains a Preferred Key Server sub-packet
that points back to http://bob.example.org/alice

Carol imports Alice's key, but wants to be sure that she has the latest
updates, revocations, and so forth, so she asks her OpenPGP client
(which defaults to using pool.sks-keyservers.net) to refresh from the
keyservers.  What should Carol's OpenPGP client do in this case?

What about in the case where the Preferred Key Server subpacket is on
Alice's self-sig?  What about two different Preferred Key Server
subpackets (one from Alice, one from Bob)?

	--dkg

http://tools.ietf.org/html/rfc4880#section-5.2.3.18
Permalink | Reply | 2 comments |
headers
David Shaw | 28 Apr 2009 17:50

Re: Preferred Key Server subpacket in non-self-signature?


On Apr 28, 2009, at 10:31 AM, Daniel Kahn Gillmor wrote:

> I'm trying to understand the preferred key server subpacket [0] and  
> how
> one might reasonably respect it in an implementation without causing
> potential for things that are the OpenPGP equivalent of "web bugs",  
> but
> while still keeping it useful.
>
> While looking into this, it occured to me that the RFC doesn't
> explicitly say that the Preferred Key Server subpacket must only  
> reside
> on a self-signature.  So, what would it mean if the Preferred Key  
> Server
> subpacket was included in a third-party certification?

I would say it means "Here is how the person who issued that  
certification wants you to get his key".  The same thing applies if  
the preferred keyserver packet was included on a regular data  
signature (which GPG supports, by the way).

> For example, Alice has an OpenPGP with her User ID "Alice".  Bob meets
> Alice, checks fingerprints, and certifies her User ID with a signature
> type 0x10.  But his signature contains a Preferred Key Server sub- 
> packet
> that points back to http://bob.example.org/alice
>
> Carol imports Alice's key, but wants to be sure that she has the  
> latest
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel Kahn Gillmor | 28 Apr 2009 18:30

Re: Preferred Key Server subpacket in non-self-signature?

On 04/28/2009 11:50 AM, David Shaw wrote:
> I would say it means "Here is how the person who issued that
> certification wants you to get his key".  The same thing applies if the
> preferred keyserver packet was included on a regular data signature
> (which GPG supports, by the way).

Ah, ok.  I was thinking it would refer to where to fetch updates for
that particular signature, not for the key.  The section reads:

   This is a URI of a key server that the key holder prefers be used for
   updates.  Note that keys with multiple User IDs can have a preferred
   key server for each User ID.  Note also that since this is a URI, the
   key server can actually be a copy of the key retrieved by ftp, http,
   finger, etc.

"used for updates" was unclear to me because i was thinking that it
meant "to get updates about this signature" rather than "to get updates
about the signer's key".

Is there a way for the issuer of a signature to provide a place where
updates to the signature itself (e.g. revocations, or re-certifications)
would be published?

I understand that the global keyserver network is normally what you'd
use.  But i'm trying to work through the context of an organization who
wants to also publish all their signature revocations in a known,
canonical location (including the revocations of certifications of
third-party keys).  Maybe this use case is misguided or irrelevant,
though.  Is it?
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Shaw | 1 May 2009 00:39

New results against SHA-1


http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf

There is not much hard information yet, but the two big quotes are  
"SHA-1 collisions now 2^52" and "Practical collisions are within  
resources of a well funded organisation."

David
Permalink | Reply | 9 comments |

Gmane