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 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
actually sign the timestamp itself other than to say the user intended
for it to be there.

Another factor favoring unsigned timestamps is that with hashing-based
timestamps they often can be extended after the fact. For instance, in
GuardTime's implementation a timestamp is first submitted to a 'level'
with a 1 second interval, quickly returning the timestamp. However its
only later that the merkle tree is timestamped permanently by inclusion
into a widely-witness newspaper ad. An unsigned timestamp allows you to
extend your timestamp after the fact to include all the intermediary
digests required to link it to that permanent, trustworthy record.
Similarly timestamps from different notaries may be collected at a later
time.

However, timestamping signatures themselves can also be useful. If a key
is compromised after some known date, a timestamp of a signature before
that date can still be trusted.


As for timestamping PGP keys in theory it can help determine
trustworthyness by making the assumption that the earlier key is the one
that is valid. (in addition to WOT and other evaluations) However, it is
not as simple as just timestamping the fingerprint of the primary key,
because an attacker can always re-use an existing key, and create new
User ID packets and sign them; you need to sign the User ID packets as
well. Unfortunately this isn't a very easy to understand user
experience, and evaluating exactly what is being proven is subtle.


Regardless all this does suggest that one timestamp packet be used for
the whole signature allowing for multiple elements to be incorporated
into one merkle tree within that packet to be timestamped in one go,
saving space. In this case I think it would make most sense to either
define a new packet type, or simply use a signature packet missing the
actual signature. The latter doesn't really seem ideal though, for
instance it would require a redundent signature creation time.


Anyway, I'd appreciate some comments on my line of thought, in
particular what people think of trade-offs between the simplicity of one
timestamp per signature, and trying to have some sort of common
timestamp packet containing a DAG of hash operations for all timestamped
data, as well as the usefulness of integrating timestamping into OpenPGP
signatures in general.


1) Potentially random beacons such as the Bitcon blockchain or the under
development NIST beacon could be used to prove a signature was created
after a given time, but a random beacon can only prove the signature,
not the data being signed.

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 
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 
http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the 
conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of
http://sites.google.com/site/dumpconf for comments from well-known researchers 
about WORLDCOMP. 


The status of your WORLDCOMP papers can be changed from scientific
to other (i.e., junk or non-technical) at any time. Better not to have a paper than 
having it in WORLDCOMP and spoil the resume and peace of mind forever!


Our study revealed that WORLDCOMP is a money making business, 
using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing 
out a small chunk of that money (around 20 dollars per paper published 
in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) 
who publicizes WORLDCOMP and also defends it at various forums, using 
fake/anonymous names. The puppet uses fake names and defames other conferences
to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to 
threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). 
That is, the puppet does all his best to get a maximum number of papers published 
at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. 


Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has 
refused to provide the venue for WORLDCOMP’13 because of the fears of their image 
being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 
is taking place at a different resort. WORLDCOMP will not be held after 2013. 


The draft paper submission deadline is over but still there are no committee 
members, no reviewers, and there is no conference Chairman. The only contact 
details available on WORLDCOMP’s website is just an email address! 

Let us make a direct request to Prof. Hamid arabnia: publish all reviews for 
all the papers (after blocking identifiable details) since 2000 conference. Reveal 
the names and affiliations of all the reviewers (for each year) and how many 
papers each reviewer had reviewed on average. We also request him to look at 
the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 


Sorry for posting to multiple lists. Spreading the word is the only way to stop 
this bogus conference. Please forward this message to other mailing lists and people. 


We are shocked with Prof. Hamid Arabnia and his puppet’s activities 
http://worldcomp-fake-bogus.blogspot.com   Search Google using the 
keyword worldcomp fake for additional links.

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

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 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
and Mallory's Fake-Bob key.  A back-sig would provide such a
distinguishing mechanism.

Practically, at least one common implementation (GnuPG) does not create
a back-sig for authentication-capable keys.  Should it do so?  Do other
implementations do so?

Are there any downsides to including a back-sig in every
authentication-capable subkey?

Regards,

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

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 "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
   indicating that the scope of use is limited to otr.  Does such a
   thing already exist?

Option A seems cleaner to me (since no existing implementations would
mistake such a marked subkey as useful for anything else), but i worry
about how it would scale in the bigger picture -- how many such bits are
we going to need to allocate if keys can be useful elsewhere?

OTOH, maybe that's not a big deal.  And option B seems risky in the near
term -- how many OpenPGP implementations will actually respect the
critical bit and reject that subkey binding signature if they know that
they are not in the OTR context?

Suggestions?  Is there some other way i should approach this?

--dkg

[0] https://tools.ietf.org/html/rfc4880#section-5.2.3.21

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

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/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea< at >jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQCVAwUBUOXmrplgi5GaxT1NAQJE/gQApktUxJ2pMJmlNKADeOUdEIQqDcklW3LG
lA52an7QuSFZ4JijFYMMXB+IOkQ0CQU9sghYZw63ZciLr3Y6bYKYCRgEFUGyF4hH
/FiTmlUaQYEgrFPYSmQ0/ZHxiiFs9tVjmid1khBJTvsHNmhIvxbD0n4qZbp5p70g
gfYrgLr0MPQ=
=HCAJ
-----END PGP SIGNATURE-----
_______________________________________________
openpgp mailing list
openpgp< at >ietf.org
https://www.ietf.org/mailman/listinfo/openpgp

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 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. 
For example, the ability to substitute a designated revoker, which 
fingerprint is stored in a subpacket of a public key, is not assisted by 
compromised collision resistance of SHA-1.

As a remedy to the problem note that the collision resistance only 
arises when the original "document" is not available. Fortunately, keys 
are small, and therefore, the suggested enhancement to the RFC4880 to 
remedy the collision dependence of fingerprints on SHA-1 is to store the 
original key. Continuing the above example with non-repudiation, the 
non-repudiation claims will be made against the application logs (i.e. 
audit trails), thus it will be necessary to include complete keys in 
addition to fingerprints in logs that record protocol exchanges that are 
dependent on public key identification.

This concern will need to be communicated somehow to developers that are 
relying on RFC4880.

An alternative method is outlined next. We introduce a new hardwired 
fingerprint, for example, based on SHA-3. The above-mentioned 
application logs can simply state that "SHA-3 fingerprint is XXX" and 
not bother with storing the whole key (which is unfortunately allowed to 
change, for example, by acquiring new userIDs, making it hard to compare 
the revisions). Any subpacket that currently takes the fingerprint will 
be able to take the new SHA-3 fingerprint as well. Applications will be 
expected to calculate two fingeprints in parallel and perform a match 
with either of them. In addition, we might consider a features packet 
forcing or preferring SHA-3 fingeprint (similar to the MDC feature). 
KeyIDs in messages can also use 8 bytes of the new fingerprint.

Regarding compatibility, note that the fingerprint in the subpackets are 
not affected by collision weakness, so that there is no downgrade 
attack. Fingerprints that are sensitive to collision resistance are 
external features. In addition to mentioned application logs, consider 
the UI implication. When a key is looked up by its fingerprint on a key 
server, the UI can offer to search by SHA-1 or the new style fingerprint 
and this will work with any current key.

I will appreciate your comments on this feature. I don't expect this to 
be a task that needs an urgent resolution. In my mind this is something 
that we agree on, have a simple spec, and then take a few years to 
implement and deploy it in a least disruptive way.

If there is a more elegant/simpler solution? I would like to hear about it.

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

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 values...)


Here it is clearly wrong - it is not (curve_size * 2 + 3), but
(curve_size_padded_to_8 * 2 + 3).

Missing detail: In addition to size check, what other validation must
be done when parsing a point?  This applies to when reading a public key,
but especially when reading incoming ECDH/ECDSA message.  I suggest
adding:  "You must check that the point is on curve." here.



This is only place which says that KEK *MUST* be AES-only.  (Ignoring 12.2)
This is in conflict with section 12.1 and 13, where non-AES is not
disallowed.  I'm not disagreeing with it, just I think it would be good
to clarify why.

It might be good idea to disallow cipher_ids < AES128, but why disallow
Camellia and Twofish?  I could imagine that because the algorithm
is not per-message but comes from key is the reason - you may not
know at key generation time all the people who want to send you messages
and what features their software has.  But I think it would be
good to put the reason in the doc.

In any case, 12.1 and 13 should be synced with the requirement.


Missing detail:  How to generate v?  What requirements it has?
I suggest expanding the second step with:

     Generate ephemeral key pair {v, V} where V=vG and v is random number
     in range 0 < v < n  (n - curve modulus)

As I noted earlier 8) claims to define ECDH as used in OpenPGP,
and it does - I managed to implement ECDH without digging in those
"real" specs.  That was the only point that I needed to look up.
I think is worth adding here, mostly because it simple.



First one should be ECDSA.



But MD5 can?  How about RIPEMD160?  Why single out SHA1?


Final note: the section 8 was quite successful at describing ECDH,
how hard would it be to have same level of description of ECDSA here?
At least I would like to see packet format here, even if the 
algorithm is not described.

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 E435AEDF689E2211, and distributes it ahead of Alice.  Now any signatures that Alice issues will result in a "bad signature" error, since they will be verified against the wrong key.

To test, I made both Alice's and Mallory's key and tested with both PGP (9.10) and GPG (1.4 from git).  Basically, the attack works as expected.  Not surprisingly, once one key is imported, you can't import the other one without explicitly deleting the first.  When trying to import the second key, GPG fails with "key 689E2211 doesn't match our copy".  PGP silently ignores the new key.  Not allowing a new key to replace an old one does make some sense (after all, how would the implementation know which is "real" and which is "fake"?), but I can see this being a frustration.  Of course, this is a double-edged sword, since if Alice beats Mallory into the keyring, Mallory is locked out.

In terms of the issue that originally started this thread, the proposal to include and compare the complete fingerprint resolves this attack as well (slightly better in this case, in fact, since a V3 fingerprint can't even accidentally collide with a V4 one).

That said, however, (and switching over to implementation thoughts here) given how easy it is to make a V3 DEADBEEF key that collides with a real V4 key, I wonder if it would also be useful for implementations to simply refuse (or at least give the option to refuse) to import any V3 keys.  That might not have been feasible 10 years ago, but nowadays, I suspect most people would not even notice.  Standards-wise, that is fine as 4880 does not require V3 (discourages it, in fact: MUST NOT create, and only MAY accept).

I've pasted the test keys below if anyone wants to play with them.

David

p.s. the PKESK packet doesn't differentiate between V3 and V4 either but the attack is less obvious there - the victim would have to encrypt to the wrong key, and we at least theoretically have the means to discourage this via the web of trust.  It would still be an annoyance, though.

Alice:

-----BEGIN PGP PRIVATE KEY BLOCK-----

lQOYBE1b9LkBCADgluafn3zba/PMOZqlfNgma16vJ0lpZO9535NgJQEQulSLHzQx
vqoTRSF/KEGjzwWpPD1LLl0ZojeVAX6quGCM0n0wVncGU3TfurPpS9VB7/7R32gY
5eTgQqGx6pFY7KqReIYvIE5pkr5Dc8/eqZxOkQgzCFlH4h4itQqvo1TK35RpcUne
i0lHUEDaYySVYpIdAmOoMLgus5vU/bocwBfpo+GxdTkWtxoWY/4h/vY+lyO3r/qH
mDk9EddxAurR/TjtWe5INxuwXJIsGmmJDdFR7FJ1cAmsYLvF3QsH8qu/89zOZL9+
oV2vcVCPXoG+l0itmDrDY33rY9xP+rG2KL4XABEBAAEAB/0eVXisF0AnlBVnVbcZ
IkXrgoBVC0BeF3+aKA62uKjD1/bdR4dRhLK3TD9cS6qknlc3EWd8ml7WvH3iBplT
ePhewiXzJmqIad3qQ0RTfqY8yVZ92ufWHQ7kaft+6p4GXbN4AchV4HjWx4wifieV
p7ZF4k7c3a7Oslq8Tf7gfstQDyaDDO4d1fBWuE5C3roQI002zOm7XhtFCsc2ANK3
a7Lo1MGJHezacM6D+pNgUfpJaZnhtF6osXmO3ZRrqO47lgzN1K1HsiexvghmLC9r
GjupbOr5g9VFzuAey4SpQalXoL04Xm0rlmHRVdrCKQXeHVZ+MxkBw46GZ14UcjiD
6qSxBADvbwv2cx78Sb/BqS8anAICLcRDJ0rInVPoE/YIPs8GYaAwjXXlVQsFRWBc
rrH+pUZFHvvayKoXYPYtNO0za+1ZsRnFk6/uccasEHDai5bBrQNBgZ0vb/aHoqvx
i6LS3XVExKyb4220dyX7Azi6Q98SGKMQfnVbBLugCJqD66/laQQA8CDs2t+i10Ws
z6fAUWJems5RMJq9MktQ3jJ/CAkAuXrpxxX1EhhUZM8N9upPdzxY8Iwz0chHCcI4
PYrRNJVNIBH+HBDGFpBLqfcqkXMgUHJtIykD3sl37InQeHgSCP3QHgRF54bucOsu
SPdiO7CmyP5vZiZLza5oojPCLKFNl38D/jUuWOe676OJYZReR56jcq5wKGMGIkeE
jyhO8510c295kbGMWi+voVANaiLalY6YxY4VH2U+xO6CntZjNTZ2U+zuDDH5iywW
rhj+WrwreLewvosmGJ8nfBOIyjefM3DI5EC717L8PaIL730gFEGG5h65t6xbYYLB
b1un9f8zB3PiPzq0GUFsaWNlIDxhbGljZUBleGFtcGxlLmNvbT6JATgEEwECACIF
Ak1cKB8CGw8GCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEOQ1rt9oniIRWSEH
/1bZWEjk/lQXElp81o7ERv/5RHo10bnbkoMl/QT0+5ROf9eaS1f3Vs5F2hMLSZoH
tPSWK6KBywijfFndLUIn2PdiisgPHRqv6cBg1gvfvJiYGdJQUQfJzEwFGyTgNviX
0CKDo8SiGDtrSH5IalnlZ1L0vZR8iTESQisOX5AlLTc45sDUnfWUmAddd+aQSKRu
1ZtWvgl3K/D4bMhFSenBXj4Ul0JekLZXPXBZbmf4zFrNUtzGsayksGq2qG4Z8F+f
BTcdozEV7V3k0sjlnS+s+uyaOPVT6Pui3n4oMV9XfEjCeJtjyg5j2xVqWFPSqvJA
6FZoXO7/Unul2mGfbY/Sg6M=
=cS7P
-----END PGP PRIVATE KEY BLOCK-----

Mallory:

-----BEGIN PGP PRIVATE KEY BLOCK-----

lQOaA01cLasAAAEIAOCW5p+ffNtr88w5mqV82CZrXq8nSWlk73nfk2AlARC6VIsf
NDG+qhNFIX8oQaPPBak8PUsuXRmiN5UBfqq4YIzSfTBWdwZTdN+6s+lL1UHv/tHf
aBjl5OBCobHqkVjsqpF4hi8gTmmSvkNzz96pnE6RCDMIWUf2ZZRTbUmnJGlWMW5N
0j4Kw95dG2cQQKFhhHT3PsP62iHrYP0P62cGCv5f9RwwNXpLS/c3hSpBTW44fr1j
qHtlDcOjdu4C2i/lqKOthQBjiW5scTl94Cn1HPr+xRwju8AJJ1e7jh5Y8k1SEYHG
wgWFHEVWplwIiajFMRPwpNvWkifJ5DWu32ieIhEAEQEAAQAH/A2L7JM6Ony9sTHj
U5mhwyPmHArykrIBvZQbUTdeZAcPRiQyGKLbfkS1ScTyt6raxNulX4kWXdU6/KFH
Os2vW1uDIrv0qy89f3IzP8DVqyJUCIm+MPg3fautOTWTEXtMoyktHOLgzvn9OO62
oJYsotn2U4lIeqIlkZD1y0TDCSY1SM7hT7Hhb2VDiwC0sD64wj1/WRBgBujcgl57
TrY+Px/mWWicdRawb6qPOicps6WuZULs0cgdf+tZxAdSZ5S7DJPNUtIrrG4grT1A
DIPDNUJy/ww5tp/E2wPDxji5JwVwEGXjn3cabHHa5fY8dslLfLNI736xEu8A//8A
AP//AAEEAO9vC/ZzHvxJv8GpLxqcAgItxEMnSsidU+gT9gg+zwZhoDCNdeVVCwVF
YFyusf6lRkUe+9rIqhdg9i007TNr7VmxGcWTr+5xxqwQcNqLlsGtA0GBnS9v9oei
q/GLotLddUTErJvjbbR3JfsDOLpD3xIYoxB+dVsQ2eQ1rt9oniIRBADwIOza36LX
RazPp8BRYl6azlEwmr0yS1DeMn8ICQC5eunHFfUSGFRkzw326k93PFjwjDPRyEcJ
wjg9itE0lU0gEf4cEMYWkEup9yqRcyBQcm0jKQPeyXfsidB4eBII/dAeBEXnhu5w
6y5I92I7sKbI/m9mJkvNt/AAAAAAAAAAAQQAkmUeSX+lSSVA2pBdjGN3KjNi/EdB
+bR9QJwFG8sRGAveAZ77FrqeLvKjEy8n7v87ahh1pLhgjH12VgR2h2giue9kY4t1
e1AeTBBk+SD8EDbOqFqMSoUtHA0MgOa97ErtOdA/yp05z1QfM+aCEufQSQLF1o/M
ml4rQaRVkf+k5QgyRbQZQWxpY2UgPGFsaWNlQGV4YW1wbGUuY29tPokBFQMFE01c
LavkNa7faJ4iEQECYS0H/1y57OK9C4iTvNl0KcSKvPfKMPikOMw8wCmY1sB0gYgg
nuPgsEMw64Hg/cG30JRBfcXZsaBviQ+nxijagBqeNf0zRMNzla1XIrtTWhD7fy0R
dYuAUZ8aIU4zwSYOHvgJraYG7rhRbKO3shlIQ+gfS6+toAz92OWC+IoYGGvEK1OL
owa0dzAkLCWI3nnT/MMkXUICpr+VlSI3u+iYKbK9WSFE9P3zCqdGkt+3LENQjV9z
c4VuyBUIqHuKU9krJxI7k6U3grYihq94oWYDEkTn8Q7KvGEygCnMdhFaeqtJZ3Ai
OA3548H3mkG3FAYemsC43l/Okn/3uz+xVrMJ4LgfxFk=
=ExMT
-----END PGP PRIVATE KEY BLOCK-----

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, and then the
User ID or User Attribute data."

So, 0xB4 + 4-octet-length + user-id-packet-body ?

The pseudocode I'm working with now (which isn't working) is:

- ----
material = key_fields.map { |key_field|
bitlength(key[key_field]) + key[key_field]
}.join

0x99 + material.length + material + 0xB4 + user_id.body.length + user_id.body
- ----

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

iQIcBAEBCAAGBQJMZqjrAAoJENEcKRHOUZzerpsQAKXYwDdcf1hO8BKGd+AkA0CO
3lWWM/lFgo3ho0gqxDoni9Y3E4eT2VBSJ3mKXrRv0CNy6udyU88rSFECDvcz54CI
Z6nf34DKlTbSpfYuR2/8n+bMhUZR/rnRhmj1Vdmxkz2VuheReWyUn1pEMBx3n4HT
bVymy9KRQn3qZbR5UT5P8DL7xzLucful00V9aFtTC6CxC2ZHKUNl6RMDH0sPHY4o
GEmdnVnlR0VREOgBqPCzAZV3/zcZ+aBqpj7mEi6AtRGvy0Dvi1Pv5YiSgp2tuNDZ
Jv0j6G58NB5MqQWtfMttCLQDGhu6K4FNah+X6QSV2j86H00luSCQSSXB05kmd5Tw
NSu4ZwjdLJOhCJDivI3LajvFKmCFLBsRZf6G1SmeP1zvv4OHMdw0MeG3g93/3M9V
gfpOVi0tvgH8806M77+N/TdBBHrPmqteK4jHAed7NQ6jj0SGdKxp/h0XEfceSQ7w
MmvrJkXS8m7MVIRCv9599a/DoKPbLmhXqsH4Fuo6AfmgdOiaNxt6vJDy7nuQdosN
fZYekGZtpe2Dmj2NgRbz4pamlm6tuMRqsa1t7Q4jViisf4scB7ecV1FX8izFg/nZ
0wDsBb/FzSZTmZYn1zJvDpzy62JOvDGhnGNrGPmSCJxohUNAFr4b2DJq4nRnbm9F
HnVT5e67gsVBXm4Tzz6j
=Pt+h
-----END PGP SIGNATURE-----

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+DSzrDMpe8BUipMHWSzlpd8F35930QB5btg7
GiAnZnsSSxb4DIbZ6sNfpYtHLJPpbR6+sfNK+W7ILwb/ERMVu7Q0SFuOzy/0Yf6z
AILiD5VbQc5vsrEN5GfOnDlb/deM5kWcm0xqdvCZXMZQO5m6AqOoBKj/XXtLcyNL
GMczfpW286Z1aqla3SE3
=OpkO
-----END PGP SIGNATURE-----

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)

iQIcBAEBCAAGBQJLsl0hAAoJENEcKRHOUZzeeiEQALIrdMesbnGdz28npdEDun6U
JyZP+WpUBI0RFESTs3VNTkvvxnNOCuQrg6PDHn10b/06b3hgbpicplAWBglGJSHd
P7/0CG4ADa3yTapyEKZy9lKbjj6s5gUuz6PJVvw+Ph5XIxDfNM3EHRSoHZERaPPI
Cs7ohUE7sxLO2Q8AYxwAQelWdzhCOONDq4WFciXp+ziI9lFVKgZKxFVAOvOLwi3s
EFDpV/6qoVWC5XBJhZPbwHcOaLbBVGwSDnA+lI1JCwtdN1HGsQnnD3fvMSjGsICv
+skfheEpoQI2x8WBq928d5cbuxQaTVKY3aHFT8DyjROUv6tAwaMWObCJ5/+GEy/8
YNAx/ba/NdCBHYFFySlvVV7xvKCeT19t9LeEKys8fbIcrNj3ULP5cNro6hfTc+2d
zu4VcbWIiJ57MuGFks15ear+6O1UN5JLGTSkz1aQx4Tb+5TqliwWRsu+tSJWlUK8
LY5BFf5AZ5w5GF0aGWMMfNj3mHkMkeqL2q1LXoIW9qjikCZRLksn4umS4mf3pM5T
1tEJJ/zfdAeP/4fKrV97vi1Ez7IbOCu+JheRwANTUbdQNWg5ajFF5uf2zxHKsKUN
gRlFzVVgBK4oJyF3tx13oBKFEV8I6B6fhtGi7pkikI6R0UyAklD0jkGMJuD2i3FQ
Gl/I+wEUGcvsdTFQxK5B
=HiOM
-----END PGP SIGNATURE-----

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