Subject: OpenPGP key fingerprints and stuff

From: "John S. Bucy" <[email-masked]>
Date: Mon, 30 Aug 1999 16:12:22 -0400 (EDT)

I'm in the process of developing a system that uses the OpenPGP message
format to encode messages sent over the network and have run into the
following issue:  The spec (RFC2440) states that signatures should contain
a "issuer's key ID" hashed subpacket.  I don't understand why this packet
wasn't defined to be an "issuer's key fingerprint" instead.  It seems to
me like it would save a huge amount of effort that implementations have to
go to to avoid problems with key ID collisions.

It would make my code substantially simpler if I could have a "signer's
key fingerprint" instead.  And as the spec stands, I have to define my own
subpacket type for it.  Since the ID can be directly derived from the
fingerprint and they both have distinct, fixed lengths, it seems to me
like you could unambiguously use either one or the other in the same
subpacket without any other indication of which it was; if the length is 8
bytes, its the ID, if its 20 bytes, its the fingerprint. Any thoughts?

thanks
john

-------------------------------------------
John Bucy

"My mind is going....I can feeeeeeel it..."

[email-masked]
-------------------------------------------

---

From: Dave Del Torto <[email-masked]>
Date: Mon, 30 Aug 1999 15:14:16 -0700

>go to to avoid problems with key ID collisions.

Well, but that collision problem is computationally non-existent,
since an OpenPGP implementor should use the full 64-bit keyID
internally. What you display for the user is a simplified 32-bit
version, which _would_ be vunlerable, as has been proved by the fact
that the new versions of PGP are *still* (arrgh) vulnerable to the
"0xDEADBEEF" attack (duplicate keyID in the UI).

For more info on that, ask Lutz Donnerhacke
<[email-masked]> about his recent "mkhash" code.

>bytes, its the ID, if its 20 bytes, its the fingerprint. ...

Only the last 8 bytes of the 20-byte fingerprint match the (UI) keyID
(and only with the newer DSS/DH keytype).

    dave

____________________________________________________________________________
  Dave Del Torto, security architect               "Have keys, will travel."
  <mailto:[email-masked]>     (air) +1.415.730.3583   (wire) +1.415.334.5533
  PGP/DH:  <http://pgp.surfnet.nl:11371/pks/lookup?op=get&search=0x28C029AF>
  Fingerprint: 9b29 031d 70de f566 e076 b108 904d fea3 28c0 29af  Size: 4096
  PGP/RSA: <http://pgp.surfnet.nl:11371/pks/lookup?op=get&search=0xD263D819>
  Fingerprint: c51f 47a9 30ae f132 27eb 5e75 2390 47c5            Size: 2048

Date: Mon, 30 Aug 1999 15:14:16 -0700
To: "John S. Bucy" <[email-masked]>
From: Dave Del Torto <[email-masked]>
Subject: Re: OpenPGP key fingerprints and stuff
Cc: [email-masked]
Sender: [email-masked]

>go to to avoid problems with key ID collisions.

Well, but that collision problem is computationally non-existent,
since an OpenPGP implementor should use the full 64-bit keyID
internally. What you display for the user is a simplified 32-bit
version, which _would_ be vunlerable, as has been proved by the fact
that the new versions of PGP are *still* (arrgh) vulnerable to the
"0xDEADBEEF" attack (duplicate keyID in the UI).

For more info on that, ask Lutz Donnerhacke
<[email-masked]> about his recent "mkhash" code.

>bytes, its the ID, if its 20 bytes, its the fingerprint. ...

Only the last 8 bytes of the 20-byte fingerprint match the (UI) keyID
(and only with the newer DSS/DH keytype).

    dave

____________________________________________________________________________
  Dave Del Torto, security architect               "Have keys, will travel."
  <mailto:[email-masked]>     (air) +1.415.730.3583   (wire) +1.415.334.5533
  PGP/DH:  <http://pgp.surfnet.nl:11371/pks/lookup?op=get&search=0x28C029AF>
  Fingerprint: 9b29 031d 70de f566 e076 b108 904d fea3 28c0 29af  Size: 4096
  PGP/RSA: <http://pgp.surfnet.nl:11371/pks/lookup?op=get&search=0xD263D819>
  Fingerprint: c51f 47a9 30ae f132 27eb 5e75 2390 47c5            Size: 2048

Date: Mon, 30 Aug 1999 16:12:22 -0400 (EDT)
From: "John S. Bucy" <[email-masked]>
To: [email-masked]
Subject: OpenPGP key fingerprints and stuff 
Sender: [email-masked]

thanks
john

[email-masked]

Date: Mon, 30 Aug 1999 10:28:28 -0700
Subject: COMMERCIAL: Internet Security Conference
From: "Bill Gram-Reefer" <[email-masked]>
To: [email-masked]
Sender: [email-masked]

Please be advised registration is now open for The Internet Security
Conference (TISC) to be held in Boston, October 11-15. Please see
http://tisc.corecom.com for more detail.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Subkey Implementation Question
Date: 30 Aug 1999 14:39:05 GMT
Organization: IKS GmbH Jena
Lines: 12
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* William H. Geiger III wrote:
>Multiple encryption keys using different algorithms (ie a RSA key & an
>ElGamal key) or for allowing new encryption keys to be added after a
>previous key has expired without effecting WOT on the signing key.

Important subject, but not the design issue.

>What other ways are people using subkeys and what issues of subkey
>management have they addressed?

ElGamal keys in NAI implementation are unable to sign anything. So a signing
key was needed.

From: "William H. Geiger III" <[email-masked]>
Date: Sat, 28 Aug 1999 22:10:24 -0500
To: [email-masked]
Subject: Subkey Implementation Question
Sender: [email-masked]

I have a question regarding how people are using subkeys. I understand a
couple of uses for subkeys:

Multiple encryption keys using different algorithms (ie a RSA key & an
ElGamal key) or for allowing new encryption keys to be added after a
previous key has expired without effecting WOT on the signing key.

What other ways are people using subkeys and what issues of subkey
management have they addressed?

-- 
---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
Talk About PGP on IRC EFNet Channel: #pgp Nick: whgiii

Hi Jeff!! :)
---------------------------------------------------------------

Date: Thu, 26 Aug 1999 09:23:34 -0500
From: [email-masked]
Subject: $9.95 wholesale website hosting
To: @imc.org
Reply-To: [email-masked]
Sender: [email-masked]

We offer Web Hosting for the following server platform: NT 4.0 Running IIS4
as low as $9.95/month, paid quarterly or annually, plus a $19.95 set-up fee

All our servers are Dell Poweredge dual PIII 4300 series
Our Connectivity is based on redundant state of the art equiptment

          *** Call Now!!!  for details 888-848-HOST(4678) ***

Our  hosting includes:

FREE!!! Registration of a domain or transfer 
Storage Unlimited
Bandwith Unlimited
FrontPage 2000 extensions FREE!!! 
Unlimited  e-mail accounts
Unlimited Autoresponders
Full Control E-mail Administration
24 hour private FTP access ftp.yourdomain.com 
Your own Cgi-Bin Directory 
Daily tape back-ups
UPS Backups
ODBC Support
Cold Fusion Support
ASP Support
Secure Server (SSL) access
Real Audio/Video
30 Day money back guarantee
Same day set-up 
24 hour access and monitoring of your site 
Access Logs 

                     * Resellers get Special Deals How About*
                           Call for details 888-848-HOST(4678)

From: "Peter lewis" <[email-masked]>
To: <[email-masked]>
Subject: From Firewall to IPSec VPNs
Date: Wed, 25 Aug 1999 10:36:40 +0200
Sender: [email-masked]

Security services and protection mechanisms
IPv6 promises regarding IPSec
Certification infrastructure 
Standardization update
Case Studies: ISPs, carriers, private networks
AH and ESP protocols description
Possible future extensions and modifications of the IKE protocol
Complementarity between IPSec and firewalls
Global Site-to-Site IPSec VPN's with End-to-End SLA's
Managing widespread IPSEC virtual private networks
Solving IPSec VPNs scalability
Results of some interoperability tests
IPSec architectures and non-standardized aspects of IPSec
Adding IPSec VPN functions in an existing router network
Impact of fragmentation on the performance of IPSec coding

IPSEC 99 Conference
>From Firewall to IPSec VPNs

October 26, 27, 28, 29, 1999
Paris - France

More infos: www.upperside.fr/baipsec.htm

Sorry to post this message on the list.

Thanks

Date: Thu, 19 Aug 1999 22:50:39 -0500
From: Marcel Waldvogel <[email-masked]>
To: Jack Repenning <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: PGP Keyserver Synchronization Protocol
Sender: [email-masked]

--nFreZHaLTZJo0R7j
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Jack,

> After working over Baumer's paper a bit, I don't understand the fault=20
> handling bits of the protocol, in chapter 4.  (Wording quoted here are al=
l=20
> from section 4.1, the overview):
>=20
> 	- "When a keyserver detects a gap in the sequence number, it sends a=20
> _request_ message to another keyserver, ..."  When is the gap checked=20
> for?  Upon receipt of an update, no doubt; what about upon receipt of "a=
=20
> _request_ message"?

We thought that the updates and heartbeats should ensure eventual
reliable delivery.  While it might speed up the synchronization by also
acting on requests for unknown sequence numbers, this will require more
bookkeeping at each server. A server willing to seek out for new
sequence numbers based on an incoming request will have to make sure
that it doesn't react to further incoming requests by generating another
request, to prevent livelocks. But other than that, the decision about
the two possible behaviors can be left to the discretion of the
individual implementations (they will still interoperate correctly,
IMHO).

> 	- "... the sequence number ..."  Is that the number of the last contiguo=
us=20
> known event, the first missing, the last missing, or the first received=
=20
> noncontiguous?  In general, there may be missing gaps, not merely single=
=20
> events (indeed, this seems more likely to me).  ("The oldest  missing=20
> sequence number" seems like a good choice, with the implication that this=
=20
> one and all subsequent known events be transmitted.)

Further down, request messages are described to basically contain an
enumeration of missing sequence numbers, represented in either of three
compact forms (ranges, bitmaps, and "everything above x")

> 	- "Then the Nearest Neighbour sends the information..."  What if the NN =
is=20
> also missing the requested info?  Mention of deadlock elsewhere suggests=
=20
> the NN might in turn requery its NN at this point, but this is nowhere=20
> explicit.

The node detecting a missing sequence number will look for the NN having
the information using expanding multicast rings (although building rings
based on increasing TTL will not be too effective in IPv4, where both
scope and TTL are encoded in the TTL). Servers receiving a multicast
request message should not answer if they do not have (part of) the
requested information. Whoever responds first will be considered the NN
for that operation (see 5.8). If all fails, it may revert to the
originator.

> 	- During this period (while a _request_ is pending from the NN), what is
> the behavior of the server with respect to the request itself?  Does it=
=20
> retry its request periodically, and/or after a timeout?  Should the serve=
r=20
> crash in the interregnum, is it obligated to restore itself in some state=
=20
> that will accept (or re-request) this info?  Or does it wait until yet on=
e=20
> more event arrives from the originator?  Does it continue to accept and=
=20
> apply new server-server updates from this originator?  From other origina=
tors?

Expanding MC rings require some timeout mechanism during the expansion.
If a search turns out to be fruitless, the server can schedule a search
for a later time (preferrably some exponential backoff), or can wait for
the next heartbeat to occur, which should trigger the next search.

On a restart, the server can locally check for sequence gaps.
Additionally, it can search for someone responding to a
RequestSequenceCheck (i.e., actively soliciting for a unicast heartbeat
message), or simply wait for the next heartbeat to arrive.

> 	- During this period, does it continue to serve uploads and requests fro=
m=20
> users?  Does it attempt to apply the updates?  (Note that some events, fr=
om=20
> beyond the gap, from other servers, or from users, may not be possible to=
=20
> apply, without the missing data - a new user ID added but lost, for=20
> example, means a subsequent signature on that ID can not be applied - and=
=20
> may not come even from the same originating server, so the potential=20
> extends over all updates.)

Yes. Since users have to submit entire keys, there will be no missing
information. But it can occur that this server is uploaded a packet
which (unknown to us) another server has already issued an ID for, in
which case a single packet will receive a second ID (this is expected to
occur in rare cases). Since the linking between signatures and UIDs and
public keys occurs by sending out the higher-level elements also,
stalls as you describe them should not occur.

> 	- How does the distributed database detect and communicate the case wher=
e=20
> a request to an NN is for some sequence number that in fact does not exis=
t?
>=20
> I'm particularly thinking of a potential global denial-of-service attack,=
=20
> by sending a nonsensically-high sequence number into the mbone.  All=20
> keyservers then query their NN, but none know the answer.  There is no=20
> algorithm apparent here to recover (not to say it couldn't exist, but I=
=20
> don't find it here).

This is true for both request- and update-/heartbeat-triggered
resynchronization and is dealt with in section 5.7, together with other
attacks. The originator can be queried for a signed message containing
the highest sequence number. This assumes that the servers know each
others public key. The signature does not need to be created "live", to
avoid further DoS attacks, but has a lifetime associated with it.
There is also support for cryptographically challenged servers, but
they obviously cannot protect their sequence numbers.

-Marcel

--nFreZHaLTZJo0R7j
Content-Type: application/pgp-signature

--nFreZHaLTZJo0R7j--

From: [email-masked]
To: <[email-masked]>
Subject: BE THE FIRST IN YOUR AREA WITH NEW PERSONAL POSTCARDS!
Date: Thu, 19 Aug 1999 00:35:14 -0400
Sender: [email-masked]

<HTML></P><P ALIGN=3DCENTER><FONT  COLOR=3D"#0000ff" SIZE=3D4 PTSIZE=3D12 F=
AMILY=3D"SCRIPT" FACE=3D"Lucida Calligraphy" LANG=3D"0"><B>The Hottest Bus=
iness Opportunity to Hit<BR>
the U.S. this Year!</FONT><FONT  COLOR=3D"#000000" SIZE=3D4 PTSIZE=3D12></=
B><BR>
</FONT><FONT  SIZE=3D3 PTSIZE=3D10><BR>
</FONT><FONT  COLOR=3D"#000040" SIZE=3D4 PTSIZE=3D12><B>This is not a MLM =
Program !<BR>
</FONT><FONT  SIZE=3D3 PTSIZE=3D10></B> </FONT><FONT  COLOR=3D"#000000" SI=
ZE=3D3 PTSIZE=3D10><BR>
</FONT><FONT  COLOR=3D"#800080" SIZE=3D3 PTSIZE=3D10><B>Earn Full Time Inc=
ome on a Part Time Basis !!!<BR>
<BR>
</FONT><FONT  COLOR=3D"#ff8040" SIZE=3D2 PTSIZE=3D8 FAMILY=3D"SANSSERIF" F=
ACE=3D"Arial" LANG=3D"0">New Photo Postcard vending machines which put you=
r face on a postcard<BR>
are a smashing success throughout Europe.</FONT><FONT  SIZE=3D3 PTSIZE=3D1=
0 FAMILY=3D"SCRIPT" FACE=3D"Lucida Calligraphy" LANG=3D"0"><I><BR>
</FONT><FONT  COLOR=3D"#800080" SIZE=3D3 PTSIZE=3D10><BR>
</FONT><FONT  COLOR=3D"#000000" SIZE=3D2 PTSIZE=3D8 FAMILY=3D"SANSSERIF" F=
ACE=3D"Arial" LANG=3D"0"></I>Now for the first time these machines are ava=
ilable in the U.S. <BR>
The U.S. market will grow to thousands of machines within the next <BR>
12-18 months according to industry experts. We are seeking qualified indiv=
iduals<BR>
who are looking to take advantage of a virtually untapped market opportuni=
ty in<BR>
their area. There are retail locations across the country ......waiting ! =
<BR>
<BR>
</FONT><FONT  COLOR=3D"#0000ff" SIZE=3D4 PTSIZE=3D12 FAMILY=3D"SCRIPT" FAC=
E=3D"Lucida Calligraphy" LANG=3D"0"><I>Timing is Everything !</FONT><FONT =
 SIZE=3D3 PTSIZE=3D10></I><BR>
<BR>
</FONT><FONT  COLOR=3D"#000000" SIZE=3D2 PTSIZE=3D8 FAMILY=3D"SANSSERIF" F=
ACE=3D"Arial" LANG=3D"0">We have developed the new self-service Personal P=
ost Card to take advantage<BR>
of this dynamic market opportunity. Personal Post Cards combines the popul=
arity<BR>
of the following markets:<BR>
<BR>
</FONT><FONT  COLOR=3D"#ff8040" SIZE=3D3 PTSIZE=3D10>Travel and Leisure Ma=
rket $200 billion<BR>
</FONT><FONT  COLOR=3D"#008000" SIZE=3D3 PTSIZE=3D10>Greeting Card $10 bil=
lion</FONT><FONT  SIZE=3D2 PTSIZE=3D8><BR>
</FONT><FONT  COLOR=3D"#800080" SIZE=3D2 PTSIZE=3D8>Photography $30 billio=
n</FONT><FONT  COLOR=3D"#0000ff" SIZE=3D2 PTSIZE=3D8><BR>
</FONT><FONT  COLOR=3D"#800080" SIZE=3D2 PTSIZE=3D8><BR>
</FONT><FONT  COLOR=3D"#0000ff" SIZE=3D5 PTSIZE=3D14 FAMILY=3D"SCRIPT" FAC=
E=3D"Lucida Calligraphy" LANG=3D"0"><I><U>The Opportunity Is:</FONT><FONT =
 COLOR=3D"#800080" SIZE=3D2 PTSIZE=3D8 FAMILY=3D"SANSSERIF" FACE=3D"Arial"=
 LANG=3D"0"></I></U><BR>
<BR>
Part or full time<BR>
</FONT><FONT  COLOR=3D"#008080" SIZE=3D2 PTSIZE=3D8>No selling required<BR=
</FONT><FONT  COLOR=3D"#ff8040" SIZE=3D2 PTSIZE=3D8>No prior experience or=
 office required<BR>
</FONT><FONT  COLOR=3D"#008000" SIZE=3D2 PTSIZE=3D8>All cash business!<BR>
</FONT><FONT  COLOR=3D"#0000ff" SIZE=3D2 PTSIZE=3D8>Financing programs ava=
ilable</FONT><FONT  SIZE=3D3 PTSIZE=3D10><BR>
<BR>
</FONT><FONT  COLOR=3D"#800080" SIZE=3D3 PTSIZE=3D10 FAMILY=3D"SCRIPT" FAC=
E=3D"Lucida Calligraphy" LANG=3D"0"><I><U>For a Free Business Package at N=
o Obligation:<BR>
</FONT><FONT  COLOR=3D"#000000" SIZE=3D3 PTSIZE=3D10></B></I></U><BR>
</FONT><FONT  SIZE=3D3 PTSIZE=3D10 FAMILY=3D"SCRIPT" FACE=3D"Lucida Handwr=
iting" LANG=3D"0"><B><I><A 
</FONT><FONT  COLOR=3D"#008000" SIZE=3D5 PTSIZE=3D14><B>1-888-852-7900</FO=
NT><FONT  SIZE=3D3 PTSIZE=3D10><BR>
</FONT><FONT  COLOR=3D"#000000" SIZE=3D2 PTSIZE=3D8 FAMILY=3D"SANSSERIF" F=
ACE=3D"Arial" LANG=3D"0">Please refer to Code </FONT><FONT  COLOR=3D"#ff80=
40" SIZE=3D2 PTSIZE=3D8>F818</FONT><FONT  COLOR=3D"#000000" SIZE=3D2 PTSIZ=
E=3D8> when you call. <BR>
<BR>
</FONT><FONT  COLOR=3D"#0000ff" SIZE=3D2 PTSIZE=3D8>Customer Service Opera=
tors are available <BR>
Monday-Friday 9:00am - 9:00pm EST Saturday-Sunday 12:00 pm to 8 pm EST.</F=
ONT><FONT  COLOR=3D"#000000" SIZE=3D2 PTSIZE=3D8><BR>
<BR>
If you are outside the U.S. please fax your name, complete phone number<BR=
including country code and a good time for us to call you to (954)236-7264=
 . <BR>
We will respond to your request as soon as possible.<BR>
<BR>
</FONT><FONT  COLOR=3D"#008000" SIZE=3D2 PTSIZE=3D8>This offer is not vali=
d in all statesand should not be considered an offer <BR>
in states where the company is not registered.</FONT><FONT  COLOR=3D"#ff80=
40" SIZE=3D2 PTSIZE=3D8><BR>
<BR>
</FONT><FONT  COLOR=3D"#400040" SIZE=3D2 PTSIZE=3D8>If you no longer desir=
e to receive email from us</FONT><FONT  SIZE=3D3 PTSIZE=3D10 FAMILY=3D"SCR=
IPT" FACE=3D"Lucida Calligraphy" LANG=3D"0">, please email us,</FONT><FONT=
  COLOR=3D"#0000ff" SIZE=3D3 PTSIZE=3D10><BR>
<A HREF=3D"mailto:[email-masked]">CLICK HERE</A></FONT><FONT  CO=
LOR=3D"#0000ff" SIZE=3D3 PTSIZE=3D10>.</P></HTML>
<p><p><p><p><p><p><p><p><p><p>

<HTML></P><P ALIGN=3DCENTER><FONT  COLOR=3D"#0000ff" SIZE=3D4 PTSIZE=3D12 =
FAMILY=3D"SCRIPT" FACE=3D"Lucida Calligraphy" LANG=3D"0"><B>The Hottest Bu=
siness Opportunity to Hit<BR><p>the U.S. this Year!</FONT><FONT  COLOR=3D"=
#000000" SIZE=3D4 PTSIZE=3D12></B><BR><p></FONT><FONT  SIZE=3D3 PTSIZE=3D1=
0><BR><p></FONT><FONT  COLOR=3D"#000040" SIZE=3D4 PTSIZE=3D12><B>This is n=
ot a MLM Program !<BR><p><p><p><p><p><p><p><p><p><p></BODY></HTML>

From: "=?iso-8859-1?Q?Jorge_S=E1nchez_Arriazu?=" <[email-masked]>
To: <[email-masked]>
Subject: Source code 
Date: Fri, 13 Aug 1999 19:19:47 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0024_01BEE5C0.CED68780
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0025_01BEE5C0.CED68780"

------=_NextPart_001_0025_01BEE5C0.CED68780
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

I'd like to be in touch with people who have worked with this code to
ask them some technical questions about how some functions work, about =
which
algorithms are used by PGP to do different things and about other stuff =
like
that.
Another question, is there any book or document discussing the source =
code of PGP in detail instead of just listing it? I've heard about a =
PGPsdk programmer's manual but I Can't download it from www.pgp.com =
because I'm in Spain (I haven't seen it in www.pgpi.com)

Jorge.

---------------------------------
Jorge S=E1nchez Arriazu
C/Jer=F3nimo Alcal=E1 Y=E1=F1ez, 6, 6=BAA, 30003-Murcia. Spain
Tel=E9fono: 00 34 968 220976
[email-masked]
---------------------------------

------=_NextPart_001_0025_01BEE5C0.CED68780
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><EM><FONT face=3D"Lucida Console" size=3D2>Hello,</FONT></EM></DIV>
<DIV>&nbsp;</DIV>
<DIV><EM><FONT face=3D"Lucida Console" size=3D2>I'd like to be in touch =
with people=20
who have worked with this code to<BR>ask them some technical questions =
about how=20
some functions work, about which<BR>algorithms are used by PGP to do =
different=20
things and about other stuff like<BR>that.</FONT></EM></DIV>
<DIV><EM><FONT face=3D"Lucida Console" size=3D2>Another question, is =
there any book=20
or document discussing the source code of PGP in detail instead of just =
listing=20
it? I've heard about a PGPsdk programmer's manual but I Can't download =
it from=20
<A href=3D"http://www.pgp.com">www.pgp.com</A> because I'm in Spain (I =
haven't=20
seen it in <A =
href=3D"http://www.pgpi.com">www.pgpi.com</A>)</FONT></EM></DIV>
<DIV><EM><FONT face=3D"Lucida Console" size=3D2></FONT></EM>&nbsp;</DIV>
<DIV><FONT face=3D"Lucida Console" size=3D2><EM>Jorge.</EM></FONT></DIV>
<DIV><EM><FONT face=3D"Lucida Console" size=3D2></FONT></EM>&nbsp;</DIV>
<DIV><EM><FONT face=3D"Lucida Console"=20
size=3D2>---------------------------------<BR>Jorge S=E1nchez =
Arriazu<BR>C/Jer=F3nimo=20
Alcal=E1 Y=E1=F1ez, 6, 6=BAA, 30003-Murcia. Spain<BR>Tel=E9fono: 00 34 =
968 220976<BR><A=20
href=3D"mailto:[email-masked]">[email-masked]</A><BR>--------------=
-------------------<BR></DIV></FONT></EM></BODY></HTML>

------=_NextPart_001_0025_01BEE5C0.CED68780--

------=_NextPart_000_0024_01BEE5C0.CED68780
Content-Type: text/x-vcard;
	name="=?iso-8859-1?Q?Jorge_S=E1nchez_Arriazu.vcf?="
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="=?iso-8859-1?Q?Jorge_S=E1nchez_Arriazu.vcf?="

BEGIN:VCARD
VERSION:2.1
N:S=E1nchez Arriazu;Jorge
FN:Jorge S=E1nchez Arriazu
TEL;HOME;VOICE:00 34 968 22 09 76
ADR;HOME:;;c/ J. Alcal=E1 Y=E1=F1ez, 6, =
6=BAA;Murcia;Murcia;30003;Espa=F1a
LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:c/ J. Alcal=3DE1 Y=3DE1=3DF1ez, =
6, 6=3DBAA=3D0D=3D0AMurcia, Murcia 30003=3D0D=3D0AEspa=3DF1a
EMAIL;PREF;INTERNET:[email-masked]
REV:19990813T171946Z
END:VCARD

------=_NextPart_000_0024_01BEE5C0.CED68780--

Date: Mon, 2 Aug 1999 09:50:12 +0200 (MET DST)
To: [email-masked]
From: Sven Wohlgemuth <[email-masked]>
Subject: Re: typo in rfc2440: secret key packet format
Cc: [email-masked]
Sender: [email-masked]

Hello,

now I see :-)
Thank you very much!

Regards,
Sven Wohlgemuth

At 9:49 Uhr -0700 30.07.1999, [email-masked] wrote:
>Sven Wohlgemuth, <[email-masked]>, writes:
>> Has a string-to-key specifier to follow the specification of the symmetric
>> algorithm?
>
>It does, if there was a 255 and then the symmetric algorithm.  It must
>not, if you just put in the symmetric algorithm and didn't put a 255
>first.
>
>> Since I can use the MD5 hash value of the passphrase as a symmetric key.
>> Why should I write
>> 	255, 1
>> if I just want to use a symmetric algorithm without a s2k-specifier?
>
>You don't have to.
>
>>
>> >>      - One octet indicating string-to-key usage conventions.  0
>> >>        indicates that the secret key data is not encrypted.  255
>> >>        indicates that a string-to-key specifier is being given.  Any
>> 								    ===
>> >>        other value is a symmetric-key encryption algorithm specifier.
>> 	  =============================================================
>> Isn't it possible to write
>> 	1, enc_MPI, ...
>> 1 for the sym. algorithm follwed by the encrypted MPIs, instead?
>
>Almost.  There needs to be an IV before the encrypted MPIs start.
>
>The idea is that there are three formats.  Unencrypted looks like:
>
>	0, MPI, ...
>
>The simpler encrypted case is similar to your last suggestion:
>
> 	<symmetric-alg>, <IV>, enc_MPI, ...
>
>This uses the default "simple" string-to-key conventions.
>
>The more complex one is:
>
>	255, <symmetric-alg>, <string-to-key>, <IV>, enc_MPI, ...
>
>This allows you to specify a different string to key specifier.  That is
>the reason for the more complex format.  The iterated/salted string-to-key
>is superior as it makes it harder to guess passphrases for someone who
>gets hold of the private key.
>
>Hal Finney

Sven Wohlgemuth, Department 14, Computer Science, University of
Saarbruecken, Germany, <http://fsinfo.cs.uni-sb.de/~wohlgemuth>,
PGP-Fingerprints:
RSA: 46C3 B9EB B21D EAAF  63C7 D667 F040 88A7
DSS: 56F0 55A2 4DF8 53C1 1E0E  52CB E196 5D18 894F 7C23