[17037] in cryptography@c2.net mail archive
Re: two-factor authentication problems
daemon@ATHENA.MIT.EDU (Anne & Lynn Wheeler)
Sun Mar 13 14:16:00 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Mon, 07 Mar 2005 15:36:23 -0700
From: Anne & Lynn Wheeler <lynn@garlic.com>
To: gabriel@castelain.com.au
Cc: 'Matt Crawford' <crawdad@fnal.gov>, 'Ed Gerck' <egerck@nma.com>,
cryptography@metzdowd.com
In-Reply-To: <005201c522d1$47a6cc30$9030ecdc@ORGANIZAD3342A>
Gabriel Haythornthwaite wrote:
> You're quite correct Matt,
>
> Which is why IMHO you can only really get true "non-repudiation" through use
> of PKI. And more specifically:
> - where the key pair was generated by the end-user, and
> - where the server has stored a copy of the transaction - digitally signed
> by the end user - which it can reproduce in court.
>
> In this case, a corrupt operator could not have faked the transaction even
> if they had wanted to.
>
> RSA SecureID and OATH technology have some great virtues:
> - they cost nothing to integrate at the client end - there is no client
> "footprint" so there's nothing to go wrong
> - they are relatively easy to understand and use
> - they're unquestionably better than reliance on user IDs and passwords.
>
> What they won't do is:
> - provide non-repudiation
> - defend against man-in-the-middle attacks, or
> - provide a robust defence against phishing scams
>
> And for these reasons I suspect their days are numbered.
in general, non-repudiation is a legal term and is associated with a
legal signature ... which implies a person has read, understands,
agreed, approves, and/or authorizes what is being signed.
a digital signature is somewhat of a semantic misnomer since by itself,
it carries none of the characteristics commonly associated with a legal
signature.
a digital signature, by itself, implies that some entity has accessed
and used a specific private key. there is nothing in the standard, basic
PKI infrastructure that either
1) implies that anything associated with any form of 3-factor
authentication was necessary in the access and use of a private key (in
the generation of a digital signature)
2) that there was any demonstration that there was any reading,
understanding, agreement, approval, and/or authorization associated with
the access and/or use of a private key (in the generation of a digital
signature).
part of this i pointed out in a number of postings on dual-use digital
signature attack ... where the scenario is that digital signature is
being used to imply simple authentication aka possibly some flavor of a
challenge was transmitted, the receiving entity then used a private key
to digitally sign the challenge and return the digital signature (there
is a extremely vague implicit assumption that any component of 3factor
authentication was used in access and use of the private key ... with
the existance of a digital signature hopefully implying that some
component of 3factor authentication actually occured in the access and
use of the private key).
issues are
a) frequently challenge type protocols don't bother to present (the
possibly totally random) bits (being signed) to the entity (that is
assumed to be associated with the digital signature).
b) frequently infrastructures that attempt to equate legal signature and
digital signature ... will accept the existance of a digital signature
applied to some number of bits as representing that the associated
entity actually read, understood, approved, agrees, and/or authorizes
the semantic meaning associated with the bits that were signed ... w/o
requiring either 1) some demonstration/proof that 3factor authentication
was used in the access and use of the private key for the digital
signature and/or 2) that the meaning of what was digital signed had
actually been read, understood, approved, agreed and/or authorized
in the dual-use attack, bits that might have semantic meaning are
presented as random and/or meaningless as part of an authentication
challenge/response protoocol. The attacker then takes and represents
that the challenge bits that were signed ... were actually signed in the
sense of a legal signature.
as a totally extraneous observation ... the discussion up to this point
has been totally agnostic with regard to whether an infrastructure
attempting to show some relationship between a digital signature and a
legal signature involves PKI in anyway what so ever and/or is totally
certificateless with regard to establishing a relationship between an
entity and what might be assumed from the existance of a digital signature.
past posts regarding 3-factor authentication
http://www.garlic.com/~lynn/subpubkey.html#3factor
EU finread standard attempting to address some of the issues regarding
providing some level of assurance about 1) any characteristic of 3factor
authentication actually occuring when the private key was accessed and
used for a digital signature and 2) the entity might have actually read
and approves the transaction
http://www.garlic.com/~lynn/subpubkey.html#finread
past posts on dual-use vulnerability
http://www.garlic.com/~lynn/aadsm17.htm#55 Using crypto against
Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#12 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#13 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#17 should you trust CAs? (Re:
dual-use digital signature vulnerability)
http://www.garlic.com/~lynn/aadsm18.htm#32 EMV cards as identity cards
http://www.garlic.com/~lynn/aadsm18.htm#35 Credit card leaks continue at
a furious pace
http://www.garlic.com/~lynn/2004h.html#51 New Method for Authenticated
Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004h.html#58 New Method for Authenticated
Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#24 New Method for Authenticated
Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004m.html#4 REVIEW: "Biometrics for Network
Security", Paul Reid
http://www.garlic.com/~lynn/2005.html#14 Using smart cards for signing
and authorization in applets
http://www.garlic.com/~lynn/2005b.html#56 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#51 [Lit.] Buffer overruns
past posts on non-repudiation ... and possibly some characteristics that
might be required to demonstrate a person has read, understood,
approved, agrees, and/or authorized what was digitally signed:
http://www.garlic.com/~lynn/aepay7.htm#nonrep0 non-repudiation, was Re:
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep1 non-repudiation, was Re:
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep2 non-repudiation, was Re:
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re:
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep4 non-repudiation, was Re:
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re:
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re:
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure
Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aepay10.htm#72 Invisible Ink, E-signatures
slow to broadly catch on
http://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures
slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aepay11.htm#22 FBI Probing Theft of 8
Million Credit Card Numbers
http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
http://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside
http://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication
white paper
http://www.garlic.com/~lynn/aepay11.htm#66 Confusing Authentication and
Identiification?
http://www.garlic.com/~lynn/aadsm3.htm#cstech4 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth
about Digital Signatures
http://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth
about Digital Signatures
http://www.garlic.com/~lynn/aadsm5.htm#ocrp Online Certificate
Revocation Protocol
http://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI
http://www.garlic.com/~lynn/aadsm6.htm#nonreput Sender and receiver
non-repudiation
http://www.garlic.com/~lynn/aadsm6.htm#nonreput2 Sender and receiver
non-repudiation
http://www.garlic.com/~lynn/aadsm6.htm#terror7 [FYI] Did Encryption
Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#terror10 [FYI] Did Encryption
Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm7.htm#pcards4 FW: The end of P-Cards?
http://www.garlic.com/~lynn/aadsm7.htm#cryptofree Erst-Freedom: Sic
Semper Political Cryptography
http://www.garlic.com/~lynn/aadsm7.htm#rubberhose Rubber hose attack
http://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki9 Software for PKI
http://www.garlic.com/~lynn/aadsm9.htm#softpki23 Software for PKI
http://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's
Nathaniel Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/aadsm9.htm#pkcs12b A PKI Question: PKCS11->
PKCS12
http://www.garlic.com/~lynn/aadsm10.htm#cfppki13 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#cfppki15 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#cfppki18 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#paiin PAIIN security glossary &
taxonomy
http://www.garlic.com/~lynn/aadsm10.htm#tamper Limitations of
limitations on RE/tampering (was: Re: biometrics)
http://www.garlic.com/~lynn/aadsm10.htm#bio3 biometrics (addenda)
http://www.garlic.com/~lynn/aadsm10.htm#bio7 biometrics
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet,
here's your private key
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
http://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm12.htm#5 NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm12.htm#12 TOC for world bank e-security
paper
http://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and
their users [was Re: Cryptogram: Palladium Only for DRM]
http://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates -
Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#37 Legal entities who sign
http://www.garlic.com/~lynn/aadsm12.htm#38 Legal entities who sign
http://www.garlic.com/~lynn/aadsm12.htm#54 TTPs & AADS Was: First Data
Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm12.htm#59 e-Government uses
"Authority-stamp-signatures"
http://www.garlic.com/~lynn/aadsm12.htm#64 Invisible Ink, E-signatures
slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
http://www.garlic.com/~lynn/aadsm14.htm#20 Payments as an answer to spam
(addenda)
http://www.garlic.com/~lynn/aadsm14.htm#23 Maybe It's Snake Oil All the
Way Down
http://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
http://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI "not working"
http://www.garlic.com/~lynn/aadsm14.htm#48 basic question: semantics of
"map", "tie", etc in PKI
http://www.garlic.com/~lynn/aadsm15.htm#32 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#34 VS: On-line signature
standards (slight addenda)
http://www.garlic.com/~lynn/aadsm15.htm#35 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#37 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#40 FAQ: e-Signatures and Payments
http://www.garlic.com/~lynn/aadsm16.htm#9 example: secure computing
kernel needed
http://www.garlic.com/~lynn/aadsm16.htm#11 Difference between
TCPA-Hardware and a smart card (was: example: secure computing kernel
needed)
http://www.garlic.com/~lynn/aadsm16.htm#13 The PAIN mnemonic
http://www.garlic.com/~lynn/aadsm16.htm#14 Non-repudiation (was RE: The
PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm16.htm#17 Non-repudiation (was RE: The
PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm16.htm#18 Non-repudiation (was RE: The
PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm16.htm#23 Non-repudiation (was RE: The
PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm17.htm#3 Non-repudiation (was RE: The
PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm17.htm#5 Non-repudiation (was RE: The
PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm17.htm#28 Definitions of "Security"?
http://www.garlic.com/~lynn/aadsm17.htm#53 Using crypto against
Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm17.htm#55 Using crypto against
Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#55 MD5 collision in X509
certificates
http://www.garlic.com/~lynn/99.html#224 X9.59/AADS announcement at BAI
this week
http://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
http://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#43 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#46 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#50 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#51 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#52 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001d.html#41 solicit advice on purchase of
digital certificate
http://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit cards!
http://www.garlic.com/~lynn/2001g.html#1 distributed authentication
http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
http://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#57 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#45 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001j.html#49 Are client certificates really
secure?
http://www.garlic.com/~lynn/2001j.html#52 Are client certificates really
secure?
http://www.garlic.com/~lynn/2001k.html#1 Are client certificates really
secure?
http://www.garlic.com/~lynn/2001k.html#34 A thought on passwords
http://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic
rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#43 FA: Early IBM Software and
Reference Manuals
http://www.garlic.com/~lynn/2001n.html#71 Q: Buffer overflow
http://www.garlic.com/~lynn/2002c.html#7 Opinion on smartcard security
requested
http://www.garlic.com/~lynn/2002c.html#15 Opinion on smartcard security
requested
http://www.garlic.com/~lynn/2002c.html#42 Beginning of the end for SNA?
http://www.garlic.com/~lynn/2002d.html#16 Mainframers: Take back the
light (spotlight, that is)
http://www.garlic.com/~lynn/2002d.html#41 Why?
http://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security
requested
http://www.garlic.com/~lynn/2002e.html#29 Crazy idea: has it been done?
http://www.garlic.com/~lynn/2002e.html#36 Crypting with Fingerprints ?
http://www.garlic.com/~lynn/2002e.html#58 O'Reilly C Book
http://www.garlic.com/~lynn/2002f.html#10 Least folklorish period in
computing (was Re: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002f.html#23 Computers in Science Fiction
http://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
http://www.garlic.com/~lynn/2002f.html#45 Biometric Encryption: the
solution for network intruders?
http://www.garlic.com/~lynn/2002g.html#37 Security Issues of using
Internet Banking
http://www.garlic.com/~lynn/2002g.html#69 Digital signature
http://www.garlic.com/~lynn/2002h.html#41 Biometric authentication for
intranet websites?
http://www.garlic.com/~lynn/2002h.html#68 Are you really who you say you
are?
http://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman schema
belong to Public Key schema family?
http://www.garlic.com/~lynn/2002i.html#77 Does Diffie-Hellman schema
belong to Public Key schema family?
http://www.garlic.com/~lynn/2002j.html#24 Definition of Non-Repudiation ?
http://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
http://www.garlic.com/~lynn/2002k.html#42 MVS 3.8J and NJE via CTC
http://www.garlic.com/~lynn/2002l.html#5 What good is RSA when using
passwords ?
http://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and hashing
http://www.garlic.com/~lynn/2002m.html#17 A new e-commerce security proposal
http://www.garlic.com/~lynn/2002m.html#20 A new e-commerce security proposal
http://www.garlic.com/~lynn/2002m.html#36 (OT) acceptance of technology,
was: Convenient and secure
http://www.garlic.com/~lynn/2002m.html#38 Convenient and secure
eCommerce using POWF
http://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for
national ID card?
http://www.garlic.com/~lynn/2002n.html#16 Help! Good protocol for
national ID card?
http://www.garlic.com/~lynn/2002n.html#19 Help! Good protocol for
national ID card?
http://www.garlic.com/~lynn/2002n.html#25 Help! Good protocol for
national ID card?
http://www.garlic.com/~lynn/2002n.html#26 Help! Good protocol for
national ID card?
http://www.garlic.com/~lynn/2002o.html#67 smartcard+fingerprint
http://www.garlic.com/~lynn/2002p.html#23 Cost of computing in 1958?
http://www.garlic.com/~lynn/2003e.html#47 Public key and the authority
problem
http://www.garlic.com/~lynn/2003f.html#35 Public Encryption Key
http://www.garlic.com/~lynn/2003f.html#37 unix
http://www.garlic.com/~lynn/2003h.html#6 IBM says AMD dead in 5yrs ...
-- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003h.html#18 Authentication protocol
http://www.garlic.com/~lynn/2003h.html#25 HELP, Vulnerability in Debit
PIN Encryption security, possibly
http://www.garlic.com/~lynn/2003h.html#29 application of unique signature
http://www.garlic.com/~lynn/2003h.html#38 entity authentication with
non-repudiation
http://www.garlic.com/~lynn/2003h.html#42 IBM says AMD dead in 5yrs ...
-- Microsoft Monopoly vs
http://www.garlic.com/~lynn/2003.html#19 Message
(authentication/integrity); was: Re: CRC-32 collision
http://www.garlic.com/~lynn/2003.html#29 Message
(authentication/integrity); was: Re: CRC-32 collision
http://www.garlic.com/~lynn/2003i.html#1 Two-factor authentication with SSH?
http://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation
http://www.garlic.com/~lynn/2003i.html#36 electronic-ID and key-generation
http://www.garlic.com/~lynn/2003j.html#47 The Tao Of Backup: End of postings
http://www.garlic.com/~lynn/2003k.html#6 Security models
http://www.garlic.com/~lynn/2003l.html#65 Strength of RSA with known
plain-text
http://www.garlic.com/~lynn/2003m.html#38 Questioning risks of using the
same key for authentication and encryption
http://www.garlic.com/~lynn/2003m.html#51 public key vs passwd
authentication?
http://www.garlic.com/~lynn/2003o.html#22 securID weakness
http://www.garlic.com/~lynn/2003o.html#29 Biometric cards will not stop
identity fraud
http://www.garlic.com/~lynn/2003o.html#44 Biometrics
http://www.garlic.com/~lynn/2003p.html#4 Does OTP need authentication?
http://www.garlic.com/~lynn/2003p.html#11 Order of Encryption and
Authentication
http://www.garlic.com/~lynn/2003p.html#17 Does OTP need authentication?
http://www.garlic.com/~lynn/2004e.html#20 Soft signatures
http://www.garlic.com/~lynn/2004h.html#13 Two-factor Authentication Options?
http://www.garlic.com/~lynn/2004h.html#30 ECC Encryption
http://www.garlic.com/~lynn/2004.html#29 passwords
http://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated
Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#24 New Method for Authenticated
Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#6 New Method for Authenticated
Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004m.html#4 REVIEW: "Biometrics for Network
Security", Paul Reid
http://www.garlic.com/~lynn/2005d.html#32 Is a cryptographic monoculture
hurting us all?
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
