Re: Problems with GPG El Gamal signing keys?

2003-12-01 Thread Anton Stiglic

- Original Message - 
From: Ralf Senderek [EMAIL PROTECTED]
To: Werner Koch [EMAIL PROTECTED]; cryptography [EMAIL PROTECTED]
Sent: Thursday, November 27, 2003 11:23 AM
Subject: Re: Problems with GPG El Gamal signing keys?


 On Thu, 27 Nov 2003, Werner Koch wrote:

  Yes, yes, I should have removed ElGamal signing key support back in
  1998 when there was no more need for it.  I recall that some folks
  begged me not to do that and I took the wrong decision.

 I think no-one will blame you for this, you couldn't have known the
 effects. But what are we going to learn? Heading for far less complexity
 is the future!

Maybe we can learn that code re-use is tricky in cryptography:  indeed, if
the signing function and encryption function did not use the same gen_k
function, the author of the code would have done the optimization that
causes the vulnerability in the signing function because this has never been
recommended (while for encryption it is a well known recommendation).

Maybe we can learn that using the same key for two different things is
really really not a good idea!  If the vulnerability was restricted to
signatures
it would have been less severe, being able to decrypt all confidential
messages
that were created in the past is much more severe.  Allot of applications
use
one single key for both signing and encryption, while this doesn't seem to
be
immediately dangerous I don't think it's a good idea. For example when I
receive
an email from someone that is signed, Outlook will save the public signature
key
that comes with the message and use it to encrypt if I decide to send an
encrypted
message to that person.
I never understood why having separate keys for signing and encrypting was
so complicated to implement?Also in the PoP protocol of X.509, a
signature
using the private key is used to prove possession of the private key
corresponding to a public encryption key.  While the different padding used
in signature and encryption schemes make it difficult to find an obvious
vulnerability with this, I don't think it's a good idea.

You have to be very careful when using the same key pair for encrypting and
signing.  The subtle error found in GnuPG about using small k is a good
example.  Another thing to consider is that ElGamal encryption with base
g = 2 is safe but insecure for signatures...  It's just simpler to have two
distinct pairs of keys.

By the way, is the paper by Phong Q. Nguyen describing the vulnerability
available somewhere?  Or maybe someone could describe the cryptanalysis
steps to retrieving the private key from the signature when using smaller
random k, I would appreciate.  ElGamal with smaller k looks allot like
DSA, exept in DSA you work with a generator of a smaller subgroup and
your k is chosen in this smaller subgroup...

Thanks.

--Anton



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: lockable trapdoor one-way function

2003-12-01 Thread Jerrold Leichter
| Does anyone know of a trapdoor one-way function whose trapdoor can be locked
| after use?
|
| It can be done with secure hardware and/or distributed trust, just delete
| the trapdoor key, and prove (somehow?) you've deleted it.
|
| It looks hard to do in trust-the-math-only mode...
You're going to have to be much more explicit about the details to have any
hope of getting at this.  If you take too naive an approach, even a simple
trapdoor function is impossible.  Given f(X), it's impractical to compute
X.  However, whoever computed f(X) can of course give you X!  So one sets
it up as something like:  If we have any probabilistic Turing machine T
(subject to some constraints on size and running time) which is given an input
tape containing f(X), then over all X and all runs of the machine, the
probability that it halts with the tape containing X is less than (some limit
not much bigger than the probability of just just guessing X correctly).
This is the only way I know of to capture the notion of T is only given f(X).
But this whole approach can't possibly model the notion of forgetting X,
since the only way you can *prove* you've forgotten something is to display
that *all* possible memory you have access to, or will have access to in the
future, is (say) zeroed.

You could certainly spread the trust out.  For example, one could imagine a
trap door computed using shared-secret techniques:  The trap door information
is shared among K participants.  The K participants jointly compute the trap
door function.  Even *after* the computation is complete, it still takes all
K participants to compute the function.  So if we now tell all the participants
to forget their portion of the secret, if you trust *any* of them to do so,
the trap door information is gone.

Even this has a subtlety:  What's to prevent a participant - or anyone else? -
from storing X,f(X) pairs?  So, on the one hand, you may need to state the
requirement in terms of being able to compute f(X) or its inverse on data that
had never been presented to the K participants.  Alternatively, you could
insist that the K participants individually never see X or f(X).  (But then
who *does* see them to distribute and finalize them?)

There's the seed of an interesting primitive here, but exactly what it is
seems difficult to pin down.  What application do you have in mind for such a
thing?
-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Problems with GPG El Gamal signing keys?

2003-12-01 Thread Steven M. Bellovin
In message [EMAIL PROTECTED], Anton Stiglic writes
:

By the way, is the paper by Phong Q. Nguyen describing the vulnerability
available somewhere?  

This note appeared on the IETF OpenPGP mailing list.

--

Subject: Re: Removing Elgamal signatures
From: David Shaw [EMAIL PROTECTED]
Date: Mon, 1 Dec 2003 12:31:11 -0500
To: [EMAIL PROTECTED]


On Mon, Dec 01, 2003 at 08:46:25AM -0800, Hal Finney wrote:
 It would be good to see these results made available because they might
 turn out to be applicable to other types of keys that we might consider
 in the future.

The paper is as yet unpublished, but the author's web page with
contact info is http://www.di.ens.fr/~pnguyen/


--Steve Bellovin, http://www.research.att.com/~smb


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Halifax Airport Launches Iris Scanning

2003-12-01 Thread R. A. Hettinga
http://www.news.gc.ca/cfmx/CCP/view/en/index.cfm?articleid=73249;

 

 

Monday, Dec. 1, 2003
22:42 EST

Halifax International Airport launches CANPASS - Air

 

Halifax International Airport launches CANPASS - Air

Halifax, December 1, 2003... The CANPASS - Air program at Halifax
International Airport (HIA) was officially launched today.

Halifax is only the second international airport in Canada to implement the
iris-recognition technology used in CANPASS - Air. The CANPASS - Air
program allows the Canada Customs and Revenue Agency (CCRA) to manage risk
effectively. This program permits pre-approved travellers to clear customs
and immigration quickly and securely. It is a clear example of how the CCRA
and Citizenship and Immigration are working collaboratively to strengthen
our border and to protect the safety and security of Canadian citizens.

CANPASS - Air showcases our commitment to modernizing, securing, and
streamlining the process for travellers, said Geoff Regan on behalf of the
Minister of National Revenue, Elinor Caplan. It is another example of how
the CCRA implements programs that balance security with the free flow of
travellers.

In conjunction with other new technologies, CANPASS - Air checks clients
against a security system as if they were meeting an officer in person and
refers suspect clients for further inspection. Members of the program can
now pass through Vancouver and Halifax airports quickly and without
compromising security. CANPASS - Air members clear customs and immigration
by looking into a camera lens that recognizes the iris of their eyes as
proof of identity. Reducing the time it takes for interaction with trusted
clients allows Customs personnel to focus on people they don't know.

Any CANPASS - Air member can now travel through both HIA and Vancouver
International Airport, declare their goods, and pay duties and taxes at the
CANPASS - Air kiosks located in those airports.

CANPASS - Air kiosks are scheduled to open at other international airports
in Canada in the spring of 2004. The program has an annual membership fee
of $50 CDN.

The CCRA expects that the CANPASS - Air Program will be expanded into a
joint program with the United States and that it will be piloted at the
Macdonald-Cartier Airport in Ottawa.

CANPASS - Air enables the CCRA to work with trusted and known clients to
make their Customs experience quick and secure and allowing the focus to be
placed on higher-risk cases.


-- 
-
R. A. Hettinga mailto: [EMAIL PROTECTED]
The Internet Bearer Underwriting Corporation http://www.ibuc.com/
44 Farquhar Street, Boston, MA 02131 USA
... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Big Japanese firms claim encryption breakthrough

2003-12-01 Thread R. A. Hettinga
http://www.theinquirer.net/print.aspx?article=10709print=1


Big Japanese firms claim encryption breakthrough

Elliptic curve cryptosystems

By INQUIRER staff: Monday 28 July 2003, 07:36


NTT, MITSUBISHI and Hitachi today said they have succeded in developing a
more effective type of cryptography based on what the companies call
elliptic curve cryptosystems.

Earlier this year, the European Union started NESSIE 5, a plan to use next
generation cryptography, and chose Camella 6, Misty1 7 and PSEC-KEM as
algorithms - developed by Mitsubishi and NTT.

NESSIE stands for the New European Schemes for Signatures Integrity and
Encryption.

Camellia is a 128-bit block encryption algorithm, Misty1 is a 64-bit block
encryption algorithm, while PSEC-KEM is an NTT public key encryption
algorithm.

The firms said that the new project, codenamed CRESERC, creates public key
cryptosystems using mathematical operations over elliptic curves. ยต


-- 
-
R. A. Hettinga mailto: [EMAIL PROTECTED]
The Internet Bearer Underwriting Corporation http://www.ibuc.com/
44 Farquhar Street, Boston, MA 02131 USA
... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]