Cryptography-Digest Digest #713, Volume #10 Thu, 9 Dec 99 22:13:01 EST
Contents:
Re: SRP - a secure alternative for authentication >> Nice reading ... ("anonymous")
Re: High Speed (1GBit/s) 3DES Processor (Christof Paar)
Re: NSA future role? (CLSV)
Re: If you're in Australia, the government has the ability to modify ("Douglas A.
Gwyn")
Re: Synchronised random number generation for one-time pads (Tim Tyler)
Re: If you're in Australia, the government has the ability to modify ("Douglas A.
Gwyn")
----------------------------------------------------------------------------
From: "anonymous" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: SRP - a secure alternative for authentication >> Nice reading ...
Date: Thu, 9 Dec 1999 19:37:31 -0700
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Nice reading ...
> --
> Thanks, Richard
As the author of this I would please ask people to not post my work
without at least asking. Additionaly if you do feel the need to post
stuff please include the URL so people can find updated copies/etc. I
wrote this while sick with the flu and it's quite messed up (read
wrong). I will post an updated version to
http://www.securityportal.com/closet/ sometime this week.
- -Kurt Seifried, MCSE
https://www.seifried.org/
http://securityportal.com/lasg/
http://securityportal.com/closet/
My public keys are available at:
https://www.seifried.org/keys/
http://www.pgpi.org/ - recommended for Windows
http://www.gnupg.org/ - recommended for UNIX
http://www.pgp.com/ - recommended for commercial use
and start using PGP/GnuPG to sign and encrypt your email.
> ===============================================
> SRP - a secure alternative for authentication by Kurt Seifried
>
> December 8, 1999 - If users want to log into
> servers we usually make them authenticate first. This has consisted
> mostly of a username and password pair passed to the server, in
> cleartext, which is fine if you have a 100% physically secure
> network using switches and no interlopers between you and the
> server. Of course there are very few networks like this, so people
> have invented schemes to encrypt and otherwise protect the
> authentication data when it is sent across the network. This has
> been aided by the growth of cryptography, where you have the same
> basic issues (prove to me who you are, in a secure manner, across
> an unsecured channel).
>
> EKE verses AKE
>
> No this is not a wrestling match between a pair of Swedish brothers
> (sorry, I couldn't resist). One of the most fundamental problems to
> encryption is the key exchange. Finding an algorithm or method to
> securely mangle the data so that only the other party can make
> sense of it is easy (there were 50+ algorithms in the initial AES
> candidate selection, now narrowed down to 5). Securely exchanging
> keys with a party that you probably have not communicated with
> before, especially across an insecure channel is difficult at best.
> There are two primary methods currently in use, EKE (Encrypted Key
> Exchange protocol) and AKE (Asymmetrical Key Exchange protocol),
> and there are several others (such as IKE, Internet Key Exchange
> protocol). EKE uses a variety of methods such as RSA, DSA or
> Diffie-Helman, and is susceptible to a number of attacks, one of
> the more important ones being a man in the middle attack. To combat
> this most authentication systems use some form of pre shared
> secret, or use digital signature technology (where trusted third
> parties verify the identity of one or both parties, and is used as
> the pre-shared secret).
>
> EKE based transactions fill a wide variety of needs, and are the de
> facto standard for SSL based transactions (which includes the vast
> majority of online commerce). SSL typically employs certificates,
> which consists of a public and private portion, the public portion
> not only contains a key, but information about the owner (such as
> name, expiry date of the certificate, and so on). This public
> certificate is signed by a trusted third party, such as Verisign or
> Thawte, who have typically convinced large www browser companies
> (like Netscape and Microsoft) to include their certificates with
> the browser software (so by default most users blindly accept it).
> This is the "pre-shared" secret typically used, and it works quite
> well (although it isn't perfect). This systems become much less
> practical however when you want to prove the identity of the client
> (or large numbers of entities). The costs involved of getting a
> third party to verify your identity and issue a certificate are
> quite high (Verisign used to sell them at $20 US but stopped). The
> costs involved in making that certificate portable are even higher
> (a hundred dollars US for a smart card and smart card reader is
> well within the average price range). In addition to this the
> amount of information provided by a certificate is overkill, the
> majority of authentication transactions only require a username and
> password. This is the area of authentication that SRP works to
> solve.
>
> It can be argued that SRP uses a form of preshared secret, the
> username and password, however there are some differences. SRP
> makes use of AKE, essentially each party exchanges some generated
> information (I'm not going to explain the math here, please read
> Tom Wu's whitepaper on it, listed at the bottom) that is used to
> prove the veracity of the data sent (but cannot actually be used to
> figure out say the username and password). As far as I can tell SRP
> is the only protocol that uses AKE currently, so it's also useful
> as a "reference" implementation, that is if you want to learn about
> AKE and see how it's done, SRP is a good place to start (especially
> being that it is OpenSource).
>
> Other SRP benefits
>
> SRP provides several benefits over traditional methods, the biggest
> being that no actually encryption of the data takes place, meaning
> SRP can be exported legally from the US. SRP also makes no use of
> the patented RSA algorithm (typically used in key exchanges), so
> you can legally use it in the US (without having to pay RSA). SRP
> does not use preshared secrets (in the typical sense of preshared
> secrets), so there is nothing to steal (i.e. no certificate, server
> key, etc.) meaning to impersonate someone you have to resort to
> stealing their username and password in some manner (essentially
> you need to steal the authentication data in a time honored fashion
> such as bashing the persons head in and kidnapping them, you cannot
> generate the authentication data even if you manage to impersonate
> the server). SRP is also quite simple compared to many encryption
> algorithms I have seen, which should make testing and proving it is
> valid a bit simpler (peer review is always a good thing).
>
> Kurt: What prompted you to create SRP?
>
> Tom: In the process of designing the authentication infrastructure
> for a Java-based Webtop that was being developed at Stanford, I
> encountered the same problem that has plagued countless software
> developers and engineers: I had to design and implement a simple,
> yet secure password system to authenticate users and protect both
> their sessions and their data. After doing a bit of research, I
> concluded that there had to exist a method that was resistant to
> on-the-wire attacks while being friendly to Open Source terms.
> Thus, SRP was invented.
>
> Kurt: Do you feel that for authentication that AKE based protocols
> are better then EKE based protocols?
>
> Tom: AKE protocols like SRP have the advantage that the information
> stored on the server side cannot be stolen and used to impersonate
> the clients. "Verifier-based" protocols keep the data used for
> verification one step removed from the password itself, and this
> one step is computationally difficult to reverse. Although
> EKE-style protocols can be extended to achieve verifier-based
> functionality, it involves a significant performance disadvantage
> relative to SRP.
>
> Still the difference between the various strong password methods is
> minor compared to the massive gulf that separates any of these
> methods from weak
> challenge-response or any of the "classical" password
> authentication schemes.
>
> Kurt: What is the patent (if any) on SRP?
>
> Tom: Although Stanford is in the process of seeking patent
> protection for the SRP technology, any issued patents will not
> affect the Open Source-friendly terms for SRP. It is my intention
> to keep SRP available for Open Source projects everywhere, since I
> believe that the Open Source community must continue to have access
> to fundamental cryptographic technologies if it is to compete
> successfully with proprietary products from closed-source vendors.
>
> Kurt: I notice there are draft RFC's with it. Do you think SRP will
> achieve status as a widely accepted protocol?
>
> Tom: I believe it is up to the Internet crypto community as a whole
> to recognize the considerable advantages SRP offers and to
> contribute to the SRP project. Because of its flexibility (it
> decouples authentication from encryption so it can be incorporated
> into products exported from the US), openness, and security, SRP
> already has made its way into countless security-related products,
> both commercial and non-commercial, and its installed base is
> growing rapidly. Programmers don't have to design their own
> ad-hoc, weak password systems when they want to add authentication
> to an existing product anymore, now they just use SRP and call it a
> day.
>
> "Tom Wu attends Stanford University where he created the SRP
> protocol, and now works for Arcot Systems Inc.
> (http://www.arcot.com/)"
>
> Summary
> If you need to authenticate with a username and password SRP is
> definitely a good protocol to do it securely. SRP has several
> advantages over programs like OpenSSH, it is somewhat easier to
> implement in software (it doesn't require things like OpenSSL for
> example), and since it is not cryptographic in nature export issues
> are avoided. SRP does not make use of RSA or other patented ideas
> in any way, meaning you do not need to worry about compiling it
> against RSAREF or anything strange like that. As stated in the
> interview it appears that Stanford University will allow SRP to
> remain "free" and unencumbered by patent issues, which is a
> definite issue to consider when using a new (patented) protocol.
> SRP also supports encryption, but this portion cannot be exported
> out of the USA or Canada, making it of somewhat limited usefulness.
> If you need to secure logins, but are not as worried about the
> actual data being exchanged (for example email which tends to fly
> around unencrypted to start with), then SRP is an excellent
> protocol to use.
>
> Kurt Seifried is a security analyst and the author of the "Linux
> Administrators Security Guide", a source of natural fiber and Linux
> security, part of a complete breakfast.
>
>
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>
iQA/AwUBOFBnaYb9cm7tpZo3EQIoCQCgpMu2SZMYNFdPjnc8HFZEd98PbXoAnA1b
gWBjtRCDWCm2Ee4hkG8UlXfj
=Oo4L
=====END PGP SIGNATURE=====
------------------------------
From: Christof Paar <[EMAIL PROTECTED]>
Crossposted-To: comp.dcom.vpn,comp.security.firewalls
Subject: Re: High Speed (1GBit/s) 3DES Processor
Date: Thu, 9 Dec 1999 21:25:06 -0500
Just to give a data point for a non-FPGA, i.e., classic ASIC,
implementation:
Folks from Sandia Labs presented a 16-stage pipeline DES design in current
ASIC technology which encrypts at around 10 Gbit/sec at CHES '99. The
exact reference is at:
http://ece.wpi.edu/Research/crypt/ches/ches99/index.html
3DES should be 1/3 of that speeed.
Cheers, Christof
! WORKSHOP ON CRYPTOGRAPHIC HARDWARE AND EMBEDDED SYSTEMS (CHES 2000) !
! WPI, August 17 & 18, 2000 !
! http://www.ece.wpi.edu/Research/crypt/ches !
***********************************************************************
Christof Paar, Assistant Professor
Cryptography and Information Security (CRIS) Group
ECE Dept., WPI, 100 Institute Rd., Worcester, MA 01609, USA
fon: (508) 831 5061 email: [EMAIL PROTECTED]
fax: (508) 831 5491 www: http://ee.wpi.edu/People/faculty/cxp.html
***********************************************************************
On Thu, 9 Dec 1999, Helger Lipmaa wrote:
> Paul Koning wrote:
>
> > Same here, but I expect he was referring to the work of Hans Eberle,
> > still quoted in the second edition references (from Crypto '92). Or you
> > can read the DEC SRC research report, number 90, "A High-speed DES
> > implementation for network applications", H. Eberle, Sept 23, 1992.
> >
> > > Apply Moore's law (and divide by
> > > three to get 3DES;).
> >
> > Don't divide by three, just triple the transistor count. Trivial
> > these days, as David pointed out.
>
> Well, you can do everything.
>
> > I guess this discussion implies that crypto protocols should start
> > using interleaved CBC rather than classic uninterleaved CBC. That
> > would fix the pipeline bottleneck we currently have.
>
> The url I pointed to (http://home.cyber.ee/helger/fastidea) and the numbers
> I refered to (>300 Mbit/s on a 700 MHz P3) correspond to a parallel
> implementation of IDEA. Haven't looked closely at the hardware implementations
> of 3DES, but the fastest hardware for IDEA also works in a parallel mode
> (achieving 200 Mbit/s - less than the software implementation). So... Yes, you
> are true (and it's a point I've been personally pressing for more than a year).
> Parallel implementations can be used in counter mode and CBC decryption,
> however - I personally don't feel that easy about interleaved CBC.
>
> Helger Lipmaa
> http://home.cyber.ee/helger
>
>
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: NSA future role?
Date: Fri, 10 Dec 1999 02:50:11 +0000
> CLSV <[EMAIL PROTECTED]> wrote:
> : Long key crypto certainly has its uses. But I also believe that
> : it is *much* harder to write an algorithm that uses a long key
> : in a useful way. It doesn't make much sense to design an algorithm
> : that uses 16384-bits keys but can be broken using *only* 1024-bits.
Tim Tyler responded:
> I don't really see much difficulty there. Many encryption systems
> use large numbers of s-boxes. These can often be configured randomly
> (given a bunch of constraints designed to eliminate weak keys), and the
> resulting algorithm will still be quite strong.
Using large (number of) S-boxes is a nice idea. OTOH providing good
key-scheduling will be harder than it is for small key sizes I think.
[...]
> You won't find an algorithm whose strength depends on the size of its
> key-space, but provided your expectations are more modest, large keys
> /should/ fairly easily translate into real security advantages.
That is exactly what I meant: there will certainly be security advances
but it is harder to be as efficient (security wise) with large keys
than it is with small keys. Maybe I shouldn't have said *much* harder.
> :> This was to help foster the flase impression that the NSA wants
> :> people to belive. Yes he and the NSA will do a good job on selling the
> :> AES stuff as secure. But do you really think the NSA would allow a
> :> secure crypto system to become a US standard that they could
> :> not easily brake.
> : I think you look up too much to the NSA. If the NSA can brake
> : an algorithm than there are probably two or three other agencies
> : that can brake it. The NSA knows this as well and I think they
> : rather have a secure algorithm than one that gives the Russians,
> : Chinese, Israeli, French (...) easy access to commercial secrets.
> Hmm. NSA is responsible for national /security/, not commercial profits.
> Profits are often secondary to security - without security, profits can
> be stolen, or the country can be invaded.
Well, I don't think a security agency cares much about the commercial
secrets
of a fast-food chain. But they do care about important trade secrets
of companies that are vital for the economy of the country they are
serving.
If we take the US as an example I was more thinking about Lockheed,
Intel,
Microsoft (NSA_KEY), Exxon, AT&T et cetera.
> The NSA has a /long/ history of restricting public access to cryptography:
> Consider for example its funding of a (1980) study designed to presuade
> congress to give it power over publications in the field of cryptography.
I don't condone it, but remember that it was the height
of the Cold War era. Stranger things happened then.
> Then there's the export controls. Any US company who wants to use a
> single product at home and in the world market needs to cripple its
> encryption. Then there's the key-escrow chips. And so on.
So, political change takes time. The debate is still open.
What will happen when the AES winner is chosen? Would it still
be forbidden to export the global-wide used encryption standard?
> Those who have urged us to look twoards the NSA's involvement with DES
> should be reminded that the NSA are supposed to have characterised DES
> off the record as "one of their biggest mistakes".
> Apparently the situation was a result of confusion between the NSA and the
> NBS. The NSA understood that DES would be hardware-only. Had they known
> what would be done with it it seems unlikely they would have agreed to it.
> I expect they will have learned from this mistake.
Maybe, but given the flourishing field of academic and commercial
cryptography I don't think they have the same options as they
had in the 1980's. I don't think they even could offer all the
security knowledge that is needed in business today. The demand
for new kinds of protocols and applications is just exploding.
So they either have a choice of retreating to their core business,
just national security, or providing additional services for large
customers at risk of spreading specific knowledge.
Regards,
Coen Visser
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: If you're in Australia, the government has the ability to modify
Date: Fri, 10 Dec 1999 02:53:40 GMT
> Douglas A. Gwyn <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Apparently in the UK and Australia the citizens have surrendered;
> > other evidence for that is that they let the agents of the
> > government disarm them (with a consequent, predictable leap
> > in the violent crime rate, especially home invasions). Sheep.
"H.J. Gould" wrote:
> I would love to see you substantiate the claim that in those
> countries where the possesion of firearms is legal the violent
> crime rate is lower. As far as I know the rate of violent crimes
> in the US is at least as high as any other country in the world.
First of all, that is *not* what I said! You can confirm
what I did say from those governments' own crime statistics.
Second, violent crime rate is largely a matter of culture
and varies widely among countries with similar firearms policies.
For example, firearms are common "on the streets" of Israel,
which has a violent crime rate much lower than that of the US,
where there are *fewer* firearms "on the streets". Switzerland
(at least until recently; I don't have current information)
had mandatory military readiness requirements for its citizens,
which included keeping so-called "assault weapons" in the homes,
yet they had an exceedingly low violent crime rate. Within just
the US, the best available academic study of the connection
between ease of licensing for firearms carry and violent crime
state-by-state showed that there was a significant negative
correlation; i.e. the more likely a victim is to be able to defend
himself, the less inclined the career criminal is to assault him.
That even makes sense, when you think about it.
Over the past 5 years, the US violent crime rate has dropped
significantly, if one can trust the Justice Department's
statistics (that's a big "if"). It has not been determined
whether that is best attributed to increased police crackdown
or to the rapid spread of "shall issue" concealed carry laws
among the states, both of which have occurred during that time.
(It clearly is *not* that firearms are appreciably harder for
criminals to acquire.) We do have statistics showing that
concealed-carry licensees have been far less likely to commit
violent crimes than the average citizen.
Sorry this drifted off-charter, but there is a lot of
misinformation being propagated about this issue. If you
want to pursue it, presumably the discussion should move to
talk.politics.guns.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Synchronised random number generation for one-time pads
Reply-To: [EMAIL PROTECTED]
Date: Fri, 10 Dec 1999 02:19:25 GMT
[EMAIL PROTECTED] wrote:
: [EMAIL PROTECTED] wrote:
:> Authenticity is a problem for OTPs.
: It's a solved problem. In fact the only theoretically
: proven authentication methods are, like provable
: privacy, based on a one-time random key stream.
: For perfect secrecy, the condition required is that
: for any message m, the ciphertext of m is independent
: of m. For authentication we want the stronger
: property that for any pair of messages m and m', the
: signature of m is independent of the triple
: (m, m', signature(m')).
AFAICS, whatever type of hashing mechanism you use, the authentication is
never perfect - since the attacker can simply guess a value for the
signature. When it's wrong, the recipient realises what has happened,
but when he guesses right, he is not detected. The chance of detection
can be reduced to low levels by increasing the size of the signature,
of course.
This may be the best authentication conceivable - but it does not have the
same "100%" feel that an OTP with a genuinely random pad would provide
against eavsdropping.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Remember, to a computer 1 + 1 = 10.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: If you're in Australia, the government has the ability to modify
Date: Fri, 10 Dec 1999 03:01:26 GMT
"SCOTT19U.ZIP_GUY" wrote:
> ... I hope the gun manufactors sue the police departments for the
> imporper use of fire arms since the feds are using our tax money
> to go after gun manufactures instead of criminals.
It wouldn't make sense to sue police departments over federal
activities. However, the Second Amendment Foundation has just
sued the mayors of large cities for conspiracy to violate civil
rights, in connection with those "city sues for expenses due to
gun abuse" cases that anti-gunowner organizations such as the
Violence Policy Center have been promoting around the US. (Of
course there is a fundamental flaw in their reasoning; see
Henry Hazlitt's "Economics in One Lesson" if you don't
immediately see the flaw.) Since it is a Constitutional issue,
it should work its way through the Federal court system soon.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
