Timestamping

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 timestamps to OpenPGP signatures as
Signature Notation Data. In short the timestamp would apply to the
digest of the data being signed proving that it existed before some
particular time; the timestamp would act to prove the Signature Creation
Time field was correct, at least in one direction.(1) Timestamps on data
is one obvious applications. Timestamping PGP keys is another, although
actually doing so usefully is tricky.

Lets look at data first. Signature Notation Data can either be signed or
unsigned. A timestamp should be stand-alone - its validity must depend
on the notary rather than the user - so there really isn't any need to

Re: OpenPGPv5 wish list

On Mon, 29 Apr 2013 19:53, philcerf <at> gmail.com said:

> Well actually the contrary seems to be the case... OpenPGP is rather
> only used for mail and plain file encryption/signing, which covers of
> course already many fields, but nothing advanced.

Depends on what you call advanced.  OpenPGP is a low-level protocol and
never really tried to address the application layer. 

> It would never have any chance to be used for government ID cards, or
> similar projects.

Why should a government do that?  eID cards started in Europe (iirc, the
German electronic signature law was the first at all).  Europe has a
history of waiting for X, aehmm the OSI network stack, and thus it is
quite obvious that they started with X.400 et al.  Further, you can make
more (consulting) money with weakly defined/complex protocols than with
a clean solution.  The latter almost never wins (cf. IPSec lessons).

> Yeah I knew... but right now it's also used for the name of the user,
> which is the primary identification property... and it shouldn't be
> used for that (from a design POV).

Maybe not for your application, so go and use your own thing for it.
There is nothing which will stop you.  What about putting a DN into it?

> Obviously I don't want X.509 or I'd use it.
> And I don't see how this is touched by X.509 anyway.

Because X.509 has all the useless bells and whistles which have been

Biggest Fake Conference in Computer Science

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 
any reviews) and we were invited to submit the final paper and a 
payment of $500+ fee to present the paper. We decided to use the 
fee for better purposes than making Prof. Hamid Arabnia (Chairman 
of WORLDCOMP) rich. After that, we received few reminders from 
WORLDCOMP to pay the fee but we never responded. 

We MUST say that you should look at the above website if you have any thoughts 
to submit a paper to WORLDCOMP.  DBLP and other indexing agencies have stopped 
indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See 

primary key binding signatures (0x19) for non-signing subkeys

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:

>   For subkeys that can issue signatures, the subkey binding signature
>   MUST contain an Embedded Signature subpacket with a primary key
>   binding signature (0x19) issued by the subkey on the top-level key.

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 keyserver for primary keys that have Bob's OTR key as a
subkey, there is no way for her to distinguish between Bob's actual key

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

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 "authentication" usage flag with a critical notation.

   Since the OTR subkey is clearly used for authentication purposes,
   perhaps the right way to go is to mark the key as authentication-
   capable in the usage flags, but also add a critical notation that

keyserver protocol

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/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea <at> jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/

Secret key checksum

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?

--

-- 
Stephen Paul Weber,  <at> singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph

_______________________________________________
openpgp mailing list
openpgp <at> ietf.org
https://www.ietf.org/mailman/listinfo/openpgp

Fingerprints and their collisions resistance

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 proof supporting his 
inability to perform the private key operation).

Public keys offer a reasonable opportunity to place arbitrary bytes into 
fields that are hashed. For example, DSA P,Q,G, are primes. Every byte 
but the last one of a 2048 bit prime can be fixed, on average, due to 
the high density of primes. It suggests that the task of finding a 
collision with public keys is at least no more difficult than for ASCII 
documents.

Not all scenarios involving fingerprint depend on collision resistance. 

Last call for ECC in OpenPGP

Hi,

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

Salam-Shalom,

   Werner

From: The IESG <iesg-secretary <at> ietf.org>
Subject: Last Call: <draft-jivsov-openpgp-ecc-10.txt> (ECC in OpenPGP) to Proposed Standard
Date: 2012-03-12 13:57:39 GMT

The IESG has received a request from an individual submitter to consider
the following document:
- 'ECC in OpenPGP'
  <draft-jivsov-openpgp-ecc-10.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2012-04-09. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the

Review of draft-ecc-09

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. ]

> 5. Supported public key algorithms
> 
>    Supported public key algorithms are Elliptic Curve Digital
>    Signature Algorithm (ECDSA), defined in [FIPS 186-2], and Elliptic
>    Curve Diffie-Hellman (ECDH), defined in section 8.

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

> 6. Conversion primitives
> 
>    The method to convert an EC point to the octet string is defined in
>    [SEC1].  This specification only defines uncompressed point

MIME media type literal packet in OpenPGP