headers
mkuusio | 3 Aug 2005 09:57
Picon

Secret key encryption


I need to encrypt secret data of the keypair to prevent attackers from
misusing the keypair. I am using 3DES symmetric algorithm in encrypting
and decrypting the secret key. As a s2k specifier I use Iterated and
Salted S2K, so in the encryption process I need the secret passphrase, 
the Coded count,  an 8-octet salt value and an 8-octet Initial Vector. My
question is: is the Initial vector some arbitrary data like salt values
are? In this case it would be some 64-bit random number. And what about
the coded count value? What affects to the value? I have generated my keys
so far with gnu privacy guard software and the count has always been 96
(65536) in every key. I didn`t find solution to this from the RFC2440. Can
someone clarify this?
Permalink | Reply | 0 comments |
headers
Jon Callas | 3 Aug 2005 14:57
Gravatar

Re: Literal+Literal


On 21 Jul 2005, at 3:03 PM, David Shaw wrote:

>
> A while back (2003), I noticed a inconsistency in the draft.  The
> problem was one of those fiddly grammar things: some text in the draft
> said that multiple literal packets in a row were legal, and some other
> text said that it wasn't.  For example, in that draft,
> COMPRESSED(literal+literal) was legal in section 5.6, and illegal in
> 10.2.
>
> To resolve that, I suggested that we simply change 10.2 (the grammar
> section) to allow literal+literal.  That's how the draft reads now.
> Several people have commented that this is raising more problems than
> it is solving, and they're right.  Literal+literal raises a whole
> collection of issues with how to hash the data in a construction like
> onepass+literal+literal+sig.  It also requires parsers to be more
> complex (though at least the parsers in PGP and GPG always worked this
> way).
>
> I'd like to change the text to fix this, and solve this problem a
> different way: rather than resolve the inconsistency by making
> literal+literal legal everywhere, better to resolve the inconsistency
> by making literal+literal illegal everywhere.
>
> The specific changes would be:
>
> Section 5.6 (Compressed Data Packet) - change "literal data packets"
> to "a literal data packet".
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Hal Finney | 3 Aug 2005 18:24

Re: Secret key encryption


> I need to encrypt secret data of the keypair to prevent attackers from
> misusing the keypair. I am using 3DES symmetric algorithm in encrypting
> and decrypting the secret key. As a s2k specifier I use Iterated and
> Salted S2K, so in the encryption process I need the secret passphrase, 
> the Coded count,  an 8-octet salt value and an 8-octet Initial Vector. My
> question is: is the Initial vector some arbitrary data like salt values
> are? In this case it would be some 64-bit random number. And what about
> the coded count value? What affects to the value? I have generated my keys
> so far with gnu privacy guard software and the count has always been 96
> (65536) in every key. I didn`t find solution to this from the RFC2440. Can
> someone clarify this?

Yes, the IV should be a 64 bit random number.

The purpose of the coded count is to slow down dictionary attacks.  In a
dictionary attack, someone who gets access to the secret key ring tries
all possible pass phrases.  By slowing down the operation of turning a
passphrase into the 3DES key that unlocks the secret key, it makes the
dictionary attacker's job harder.

Choosing a value for the coded count is a tradeoff.  Larger values will
help defend against dictionary attacks, but they will also slow down
the process of unlocking the key for legitimate users.  If keys in your
application will be unlocked by human users typing in their passphrases,
then larger coded counts would be acceptable, providing for delays of 1/10
or even 1/2 second or more.  If your application must expose the secret
key data structure, again larger coded counts would be appropriate.
On the other hand, if your application involves an automated system
which must frequently unlock keys, and/or if you are confident that
(Continue reading)

Permalink | Reply | 0 comments |
headers
g kare | 3 Aug 2005 21:08
Picon
Favicon

PGP questions


Hi,

I am trying to get my company to upgrade to PGP 9, but he is voicing concern 
that PGP has gone through so many management changes, that is reluctant to 
spend $$$ on PGP.

Can anyone speculate on what the future holds for PGP Corp?  Is there a 
future for them?

Are there any viable alternative products to PGP?

Thanks,

Gary
Permalink | Reply | 1 comment |
headers
Werner Koch | 3 Aug 2005 21:58
Picon
Favicon

Re: PGP questions


On Wed, 03 Aug 2005 19:08:44 +0000, g kare said:

> Can anyone speculate on what the future holds for PGP Corp?  Is there
> a future for them?

This is a list of the IETF OpenPGP WG; it is purely a technical list
and not a business oriented one.  Please ask elsewhere.

> Are there any viable alternative products to PGP?

Sure, I'd say.

Shalom-Salam,

   Werner
Permalink | Reply | 0 comments |
headers
Simon Josefsson | 3 Aug 2005 23:02

OpenPGP header (was: Re: Meet in Paris?)


I forgot to raise the question of whether the WG wishes to adopt this
document as a work item.  Is there interest in doing so?

I fear the precise wording to deal with a "supports" token may be
contentious, and will likely bring back the PGP/MIME vs vanilla PGP in
e-mail environments discussion, so hold that in mind when deciding.

I think there are two orthogonal questions that a "supports" token
could address:

  1) Preference between PGP/MIME, vanilla PGP, or hybrid.
  2) To signal that the originator wants personal e-mail PGP
     encrypted.

It may be overloading to have the same token address both matters;
arguing for two new tokens.  It may also be that either one of 1) or
2) should not be done now.  As a proponent of a PGP/MIME-only e-mail
world -- possibly except for the few cases [1] when vanilla PGP can be
used interoperable -- I would not mind if 1) was not supported at all.

Thanks,
Simon

[1] US-ASCII, no format=flowed, no lines starting with From or '-',
see <http://josefsson.org/inline-openpgp-considered-harmful.html>

Derek Atkins <derek <at> ihtfp.com> writes:

> I'd be happy to put you on for 5-10 minutes?  I really don't
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hal Finney | 3 Aug 2005 22:40

Re: PGP questions


This list is for technical discussion of the data formats used by
the OpenPGP standard.  You might want to try the pgp-users mailing
list, http://www.cryptorights.org/lists/pgp-users/ .

Hal Finney

> From: "g kare" <gkare <at> hotmail.com>
> To: ietf-openpgp <at> imc.org
> Subject: PGP questions
> Date: Wed, 03 Aug 2005 19:08:44 +0000
>
>
> Hi,
>
> I am trying to get my company to upgrade to PGP 9, but he is voicing concern 
> that PGP has gone through so many management changes, that is reluctant to 
> spend $$$ on PGP.
>
> Can anyone speculate on what the future holds for PGP Corp?  Is there a 
> future for them?
>
> Are there any viable alternative products to PGP?
>
>
> Thanks,
>
> Gary
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jon Callas | 4 Aug 2005 16:09
Gravatar

Re: Draft Minutes of OpenPGP


On 4 Aug 2005, at 4:08 AM, Ian Grigg wrote:

> I don't think it is necessary to "kill mime" but I don't
> have much hope for its survival.  As it only works
> when the other client also understands the format,
> it is facing an uphill battle.  ascii-armouring works
> much better as the user becomes the fallback.
>

Thank you, Ian.

Nor do I want to "kill mime." I don't want to kill MIME. That 
mischaracterizes what I said.

All I want is not to be forced to do MIME. Unfortunately, it appears 
that there are a lot of people who denigrate text, and think that if 
you say, "Hey, I like text!" then that means you want to kill MIME.

	Jon
Permalink | Reply | 0 comments |
headers
Hal Finney | 4 Aug 2005 18:34

Re: Draft Minutes of OpenPGP


Derek wrote:
>         - update milestones - proposal given.
>
> -- Proposed Milestones
>
>         - No Objections

What were the proposed milestones?

Hal Finney
Permalink | Reply | 0 comments |
headers
Ian Grigg | 4 Aug 2005 13:08

Re: Draft Minutes of OpenPGP


On Thursday 04 August 2005 09:46, Derek Atkins wrote:

>  [Jon]  - Wants support to plain inline text - kill mime and only use plain text as a personal preference.

I'd agree with this.  OpenPGP needs to support a
basic mechanism to use open text channels in the
most robust fashion.  The ascii-armouring has passed
the test of time in this fashion.

I don't think it is necessary to "kill mime" but I don't
have much hope for its survival.  As it only works
when the other client also understands the format,
it is facing an uphill battle.  ascii-armouring works
much better as the user becomes the fallback.

OpenPGP needs to think in terms of email being
a lesser and lesser influence.  IMO, email is dying.
That's debateable, but what is clear is that the star
of IM is on the ascendancy, and the email thing is
losing that battle.

Currently, IM is mostly unsecured (there is this thing
to do with SSL to the server, but as the threat is on
the node, that's ignorable).  The way to approach
securing chat (IMHO) is to layer OpenPGP over the
top in a transparent fashion.

That means ascii-armouring for the moment.
(Continue reading)

Permalink | Reply | 13 comments |

Gmane