gmane.ietf.openpgp

Timestamping

Peter Todd — 2013-05-03T17:40:15

I've been working on and off on a open-source timestamping package
called OpenTimestamps (https://github.com/opentimestamps)

It's based on hashing, usually by combining many digests into a merkle
tree, with the tip digest being timestamped by some method. To date it's
been used with the Bitcoin blockchain as the timestamping method, but
the architecture is notary agnostic - RFC3161 support is on my TODO list
for instance.

The actual structure of a timestamp consists of a set of operations,
generally hash algorithms, forming a DAG. The operations are computed,
and provided the path from the input digest to the notarized
timestamp(s) is valid one can prove that the data existed before the
time. Nothing very exciting really in terms of actual crypto, but as far
as I know my project is the first to attempt a flexible, general
solution based on hashing that can, in principle, support a variety of
notary methods.


Timestamping came up on the GnuPG mailing list, and Werner Koch
suggested I look into adding times

Biggest Fake Conference in Computer Science

2013-04-27T17:33:05

Biggest Fake Conference in Computer Science


We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.


We submitted a fake paper to WORLDCOMP 2011 and again (the same paper 
with a modified title) to WORLDCOMP 2012. This paper had numerous 
fundamental mistakes. Sample statements from that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware


Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without

primary key binding signatures (0x19) for non-signingsubkeys

Daniel Kahn Gillmor — 2013-03-12T21:07:01

hi OpenPGP folks--

I'm wondering whether authentication-capable subkeys should require
primary key binding signatures (aka "back-sigs" or
"cross-certifications").  There seems to be consensus that
signing-capable subkeys need back-sigs, but it's not clear whether
authentication-capable subkeys need the same thing.

RFC 4880 says:


Many (all?) authentication schemes that use public keys involve making a
signature of some data during the authentication exchange.

This suggests to me that authentication-capable subkeys should have a
back-sig.

Also, i'm considering the possibility of OTR-OpenPGP linkage i mentioned
in a previous thread.  It occurs to me that if Alice manages to
authenticate Bob using some OTR handshake, and she wants to bootstrap
her way from that mutual authentication into an OpenPGP authentication,
then a back-sig is critical.

Mallory can already make her own OpenPGP primary key, attach Bob's User
ID to it, and then attach Bob's actual OTR key as a subkey.  If Alice
just scans the keyserve

marking subkeys as constrained for specific use -- new key usage flags?

Daniel Kahn Gillmor — 2013-03-05T09:41:58

Hi good OpenPGP people--

I use both OpenPGP and OTR.  my OTR implementation has its own public key.

I can see a use case for indicating my OTR public key directly as a
subkey on my main OpenPGP key, so that anyone who knows me via the
OpenPGP web of trust could have their tools automatically authenticate
me (without having to do any of the various OTR authentication
handshakes explicitly).

I also think i would like this subkey to be unambiguously identified as
an OTR public key, so that it is not accepted for use in any other
context (e.g. it would be bad if someone who was able to compromise my
OTR client and steal my OTR key was able to use the secret key material
to impersonate me over SSH).

How could i indicate such a clear constraint?

I have a couple of ideas, and would be happy to hear people's thoughts:

A) allocate 0x40 of the usage flags [0] to mean "use in OTR".

  What kind of work needs to be done to get a new bit allocated there?
  Is allocating a new bit reasonable?

B) use the "authentica

keyserver protocol

Jesus Cea — 2013-01-03T20:14:38

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

Hi, everybody.

I have been following SKS mailing lists for years and I wonder how can
OpenPGP rely on an undocumented protocol, with only a single codebase
written in a unusual language for something so paramount as keyservers
and key distribution :-).

http://minsky-primus.homeip.net/sks/

I don't have a bad eye for SKS. I think it covers a badly needed need
and it is not its fault if there is no competition. I read the master
thesis that was seminal writing for this project, but the exact
protocol is not documented and must be digged from the sourcecode...
written in Ocaml :-).

I am really uncomfy with this situation, and I wonder if I am
overreacting, or people are not actually aware of this "monoculture"
and lack of interoperativity...

Please, consider this *NOT* an attack to SKS (thanks god we have it!)
but a heads up to think about it.

- -- 
Jesús Cea Avión                         _/_/      _/_/_/        _/_/_/
jcea< at >jcea.es - http://www.jcea.es/

Secret key checksum

Stephen Paul Weber — 2013-01-03T16:54:45

Encrypted secret keys can be protected with SHA1 or with a two-octet 
checksum.  Unencrypted secret keys can only be protected with a two-octet 
checksum.

What is the intended purpose of this integrity protection?  What are the 
security issues with using the weaker checksum over SHA1?  Are these 
security issues not present on an unencrypted secret key?

Fingerprints and their collisions resistance

Andrey Jivsov — 2013-01-03T07:18:46

We exchanged a few emails on gnupg list about this this issue, which I 
think belongs here, the OpenPGP thread.

The issue is that fingerprint calculation method in OpenPGP is hardwired 
to use SHA-1. Some scenarios in which fingerprints are used  depend on 
hash function collision resistance.

It's easy to see the collision resistance requirement of fingerprints by 
making the comparison with document signatures.

Classical collision resistance requirement arises in a situation when 
the owner is free to create two documents that hash to the same hash 
value. The attacker then makes one document available for signing. As a 
result he has acquired an option to use the second document later and 
claim that it was the document that was originally signed.

When viewed as document, the keys fit this pattern. One possible 
exploitation of the hash collision is when the attacker can repudiate 
signatures or repudiate his ability to decrypt messages (because he can 
offer a wrong key with the same fingerprint as a

Last call for ECC in OpenPGP

Werner Koch — 2012-03-13T19:46:30

Hi,

in case you missed it: The last call for the ECC draft, discussed here
for some years, has been issued.


Salam-Shalom,

   Werner

Review of draft-ecc-09

Marko Kreen — 2012-02-18T21:51:15


Hello,

I tried to implement ECC for pgcrypto, which is crypto module
for PostgreSQL database.  And I managed to get it to work,
mainly because of EC module in OpenSSL, which allowed me to be
ignorant of all low-level math details.

Also, I only implemented ECDH, pgcrypto does not do signing.
It uses PGP as a fancy encrypt/decrypt storage format only.

So this is a review of draft-08 by app developer who is ignorant
of EC math and has not read any detailed math/crypto papers...

[ I updated the review with diff from -09.  Thanks for taking
  my comments on the ref section into account. ]


Note for later: this basically states that section 8 plans to
fully describe ECDH used in OpenPGP.


*Then*, they are also padded to byte boundary.  As this is not mentioned
anywhere, it caused me some confusion, because I assumed they already
are on byte boundary, perhaps even power-of-two.

As it only matters to P-521 keys, the bad assumtions work fine on
P-256 and P-384 keys.  (Basically I assumed P-521 uses 512-bit v

MIME media type literal packet in OpenPGP

Vinnie Moscaritolo — 2011-03-11T18:39:40

* PGP Signed: 03/11/2011 at 10:39:52 AM

Greating;

I just posted an informational draft about some minor changes that the PGP sdk
is now supporting.   comments and complaints are welcome.

be kind, this is my first time doing this.

http://www.ietf.org/id/draft-moscaritolo-openpgp-literal-00.txt

 This document describes an extension to the OpenPGP Message Format
   that allows a Multipurpose Internet Mail Extension (MIME) Media Type
   (aka Intenet Media type) to be associated with the encoded content.
   By providing more information beyond the existing binary and text
   formats this extension and can enable the automated selection of an
   appropriate media viewer for the decoded content.



-------------------------------------------------------

Vinnie Moscaritolo
Principal Cryptographic Engineer
PGP, now a part of Symantec Corporation
PGP Fingerprint:
7E64 B73D 55AB CEF5 B3BB  E501 E985 A429 9CFE ACEC




* Vinnie Moscaritolo <vinnie< at >pgpeng.com>
* 0x9CFEACEC:0xBAD29397

DEADBEEF vs SHA1

David Shaw — 2011-02-17T19:12:20

Hi everyone,

I was thinking about Daniel Gillmor's proposal to include the complete fingerprint in signatures, and specifically this:


It occurred to me that it doesn't actually matter whether a 64-bit SHA-1 collision is feasible today or not.  There is a much easier collision that makes this attack trivial without going up against SHA-1 at all.

OpenPGP uses the 64-bit key ID to find the right key to verify a signature (via the issuer subpacket).  However that key ID doesn't have to be the lower 64 bits of the fingerprint like it is in V4.  In V3, it was the lower 64 bits of the modulus, which is trivial to set to whatever the attacker likes (i.e. the DEADBEEF key problem).  The problem is that the issuer subpacket doesn't differentiate between V3 and V4, so it's possible to make a DEADBEEF V3 key and use it to do a version rollback / denial of service attack against a V4 key.

For example, Alice's key (either V3 or V4) has a key ID of E435AEDF689E2211.  Mallory makes a V3 key, matches the key ID E435AED

Support RSA-PSS?

Hanno Böck — 2010-08-31T11:54:20

Hi,

Hi,

I'm currently writing my diploma thesis about RSA-PSS, an improved signature 
scheme for RSA. It is specified in PKCS #1 2.1. Part of my thesis is 
researching the status of implementations and standards.

Are there any plans to support RSA-PSS in openpgp? RFC 4880 only supports the 
old padding scheme from pkcs #1 1.5.

cu,

SERPENT in OpenPGP?

Christoph Anton Mitterer — 2010-08-26T21:02:16

Hi.

Have it ever been considered to add SERPENT to OpenPGP?

AFAIK it's free/patent-unencumbered,... and IIRC the AES process, it was
considered to be even more secure than Rijndael.... of course it's
probably far less analysed than the later.


Another issue, which comes just in my mind.... would it make sense to
add support for stacked encryption?
I mean, having a literal packet encrypted with a symmetrically encrypted
data packet say with cipher A, which in turn is encrypted with another
symmetrically encrypted data packet say with cipher B.
Of course the session key packet would have to be large enough to
provide key material for both.


Cheers,
Chris.

Certification/self-signatures

Stephen Paul Weber — 2010-08-14T14:32:11

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello all!

I'm seeking some clarification WRT computing v4 signatures over key data for
0x13 signatures (specifically, the self-signature).

The spec says "0x99, followed by a two-octet length of the key, and then
body of the key packet".  I assume it's always on what would be the body of
the public part of the packet?  Is this the same as the data used in
generating the fingerprint, just without version/timestamp/algorithm octets?
Should the length field include the length of the 0x99 + length in it?
Should it include the length of the whole public park (including
version/timestamp/algorithm)?

Then it says "A certification signature (type 0x10 through 0x13) hashes the
User ID being bound to the key into the hash context after the above data
... A V4 certification hashes the constant 0xB4 for User ID certifications
or the constant 0xD1 for User Attribute certifications, followed by a four-octet
number giving the length of the User ID or User Attribute data,

ElGamal, EME-PKCS1-v1_5

Brian Lewis — 2010-06-24T17:31:19

I'm trying to generate a tag 1 (public-key encrypted session key)
packet.

I'm using ElGamal, so the algorithm-specific fields are, according to
http://tools.ietf.org/html/rfc4880#section-5.1,
MPI g**k mod p
MPI m * y**k mod p

So I need m = EME-PKCS1-v1_5(...). According to
http://tools.ietf.org/html/rfc3447#section-7.2.1, PS is k - mLen
- 3 random nonzero bytes, where k is the length of RSA n in bytes. But I
don't have RSA n. I have ElGamal p, g, and y.

In EME-PKCS1-v1_5, what is k if I'm using ElGamal?

Thank you.

S2K Question

Stephen Paul Weber — 2010-03-31T23:24:03

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I think I get simple and salted, but iterated and salted is a bit complex.

Is it:

key = "";
count = ((Int32)16 + (c & 15)) << ((c >> 4) + 6);
for(i = 0; i < count; i++) {
key = hash_function(strcat(key, passphrase[i]));
}

- -- 
Stephen Paul Weber, < at >singpolyma
Please see <http://singpolyma.net> for how I prefer to be contacted.
edition right joseph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJLs9mTAAoJENEcKRHOUZzepXQP/3vuO49/kEEZ00RQTnnCdr5s
50YBdCHwlpnfm0Wmz5ZSUFkNqhjcTRwjSOraVD4xvD3aNFPyUVmijtylFcQo2Dan
2aJK/+mhKTH8phCkB6SCaTT8QI1HjNnIHUbteQGDofKLmppVMK/nJEZCshKxnA5V
5LE4tzlVyqMTKkzxGCXPqXpKvJTvPFH1G8QfLYiTC5o2/ZhS+fn3OZdd7egWECIy
YE7VICb1h4lPzvEg4n/nQA+l5SoZsUW12BsFTDtuCJlspGvXLQteiRmKVEPtbKMt
2gfBnNkroQISVjEnn07WP8GQnVDT6TaStLDNuZenKoh/+82J6nMtDthtKmV8stPY
XbWsVHyR99CT1q3nZa8xAeLv7dbaud0cujUSShpdnaeq/5erfbbxiD97rwjfh06L
hhmg9XgUrM0UgMbqlHSZRZNyhdqNtt3bmXnahm0LyMGOQkxa5kFJwJHKvrXWqPrR
LPRKTqMtbT9FkadjCk5w/gjGYjd6+DSzrD

Question about verifying signatures

Stephen Paul Weber — 2010-03-30T20:20:49

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I'm reading RFC4880 in an attempt to produce an implementatdion of a subset
of OpenPGP (RSA signatures) using <http://phpseclib.sourceforge.net/>.  I
have the publickey and compression-literal-signature packets parsed out.  I
can extract n and e and feed them to Crypt_RSA to construct a verifier.  I
tell it I'm using sha256.  It then needs a "message" and a "signature"
parametre.  I get the signature data out of the signature packet no problem.
The question I have is: what is "message"?  According to section 5.2.4 it's
some combination of the literal data packet(s?) (their bodies or the whole
packet?) and the "hashed" subpackets.  Do I just concat all the data packets
and the hashed packets together in the order they appear?

Thanks.

- -- 
Stephen Paul Weber, < at >singpolyma
Please see <http://singpolyma.net> for how I prefer to be contacted.
edition right joseph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJLsl0hAAoJENEcKRHOUZz

Better S2K functions for OpenPGP?

Daniel Franke — 2009-12-09T20:17:35

The discussion currently going on gnupg-dev about increasing the
default iteration count for the S2K prompted me to wonder whether
OpenPGP couldn't benefit from some more modern key-derivation
algorithms. PBKDF2[1] is the most standard, while bcrypt[2] is also
well-tested and popular, and scrypt[3], although new, seems to be
superior to both of them.  The advantage of scrypt is that it's hard in
terms of space complexity as well as time complexity, greatly reducing
the advantage given to an attacker who has the ability to build custom
cryptographic hardware.

[1] http://www.rsa.com/rsalabs/node.asp?id=2127
[2] http://www.openbsd.org/papers/bcrypt-paper.ps
[3] http://www.tarsnap.com/scrypt.html