ECC 2005 announcement

[R.A. Hettinga]

--- begin forwarded text


From: Tanja Lange <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: ECC 2005 announcement
Date: Sat, 5 Mar 2005 14:40:42 +0100
Organization: DTU

--
THE 9TH WORKSHOP ON ELLIPTIC CURVE CRYPTOGRAPHY (ECC 2005)

Technical University of Denmark, Copenhagen

September 19, 20 & 21, 2005

First AnnouncementMarch 5, 2005

ECC 2005 is the ninth in a series of annual workshops dedicated to the
study of elliptic curve cryptography and related areas. Over the past
years the ECC conference series has broadened its scope beyond
curve-based cryptography and now covers a wide range of areas within
modern cryptography. For instance, past ECC conferences included
presentations on hyperelliptic curve cryptography, pairing-based
cryptography, quantum key distribution, AES, implementation issues,
and deployments (e.g., cryptography for travel documents).

At the same time ECC continues to be the premier conference on
elliptic curve cryptography. It is hoped that ECC 2005 will further
our mission of encouraging and stimulating research on the security
and implementation of elliptic curve cryptosystems and related areas,
and encouraging collaboration between mathematicians, computer
scientists and engineers in the academic, industry and government
sectors.

As with past ECC conferences, there will be about 15 invited lectures
(and no contributed talks) delivered by internationally leading
experts. There will be both state-of-the-art survey lectures as well
as lectures on latest research developments.

Sponsors:
o Certicom
o ECRYPT - European Network of Excellence in Cryptography
o escrypt
o HGI Ruhr-University Bochum
o Technical University of Denmark
o University of Duisburg Essen, Campus Essen
o University of Waterloo

Organizers:

o Gerhard Frey   (University of Duisburg-Essen)
o Tanja Lange   (Technical University of Denmark)
o Alfred Menezes   (University of Waterloo)
o Christof Paar   (Ruhr-Universität Bochum)
o Scott Vanstone   (University of Waterloo)

Confirmed Speakers:
o Peter Beelen  (Technical University of Denmark, Copenhagen)
o Claus Diem(University Duisburg-Essen, Germany)
o Steven Galbraith  (Royal Holloway University of London, UK)
o Rob Gallant   (Certicom, Canada)
o Florian Hess  (TU Berlin, Germany)
o Lars Knudsen  (Technical University of Denmark, Copenhagen)
o Kenny Paterson(Royal Holloway University of London, UK)
o Christophe Ritzenthaler   (CRM Barcelona, Spain)
o Takakazu Satoh(Technical University of Tokyo, Japan)
o Martijn Stam  (University of Bristol, UK)
o Rainer Steinwandt (University Karlsruhe, Germany)
o Scott Vanstone(University of Waterloo, Canada)
o Andre Weimerskirch(escrypt, Germany)

Summer School:
After receiving so much positive feedback we decided to also have a
summer school on ECC the week before, i.e. September 12.-16.th. Our
school will be aimed at PhD students with some background on
cryptography and mathematics and at Post-Docs in neighboring fields.
The speakers are not yet fixed - more details are to follow in the
second announcement.

Travel:
The Technical University of Denmark (DTU) is situated in Kongens
Lyngby, in a suburb of Copenhagen, the Capital of Denmark. There are
local trains commuting between Copenhagen main station and Lyngby and
the ride takes 20 minutes. There are international trains including
night trains to Copenhagen and Copenhagen's airport is served by all
major airlines. Some cheap flight companies also serve Malmö which is
well connected to Copenhagen by train. To find out in more detail how
to get there, check Transportation to DTU.

Accommodations: A list of hotels will be posted before the conference.

For further information, please contact:
 Tanja Lange
 Institute for Mathematics
 Technical University of Denmark
 e-mail: [EMAIL PROTECTED]
 Fax: +45 4588 1399
 Phone: +45 4525 3007

The second announcement will be made in mid-April and will include
registration and local (i.e., accommodation and transportation)
information, and an updated list of confirmed speakers.

If you did not receive this announcement by email and would like to be
added to the mailing list for the second announcement, please send a
brief email to [EMAIL PROTECTED] The announcements are also
available from the web site
www.cacr.math.uwaterloo.ca/conferences/2005/ecc2005/announcement.html
---

--- end forwarded text


-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness an

Re: MD5 collision in X509 certificates

[Anne & Lynn Wheeler]

Victor Duchovni wrote:
What is the significance of this? It seems I can get a certificate for
two public keys (chosen, not given) while only proving posession of the
first. Is there anything else? In what sense is the second public key
useful to the attacker?
the purpose of a certificate is analogous to the old letters of credit 
in the sailing ship days  it supposedly establishes the bonifides of 
the individual in an offline, non-connected world where the relying 
party has no other recourse regarding trust/integrity of the individual 
that they are dealing with.

in the PKI/certificate world ... the relying party receives some sort of 
digitally encrypted/signed information and validates it using the public 
key presented in the attached certificate. a correctly validation then 
implies some kind of 3-factor authentication (although the 
PKI/certificate paradigm tends to totally gloss over this 
characteristic, instead attempting to focus the communities attention on 
the value of the certification as opposed to focusing the attention on 
any possibility/value/trust that some part of 3-factor authentication 
might have occured).

In any case, if the public key (from some source, possibly a 
certificate) is able to validate the transmission, then the relying 
party assumes that some portion of 3-factor authentication occured in 
the access and use of the corresponding private key ... possibly

* something you have (private key exclusively in a hardware token)
* something you know (hardware token won't work appropriately w/o PIN)
* something you are (hardware token requires some biometric)
in any case, given that the relying party accepts the validation by the 
public key as representing some implied 3-factor authentication involved 
in access and use of the corresponding private key ... then the relying 
party may be faced with just who the implied authentication corresponds 
to. In the typical, long time accepted business process ... the relying 
party will have prior relationship with the entity being authenticated 
and it will be explicit and/or implicit in the communication itself. In 
the more modern world, in the situations where the relying party has no 
prior relationship with the authenticated entity ... they will have 
access to online and/or real-time information to establish that fact.

However, certificates were targeted at the offline email world ... where 
the email was created, digitally signed (presumably after some form of 
3-factor authentication occuring to establish access/use of the private 
key), and the email, digital signature, and certificate packaged up and 
sent off to some party that there had been no previous communciation 
(might be considered spam in this day and age). After some number of 
intermediary store-and-forwards stops, the package arrives at the post 
office of the relying party. the relying party eventually calls their 
post office, exchanges emails and hangs up.

At this point the relying party is presented with a digital signed 
message with whom that they had no prior communciation. The attached 
certificate provides the public key for validating the digital signature 
and the rest of the certificate contents is supposedly to attest to some 
characteristic of the email sending party (that the relying party has no 
other way of validating).

The implication is that if i can substitute a public key in some 
certificate that attests to represent some other party  then it may 
be some form of identity theft (fraudulent messages can be created that 
otherwise appear to have originated from you ... and validate with the 
substituted public key). The other might be elevation of privileges  
adding characteristics to a certificate that were otherwise not provided.

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

two-factor authentication problems

[Ed Gerck]

Current solutions for two-factor authentication may be weaker than they
seem. Let me present two cases, including SecurID, for comments.
1. First case, without a clock, take a look at:
 http://www.ietf.org/internet-drafts/draft-mraihi-oath-hmac-otp-02.txt
Because the algorithm MUST be sequence or counter-based, poor
transmission can cause repeated failures to resynch. Also, someone
could get your token and quickly generate dozens of numbers without
you knowing it -- when you use the token later on, your new number is
not accepted and could fall outside the resynch window (even for two
numbers in sequence).
The worse part, however, is that the server side can always fake your
authentication using a third-party because the server side can
always calculate ahead and generate "your next number" for that
third-party to enter -- the same number that you would get from your
token. So, if someone breaks into your file using "your" number --
who is responsible? The server side can always deny foul play.
2. SecurID:
The last comment above applies. The server side always know what
numbers your token should generate now and in for days in the
future (clock drift included) -- and that's how they are recognized.
So, again, if someone breaks into your file using "your" number --
who is responsible?
Cheers,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: MD5 collision in X509 certificates

[Anne & Lynn Wheeler]

Victor Duchovni wrote:
What is the significance of this? It seems I can get a certificate for
two public keys (chosen, not given) while only proving posession of the
first. Is there anything else? In what sense is the second public key
useful to the attacker?
so three kinds of attacks on certificate contents ... the previously two 
mentioned

* identity theft
* privilege escalation
the other is possibly by the relying party against the key owner.
in the early '90s identity certificates were all the rage. some problems 
were at the time the certification took place ... it might not be 
possible for the certification authority to determine all possible kinds 
of identity information that a relying party (at any point in the 
future) might require ... so there was a trend to overloading an 
identity certificate with all possible types of identity information on 
the off chance that something might be useful to some relying party in 
the future. this led to increasing realization that such collection of 
identity information might represent various kinds of privacy violation 
and you saw some retrenching to relying-party-only certificates in the 
mid-90s ... misc. relying-party-only certificates only containing an 
account number to be used in online/real-time transaction (note however, 
in online/real-time relying-party-only scenario it is also trivial to 
show that certificates are redundant and superfluous)
http://www.garlic.com/~lynn/subpubkey.html#rpo

the other thing in the 90s was trying to project a value proposition for 
certificates. there was a lot of FUD and confusion generated about the 
value of certificates to the point that it was frequently obscured that 
it was even necessary to have security and safety around the protection 
and use of the private key ... and/or that any form of 3-factor 
authentication was even involved in the access and use of the private 
key. To this day, you have people writing about using a digital 
certificate to create a digital signature.

So another value representation for digital certificates was that of 
non-repudiation. basically if the non-repudiation flag in a digital 
certificate was checked/marked ... then the relying party could assume 
non-repudiation on the part of the originating party. Again this is a 
scenario trying to represent the value of a digital certificate in place 
of the safety and security around the access and use of the private key.

So the story given to merchants in the merchant/consumer market place 
 was that the existed circumstances were that in any dispute the 
burden of proof is on the merchant  but the proposal was that if a 
merchant could produce any certificate (for the originator's public key) 
that had the non-repudiation flag marked/checked, then the burden of 
proof (in a dispute) whould shift from the merchant to the consumer.

So if that effort had been succesful ... then it would be in the 
interest of merchants to be able to produce a consumer digital 
certificate that included the non-repudiation flag (regardless of 
whether that certificate had been used in the original transaction or 
not  since by definition all burden of proof then is shifted to the 
consumer).

some of this is discussed in various postings regarding finread ... 
where the EU attempted to dictate some minimum hardware environment that 
 would provide some level of assurance around the access and use of the 
private key (which helps diffuse the confusion around whether the 
digital signature value proposition relies solely in the existance of a 
digital certificate  or whether there is some value in controlling 
the access and use of private keys  and it possibly isn't the case 
that digital signatures are generated by digital certificates):
http://www.garlic.com/~lynn/subpubkey.html#finread

other past postings on 3-factor authentication
http://www.garlic.com/~lynn/subpubkey.html#3factor
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: comments wanted on gbde

[Ivan Krstic]

Steven M. Bellovin wrote:
With 
the author's consent, I'm soliciting opinions from this group about it:

http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf
I just gave the paper a quick read and am hoping this is not meant for 
production use. The key problems to me appear to be that:

- the paper claims added security through the added complexity, when 
that's almost always untrue
- standard algorithms are used for things they weren't meant to be used for
- the numbers for the amount of work to break this seem suspect 
(although, again, I only gave them a quick read)

Did PHK even solicit proper reviews before implementation? This looks 
like another case of a programmer - in this case, a really smart 
programmer - who decides to roll his own cryptosystem with no input from 
the crypto community. Terrible Idea. He would have likely been better 
off using, say, straight AES256 for the whole disk, without any of his 
own bells and whistles.

Cheers,
Ivan.
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: SSL Cert prices ($10 to $1500, you choose!)

[SK]

Hopefully, once CACert gets it acts together, this will decrease to $0!

SK


On Fri, 04 Mar 2005 15:53:51 -0800, John Gilmore <[EMAIL PROTECTED]> wrote:
> For the privilege of being able to communicate securely using SSL and a
> popular web browser, you can pay anything from $10 to $1500.  Clif
> Cox researched cert prices from various vendors:
> 
>   http://neo.opn.org/~clif/SSL_CA_Notes.html
> 
> John

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

[Fwd: [Cfrg] Colliding RFC 3161 time-stamp tokens based on MD5-collisions]

[Alfonso De Gregorio]

I hope this might be of interest.
Alfonso
--- Begin Message ---
Hi All.
I would like to thank Arjen Lenstra, Xiaoyun Wang, and Benne de Weger
for announcing a method for the construction of pairs of colliding
X.509 certificates, and David McGrew for forwarding to the list.
I would like also to point out that it is possible, in a similar way,
to construct pairs of valid, but different, RFC 3161 time-stamp tokens
in which the signed data form a collision for the MD5 hash function.
This yields to the generation of the same signature by the
Time Stamping Authority when it uses MD5 as its hash function.
With this construction the attacker can easily craft MD5 collisions
in such a way that he or she constructs RFC 3161 time-stamp tokens
in which all fields, except the nonces, are equal (i.e., including
the TSA name and serial number). Hence, producing an evidence of the
apparent violation, by a given TSA, of an absolute requirement -
according to RFC 2119 - of the specifications. In fact, the RFC 3161
requires (see section 2.4.2) the uniqueness of the serial number that,
with the TSA name, must identify a unique time-stamp token.
The construction is straightforward.
1. First construct a template for the time-stamp token.
 All the fields must be completely filled in, with the exception
 of the nonce and the signature. The following requirements
 needs to be met:
i) the data structure should be compliant to the RFC 3161 standard
   and the ASN.1 DER encoding rules;
   ii) the genTime (the time at which the time-stamp token has been
   created) and the serial-number needs to be guessed;
  iii) the position where the nonce field ends should be an exact
   multiple of 64 octets;
  (ii) The value at which the genTime field will be set by the TSA
  can be guessed depending on the accuracy of the clock (i.e.,
  the time deviation around the UTC time contained in genTime)
  and the time required to send and consume the time-stamping
  request message (e.g., the half round-trip latency plus the
  processing time). The accuracy is a public information and
  is typically equal to one second, or lesser values.
  In several implementations, the serial number is also guessable,
  since its a monotonically increasing number or derived from the
  system time.
  (iii) The third condition can be dealt with by filling out the
  nonce field with random data up to an exact multiple of 64 octets.
  This is a first part of the nonce value. For future reference,
  the offset where the first part of the nonce ends is labeled
  Offset-1. A second bitstring will be appended to it (see the
  step number 4).
2. The MD5 algorithm get executed on the first portion of the
 "to be signed" part, truncated at the position Offset-1
 (i.e., where the first part of the nonce ends). The input
 to MD5 is an exact multiple of 512 bits. The padding normally
 used in MD5 needs to be suppressed. The output should to be
 taken as the IV used as input for the next step.
3. Perform the step number 3 described by Lenstra et al. in
 'Colliding X.509 Certificates' available at
 . Two different bitstring,
 b1 and b2, whose length is a multiple of 512 bits, get
 constructed, using the technique developed by Wang et al.,
 for which the MD5 compression function with the IV from the
 previous step produces a collision.
4. Append the bitstring b1 into the time-stamp token template
 after the Offset-1. This bitstring completes the nonce value.
 Now all the (to be) signed data are complete and a time-stamping
 transaction can start with the given TSA. In the time-stamp
 request the attacker will specify the nonce that contains the
 bitstring b1.
5. The TSA replies with the time-stamp response that contains
 (seemingly) the expected time-stamp token.
6. To obtain the second valid time-stamp token, replace b1 for b2
 in the nonce field. The signature remains valid.
The time-stamp tokens are syntactically well-formed and obviously
valid also by a cryptographic standpoint, since their digital signature
can be verified by relying parties.
The same method may be applied against other iterative hash functions,
if a technique is identified to produce collisions with prescribed IV
also with the target function.
Finally, it would be much more interesting if someone would be
able to construct pairs of colliding RFC 3161 time-stamp tokens
whose genTime field (and/or serial number field) can be arbitrary
chosen. This would allow the pre-dating and post-dating of
data and would have a severe negative impact on intellectual property
protection applications and notary services based on RFC 3161 digital
time-stamping - reaffirming the importance of a strong evidence of
temporal ordering of time-stamps.
Best regards,
Alfonso


___
Cfrg mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/cfrg
--- End Message ---

Re: MD5 collision in X509 certificates

[Victor Duchovni]

On Sat, Mar 05, 2005 at 09:23:11AM -0700, Anne & Lynn Wheeler wrote:

> Victor Duchovni wrote:
> >What is the significance of this? It seems I can get a certificate for
> >two public keys (chosen, not given) while only proving posession of the
> >first. Is there anything else? In what sense is the second public key
> >useful to the attacker?
> 
> the purpose of a certificate is analogous to the old letters of credit 
> in the sailing ship days  it supposedly establishes the bonifides of 
> the individual in an offline, non-connected world where the relying 
> party has no other recourse regarding trust/integrity of the individual 
> that they are dealing with.
> 
> [...]

I've read very similar posts a few times before, and agree with them all
wholeheartedly! My question is however about this specific exposure. This
collision is between two keys generated together by the attacker, not
someone else's given key and another generated by the attacker. Yes,
this allows one to obtain a certificate for a public key whose private
key did not sign the CSR, but what does this mean in practice? It appears
that neither public key can be used to impersonate anyone else...

-- 

 /"\ ASCII RIBBON  NOTICE: If received in error,
 \ / CAMPAIGN Victor Duchovni  please destroy and notify
  X AGAINST   IT Security, sender. Sender does not waive
 / \ HTML MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

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

Re: comments wanted on gbde

[Joseph Ashwood]

- Original Message - 
From: "Steven M. Bellovin" <[EMAIL PROTECTED]>
Subject: comments wanted on gbde

I'll just deal with it piece by piece.
Page 3 "decrypting and re-encrypting an entire disk would likely take more 
than a day with currently available hardware" is wrong. Assuming 256-bit 
AES, using a two-pass encryption system, on a 2.1 GHz pentium 4 (currently 
below low end) this would equal a disk of over 1000GB (numbers taken from 
Crypto++ benchmarks), personally I don't have a laptop with that kind of 
space. I have a rackmount server with that space, and my desktop is getting 
close, but no where near full. Even by page 3 I'm becoming doubtful about 
the abilities and there isn't any real information yet.

Page 3 again, system supports multiple access paths. Clearly this means that 
either the entire disk, or per block or per sector or whatever has an 
encrypted key, this is how they will meet the false criteria above, and the 
multiple access path. Of course this is a standard technique, and has been 
around for ages, nothing new here.

Page 4 "It has been said that there is only one really hard problem in 
cryptography: the problem of key management. GBDE does not try to address 
that." They're already admitting to heavy flaws, downplaying the abilities 
of the design, not a good sign.

Page 5 finally begins the actual information.
Page 5 "plaintext sector data should be encrypted with one-time-use 
(pseudo-)random keys" serves no purpose if a strong mode is used.  The only 
purpose this serves is to slow the system down as additional searches have 
to be made. This is claimed to provide protection from when AES is broken. 
It offers nothing except wasted cryptographic and disk overhead.

Page 5 "RSA2/512 as strong one way hash" just in case I was wrong and this 
does exist, I ran a quick google for it, and found the only references to it 
are in reference to this paper. I suppose they meant SHA-512, which further 
brings the question: Why are they using a hash function at all? Obviously 
this is where the decrypt/encrypt taking more than a day came from, SHA-512 
is slow, using 256-bit AES in a properly secure mode using a MAC would have 
been better cryptographically, better for storage, computationally easier, 
and would have substantially reduced the window of exposure (A break of 
AES-256 would have been required instead of a break of either AES-128 or 
SHA-512). Further the choice of MD5 as a "bit blender" is extremely 
questionable, and again it would have created a much smaller window of 
exposure to use an AES CBC-MAC with a known key and IV. Obviously this was 
not built by someone with anything more than a rudimentary knowledge of 
cryptography.

Still on page 5, (apparently unkeyed) MD5 is used as a MAC of the lock 
sector. Very, very poor security decision.

Using variable formatting. How many times do we have to kill this before it 
stays dead? Obviously more, probably many more. Variable formatting gains 
you nothing, consumes entropy, and consumes cpu time, it also often is the 
foundation for the break.

Page 6 covers the paranoia plausible deniability. Strangely although they 
seem to imply that the current GBDE does this they apparently have chosen 
not to even begin covering this, so most likely they either make no real 
attempt at it, it doesn't work, or both.

Page 6, section 7.4 covers using MD5 to make sure the performance is as bad 
as possible by maing it impossible to precompute where data will be.

The footnote on page 6 should read "In both cases the encoded sector address 
was placed in the middle to ensure the worst possible performance, 
cryptographically it makes no difference"

In the Known Weaknesses section they forget something important THERE IS NO 
MAC ON THE DATA. This means that there is no possibility of detecting an 
attack, not possibility of determining what has been tampered with. In short 
the real level of security fails miserably.


Section 16 likes to hint that David Wagner and Lucky Green peer reviewed 
this paper. Assuming this is true, my best guess is that the authors mistook 
a statement of "This should be secure" for a statement of "This is good" 
that is unless there are enormous holes in the paper.


GBDE is built on concepts that are nonsensically put together, the design 
itself is out of date by at least a decade, and makes a wide number of 
extremely amateur decisions.


The most important point to make is that this paper shows rather well that 
while developing something "secure" is difficult, something that is "good 
and secure" is substantially more difficult.

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

Re: [IP] One cryptographer's perspective on the SHA-1 result

[james hughes]

On Mar 4, 2005, at 5:23 PM, James A. Donald wrote:
The attacks on MD*/SHA* are weak and esoteric.
On this we respectfuly disagree.
You make it sound trivial. Wang has been working on these results for 
over 10 years. She received the largest applause at Crypto 2004 session 
from her peers I have ever seen.

It is not so fundamentally broken as to justify starting over.
on this I agree.
My recommendation for anyone that listens to (nobody) me is to abandon 
the MD series and SHA algorithms below SHA-256 for everything including 
certificates, pgp and even HMAC. But these are my inclinations. I would 
rather migrate to stronger crypto than have to continually justify why 
I continue to use algorithms that have known weaknesses.

$0.02
--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 QVYtFQAELN4YlZ9xB60CvXTqW8QT8rOABMbJrPXE
 4hz2qo1jnDwc3tmFFeyh6lG9sOrXL1783FYSh2s+v
What software do you use for this? Is it ECC or RSA?
Thanks
jim

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

Re: comments wanted on gbde

[Roland Dowdeswell]

I have started writing up a bit of an analysis of GBDE, which I
would like to have people comment on before I continue with it.
I.e. am I onto something here or not? I wrote this up very quickly
over a few sleepless nights while trying to get my normal work done
before I left on vacation, so please bear with me.  The explanations
are rather empirical.  I am planning to put some mathematics in
there eventually.  At least after I return from my vacation.

I think that I have demonstrated that there are weak master keys
which can be used to construct an attack in < 2^128 steps on
individual sectors.  I also discuss dictionary attacks and construct
another attack which is more difficult than brute forcing each
sector, but a little less time consuming than GBDE's author claims
it should be.

The URL is:

http://www.imrryr.org/~elric/cgd/gbde-analysis.pdf

Thanks,

--
Roland Dowdeswell  http://www.Imrryr.ORG/~elric/

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

Re: SSL Cert prices ($10 to $1500, you choose!)

[Anne & Lynn Wheeler]

SK wrote:
Hopefully, once CACert gets it acts together, this will decrease to $0!
SK
and with a little bit of intelligent compression, zero bytes!
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: two-factor authentication problems

[Matt Crawford]

On Mar 5, 2005, at 11:32, Ed Gerck wrote:
The worse part, however, is that the server side can always fake your
authentication using a third-party because the server side can
always calculate ahead and generate "your next number" for that
third-party to enter -- the same number that you would get from your
token. So, if someone breaks into your file using "your" number --
who is responsible? The server side can always deny foul play.
Huh?  The server can always say "response was good" when it wasn't 
good.  Unless someone reclaims the server from the corrupt operator and 
analyzes it, the results are the same.

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