headers
Michael Young | 4 Nov 2003 18:43

Re: theory (was Re: Back-signatures proposal)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Trevor Perrin wrote [excerpts quoted out of order]:
...
 > I notice the patent has a signature on it, and I know the USPTO is
 > in the habit of signing pending applications with its own key.
 >
 > I go to a PGP key server and find a key claiming to belong to
 > USPTO. I use it to verify the application.  Since it verifies, I
 > jump to the conclusion that the key belongs to the USPTO.

Yes, you have made a serious error in verifying that key.

You wouldn't do this with a document you received insecurely.  You
wouldn't do this if you considered the possibility that the USPTO
site might vend documents signed by others, a perfectly reasonable
possibility.

You seem to be relying on this preface:

 > Suppose I download the patent application from USPTO's site, over a
 > secure link.

If you believe that the link is secure, why wouldn't you use it
to retrieve the USPTO's key?  [OK, they might not publish their
key this way.  Ask them to do so.  If they won't take that
seriously, why would you trust signatures gathered this way?]
(Continue reading)

Permalink | Reply | 1 comment |
headers
Trevor Perrin | 4 Nov 2003 23:27

Re: theory (was Re: Back-signatures proposal)


At 12:43 PM 11/4/2003 -0500, Michael Young wrote:
>Content-Transfer-Encoding: 7bit
>
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Trevor Perrin wrote [excerpts quoted out of order]:
>...
> > I notice the patent has a signature on it, and I know the USPTO is
> > in the habit of signing pending applications with its own key.
> >
> > I go to a PGP key server and find a key claiming to belong to
> > USPTO. I use it to verify the application.  Since it verifies, I
> > jump to the conclusion that the key belongs to the USPTO.
>
>Yes, you have made a serious error in verifying that key.
>
>You wouldn't do this with a document you received insecurely.  You
>wouldn't do this if you considered the possibility that the USPTO
>site might vend documents signed by others, a perfectly reasonable
>possibility.
>
>You seem to be relying on this preface:
>
> > Suppose I download the patent application from USPTO's site, over a
> > secure link.

Yes, I'm relying on that.
(Continue reading)

Permalink | Reply | 0 comments |
headers
vedaal | 10 Nov 2003 18:40

Shamir's Discrete Logarithm Hash // for possible inclusion into open-pgp ?


Shamir's Discrete Logarithm Hash was recently implemented by Ralf Senderek
in a new small crypto program, PCP (Pure Crypto Project)

(hash description is here:)
http://senderek.de/SDLH/

it has been around for a while, was proven to be collision resistant,
 but hasn't really been implemented before, possibly because of the length
of time required to sign directly with the rsa key

now, with faster processors,
this may be an appropriate hash for e-mail-length messages,

and, as there are plans for the wider SHA hashes to be introduced,
maybe it would be worthwhile considering a hash will remain secure as
long as the keysize is considered secure

(although it won't work for dh keys ;-(  )

just a thought,

vedaal

Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hal Finney | 10 Nov 2003 20:03

Re: Shamir's Discrete Logarithm Hash // for possible inclusion into open-pgp ?


Vedaal writes:
> Shamir's Discrete Logarithm Hash was recently implemented by Ralf Senderek
> in a new small crypto program, PCP (Pure Crypto Project)
>
> (hash description is here:)
> http://senderek.de/SDLH/

It's security properties are a little unusual, in that the creator of
the hash function can forge collisions.  Senderek has the creator be
the signer, which seems to work OK, but it is still different enough
from traditional hashes that it makes me wonder.

Traditionally, signature security proofs are based on a random oracle
model, while this hash function is like a random oracle with a trap door.
I don't know if there exist security proofs for that arrangement.

> (although it won't work for dh keys ;-(  )

I don't see why it can't.  The hash's RSA modulus has nothing to do
with the signature key.

Hal Finney
Permalink | Reply | 0 comments |
headers
Douglas Maus | 17 Nov 2003 13:54
Picon
Favicon

private key CFB


Two beginner questions:

1. In Private Key packets (tag 5, section 5.5.3), what is the bitsize of the CFB mode used in encrypting the
secret MPI? For example, AES256 may be performed in CFB 1bit, CFB 8bit and CFB 128bit (1bit, 1octet, and
1block). Is this noted somewhere in the RFC that I'm missing?

2. Could someone please help me confirm a key from salt and passphrase?
keysize of 256 (AES 256 - algorithm 9 in section 9.2)
Iterated and salted mode (3.7.1.3)
SHA1 hash (algorithm 2 in section 9.4)
salt of 0x61f8a7c834124c3a
coded count 96 (count then 65536)
passphrase: 'passphrase'

I get
0x66913d886546e5e352edaddff30255d26a4f0b969603131df274720b68d78f6f

(unfortunately this doesn't work in decrypting my MPI)

Thanks,
Douglas Maus
Permalink | Reply | 4 comments |
headers
Hal Finney | 17 Nov 2003 18:22

Re: private key CFB


Douglas Maus writes:
> 1. In Private Key packets (tag 5, section 5.5.3), what is the bitsize of the CFB mode used in encrypting the
secret MPI? For example, AES256 may be performed in CFB 1bit, CFB 8bit and CFB 128bit (1bit, 1octet, and
1block). Is this noted somewhere in the RFC that I'm missing?

CFB in PGP always uses one block shift widths.  That would be 128 bits for
AES.

> 2. Could someone please help me confirm a key from salt and passphrase?
> keysize of 256 (AES 256 - algorithm 9 in section 9.2)
> Iterated and salted mode (3.7.1.3)
> SHA1 hash (algorithm 2 in section 9.4)
> salt of 0x61f8a7c834124c3a
> coded count 96 (count then 65536)
> passphrase: 'passphrase'
>
> I get
> 0x66913d886546e5e352edaddff30255d26a4f0b969603131df274720b68d78f6f

Sorry, I don't have time to do this.

Hal Finney
Permalink | Reply | 0 comments |
headers
Michael Young | 17 Nov 2003 19:03

Re: private key CFB


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I made a quick tweak to my implementation (to emit the raw session
key),
so there's some chance I've goofed, but I got:
     1d.43.a2.ec.02.75.db.29.c1.30.d9.a1.24.28.b6.c6.

Sadly, GnuPG (1.2.2)'s --show-session-key doesn't seem to work on
symmetrically encrypted packets, but it might be easy to tweak.

Good luck!

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBP7kNTOc3iHYL8FknEQIQxgCgjG+7LnJCsAt57Un6ch5OZZ0jcUoAn2V/
XP0C5VqBxkJRH3NrT8Ibx+Lc
=J09U
-----END PGP SIGNATURE-----
Permalink | Reply | 3 comments |
headers
David Shaw | 17 Nov 2003 20:03

Re: private key CFB


On Mon, Nov 17, 2003 at 01:03:10PM -0500, Michael Young wrote:

> I made a quick tweak to my implementation (to emit the raw session
> key),
> so there's some chance I've goofed, but I got:
>     1d.43.a2.ec.02.75.db.29.c1.30.d9.a1.24.28.b6.c6.

Isn't that too short for a 256-bit key?

I got BD3511280C74BC56D12E066DF12C5E22E1D9776B068F3A276017D59C39397794

> Sadly, GnuPG (1.2.2)'s --show-session-key doesn't seem to work on
> symmetrically encrypted packets, but it might be easy to tweak.

That's not what show-session-key is for.  It's for, well, showing
session keys ;)

David
Permalink | Reply | 2 comments |
headers
Michael Young | 17 Nov 2003 22:04

Re: private key CFB


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 > Isn't that too short for a 256-bit key?

Indeed, my post included a 128-bit key computation.  (I also
used MD5, rather than SHA1 as asked.)  Sorry about that.

For a 256-bit key, based on SHA1, I get:
     53.f2.fd.a7.69.7d.0b.a6.c0.ee.18.4f.89.db.1d.f8.
     14.6c.d4.ad.36.1b.8c.4e.63.13.ab.68.75.a7.ad.0b.

I also generated a 64k-sized file and tested with "sha1sum",
getting the same first 20 bytes.

 >>Sadly, GnuPG (1.2.2)'s --show-session-key doesn't seem to work on
 >>symmetrically encrypted packets, but it might be easy to tweak.
 >
 >
 > That's not what show-session-key is for.  It's for, well, showing
 > session keys ;)

I think you may have misread my comment as wanting to produce the
session key that protects a secret key, based on the original
context.
I did not. I was talking about a "conventionally encrypted" message,
using a Symmetrically Encrypted Data Packet.  If the S2K doesn't
include an (*optional*) encryption of the session key, then the S2K
computation result *is* the session key; I was simply trying to use
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Shaw | 17 Nov 2003 23:00

Re: private key CFB


On Mon, Nov 17, 2003 at 04:04:08PM -0500, Michael Young wrote:

> > That's not what show-session-key is for.  It's for, well, showing
> > session keys ;)
> 
> I think you may have misread my comment as wanting to produce the
> session key that protects a secret key, based on the original
> context.

Given that the original poster was asking about decrypting his secret
key MPIs, I'm uncertain where a discussion of conventionally encrypted
messages came from.  Context is generally important in having a
discussion as it ties together various thoughts about the sunrise,
which was very pretty this morning.  If there is a GnuPG feature you
want, bring it up on one of the GnuPG lists.  I'll confess I'm not too
sure what behavior you are arguing for.

David
Permalink | Reply | 0 comments |

Gmane