preliminary comments on the finalists
It's going to be hard to pick one of the five finalists. But if the criteria remain (substantially) the same, I think the field may be narrowed significantly. I'm making one very crucial assumption here, of course -- that to the extent it is knowable, all five finalists (Rijndael, MARS, RC6, Serpent, and Twofish) will be equally secure. In that case, performance and confidence become major criteria. NIST marked down MARS and RC6 for their bias towards 32-bit platforms with particular architectural characteristics. RC6 is denigrated for a (relatively) low security margin; MARS is criticized for complexity. Serpent, though quite strong, is slow. Twofish is flexible, but perhaps too complex. Nothing negative was said about Rijndael in the summary -- it seems to be very secure, have a fast key setup time, and excellent performance on all platforms. When I look at those judgments (all taken from 2.7.3 of the NIST report), I suspect that MARS, RC6, and Serpent are going to be dropped for performance reasons. Twofish and Rijndael are both excellent performers across the board. The latter is simpler; the former seems to have a higher security margin (if I'm not reading too much into the difference between a "large security margin" and a "good security margin"). The answer may depend on the weighting of those two criteria.
IP: Clinton comes after the Internet by Joseph Farah
--- begin forwarded text Date: Mon, 09 Aug 1999 10:45:29 -0600 To: [EMAIL PROTECTED] From: Robert Huddleston [EMAIL PROTECTED] Subject: IP: Clinton comes after the Internet by Joseph Farah Sender: [EMAIL PROTECTED] Reply-To: Robert Huddleston [EMAIL PROTECTED] http://www.worldnetdaily.com/bluesky_btl/19990809_xcbtl_clinton_co.shtml WorldNetDaily MONDAY AUGUST 09 1999 between the lines Joseph Farah -- WND Exclusive Commentary -- Clinton comes after the Internet by Joseph Farah -- Well, it was a long time coming, but Bill Clinton has finally made his move on the Internet. Late last week, when reporters and members of Congress were going home for the weekend, he issued one of his now-famous executive orders -- this one on "Internet conduct." Like almost all such orders, it will sound quite innocuous on a quick first read. But these guys in the Clinton administration are clever. This action sets up a working group of top U.S. officials to study the whole concept of policing the Internet. No, Clinton doesn't use that word, but that's clearly the intent of this order -- the establishment of a national Internet police force. But if you catch that much -- and few will -- then the wording of this order is designed to make you relax because the working group is simply going to write a report! We all know government reports don't kill people, right? Nobody gets hurt by a government report unless they drop it on you. However, let's take a look at what's being studied here: No. 1 -- How the federal government can insinuate itself into this revolutionary new medium. And, No. 2 -- How new technology tools, capabilities or legal authorities may be required for effective investigation and prosecution. Let me repeat that last purpose behind this working group and this executive order in the actual language used by Clinton: "The extent to which new technology tools, capabilities, or legal authorities may be required for effective investigation and prosecution of unlawful conduct that involves the use of the Internet." Get it? "New technology" equals spying tools. "Capabilities" means surveillance capabilities. And "legal authorities" means Internet police. You've got to understand the bureaucratic jargon here. Think of me as your Clintonese translator. Remember, this is a man who questions what the word "is" means. You've got to leave this to the professionals -- and that means me. Now here's the other scary part of this executive order. Normally with these task forces, the president allows a year or more for study and reports. Not this time. Guess what his deadline is? "The Working Group shall complete its work to the greatest extent possible and present its report and recommendations to the President and Vice President within 120 days of the date of this order," the executive order states. What! That means the report must be prepared before the end of the year. I would suggest to you that this means the report is already drafted. I would suggest further evidence for that conclusion is that Clinton is also requiring the committee to circulate the report to federal agencies well before it comes to the White House. Why would he do that? Because the White House has already seen it. The White House has written it. Who's going to be a part of this working group? The chairman is Janet Reno, and the members are most of the important Cabinet officers. Do you really think those guys and gals could draft a report on policing the Internet in less than 120 days? Uh-uh. Something's up here, folks. Something smells really foul. Now what do you suppose is in that future report? Hillary once told us the Internet needed gatekeepers and controls. "We are all going to have to rethink how we deal with this, because there are all these competing values," Hillary said last year. She also deplored the fact that the Internet lacks "any kind of editing function or gatekeeping function." I think Clinton's about to make his move on our last best hope for freedom -- the Internet. Methinks the Internet is about to get an official editor or a government gatekeeper. ** To subscribe or unsubscribe, email: [EMAIL PROTECTED] with the message: (un)subscribe ignition-point email@address ** www.telepath.com/believer ** --- end forwarded text - Robert 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'
DCSB: Andrew Odlyzko; So, Where's All the Digital Cash?
--- begin forwarded text Date: Tue, 10 Aug 1999 09:19:25 -0400 To: [EMAIL PROTECTED], [EMAIL PROTECTED] From: Robert Hettinga [EMAIL PROTECTED] Subject: DCSB: Andrew Odlyzko; So, Where's All the Digital Cash? Cc: Eben Moglen [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Reply-To: Robert Hettinga [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- The Digital Commerce Society of Boston Presents Dr. Andrew Odlyzko Head of the Mathematics and Cryptography Research ATT Laboratories Why digital cash has not taken off (yet) Tuesday, September 7th, 1999 12 - 2 PM The Downtown Harvard Club of Boston One Federal Street, Boston, MA The arrival of digital cash has been predicted for a long time, but progress has been disappointing. To fully understand what has happened, and what the future will bring, it appears to be necessary to consider the important economic and psychological factors that have hampered acceptance of digital money. Content producers can usually get more revenues through various bundling strategies (subscriptions, site licensing, etc.) than through sales a la carte. Further, consumers have a strong preference for flat-rate pricing schemes. These factors suggest which methods might be most productive in speeding up penetration of electronic money. Andrew Odlyzko is Head of the Mathematics and Cryptography Research Department at ATT Labs, and also Adjunct Professor at the University of Waterloo. He has done extensive research in technical areas such as computational complexity, cryptography, number theory, combinatorics, coding theory, analysis, and probability theory. In recent years he has also been working on electronic publishing, electronic commerce, and economics of data networks. He is the authors of such widely cited papers as "Tragic loss or good riddance? The impending demise of traditional scholarly journals," "The decline of unfettered research," and "The bumpy road of electronic commerce." He is also a coinventor of a micropayment system. His home page is http://www.research.att.com/~amo. This meeting of the Digital Commerce Society of Boston will be held on Tuesday, September 7, 1999, from 12pm - 2pm at the Downtown Branch of the Harvard Club of Boston, on One Federal Street. The price for lunch is $35.00. This price includes lunch, room rental, various A/V hardware, and the speakers' lunch. The Harvard Club *does* have dress code: jackets and ties for men (and no sneakers or jeans), and "appropriate business attire" (whatever that means), for women. Fair warning: since we purchase these luncheons in advance, we will be unable to refund the price of your lunch if the Club finds you in violation of the dress code. We need to receive a company check, or money order, (or, if we *really* know you, a personal check) payable to "The Harvard Club of Boston", by Saturday, September 4th, or you won't be on the list for lunch. Checks payable to anyone else but The Harvard Club of Boston will have to be sent back. Checks should be sent to Robert Hettinga, 44 Farquhar Street, Boston, Massachusetts, 02131. Again, they *must* be made payable to "The Harvard Club of Boston", in the amount of $35.00. Please include your e-mail address so that we can send you a confirmation If anyone has questions, or has a problem with these arrangements (We've had to work with glacial A/P departments more than once, for instance), please let us know via e-mail, and we'll see if we can work something out. We are actively searching for future speakers. If you are in Boston on the first Tuesday of the month, and you are a principal in digital commerce, and would like to make a presentation to the Society, please send e-mail to the DCSB Program Committee, care of Robert Hettinga, mailto: [EMAIL PROTECTED]. For more information about the Digital Commerce Society of Boston, send "info dcsb" in the body of a message to mailto: [EMAIL PROTECTED] . If you want to subscribe to the DCSB e-mail list, send "subscribe dcsb" in the body of a message to mailto: [EMAIL PROTECTED] . We look forward to seeing you there! Cheers, Robert Hettinga Moderator, The Digital Commerce Society of Boston -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.1 for non-commercial use http://www.pgp.com iQEVAwUBN7Amr8UCGwxmWcHhAQFuiQf/bf1uRwIyXmKZI9J5VE5kIhJ/5UW58r8U F8K9H72Sn6yghF8krhEr63gu3Y9TpS0/utexTt8oRm37syBGvnh3+1JGKj2zI+5C 8gYiSyQUXbaZ6a086LQsC8DMOwDjKJ34AaF8ZP/vhoNUYIl8u00RhYyRJDMGRsHE SA+UsRZOv5J4IwyEuob6xls/fI9lqF51juvJkAPYCCT5yzqV7oNj5E2yTbxFlLeq /JeV5JRPTOkI1aV/6kpuxFdJXRBd8W8nAYgGedpdRQ49koO+3uCfYtkEXTaT1+Lv FvoyQjcuXZGRyTx0MCKBXTDPsi3Ld00dH+S4XumXPqj71GW5sg7Vpw== =1myx -END PGP SIGNATURE- - Robert A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar
Re: IP: Clinton comes after the Internet by Joseph Farah
A working group like this with only two years to go in an administration worrying about its place in history must be one of two things, only: 1. we are referring this to committee so that we can say we did something without having actually to do anything (what is sometimes rendered in Italian as a "bella figura") 2. we already have our draft conclusions in white paper form and we need to have the appearance of due process A betting pool might be in order, but I narrowly favor #2 --dan
Re: Summary re: /dev/random
I have found this discussion very stimulating and enlightening. I'd like to make a couple of comments: 1. Mr. Kelsey's argument that entropy should only be added in large quanta is compelling, but I wonder if it goes far enough. I would argue that entropy collected from different sources (disk, network, sound card, user input, etc.) should be collected in separate pools, with each pool taped only when enough entropy has been collected in that pool. Mixing sources gives an attacker added opportunities. For example, say entropy is being mixed from disk accesses and from network activity. An attacker could flood his target with network packets he controlled, insuring that there would be few disk entropy deposits in any given quanta release. On the other hand, if the entropy were collected separately, disk activity entropy would completely rekey the PRNG whenever enough accumulated, regardless of network manipulation. Similarly, in a system with a hardware entropy source, adding disk entropy in a mixing mode would serve little purpose, but if the pools were kept separate, disk entropy would be a valuable backup in case the hardware source failed or were compromised. 2. It seems clear that the best solution combines strong crypto primitives with entropy collection. I wonder how much of the resistance expressed in this thread by has to do with concerns about performance. For this reason, I think RC4 deserves further consideration. It is very fast and has a natural entropy pool built in. With some care, I believe RC4 can be used in such a way that attacks on the PRNG can be equated to an attacks on RC4 as a cipher. The cryproanalytic significance of RC4's imperfect whiteness is questionable and can be addressed in a number of ways, if needed. I have some thoughts on a fairly simple and efficient multi-pool PRNG design based on RC4, if anyone is interested. 3. With regard to diskless nodes, I suggest that the cryptographic community should push back by saying that some entropy source is a requirement and come up with a specification (minimum bit rate, maximum acceptable color, testability, open design, etc.). An entropy source spec would reward Intel for doing the right thing and encourage other processor manufacturers to follow their lead. A hardware RNG can also be added at the board level. This takes careful engineering, but is not that expensive. The review of the Pentium III RNG on www.cryptography.com seems to imply that Intel is only claiming patent protection on its whitening circuit, which is superfluous, if not harmful. If so, their RNG design could be copied. Arnold Reinhold
Re: linux-ipsec: Re: Summary re: /dev/random
"Arnold" == Arnold G Reinhold [EMAIL PROTECTED] writes:
Arnold I have found this discussion very stimulating and
Arnold enlightening. I'd like to make a couple of comments:
Arnold 1. Mr. Kelsey's argument that entropy should only be added in
Arnold large quanta is compelling, but I wonder if it goes far
Arnold enough. I would argue that entropy collected from different
Arnold sources (disk, network, sound card, user input, etc.) should
Arnold be collected in separate pools, with each pool taped only
Arnold when enough entropy has been collected in that pool.
Arnold Mixing sources gives an attacker added opportunities. For
Arnold example, say entropy is being mixed from disk accesses and
Arnold from network activity. An attacker could flood his target
Arnold with network packets he controlled, insuring that there would
Arnold be few disk entropy deposits in any given quanta release. On
Arnold the other hand, if the entropy were collected separately,
Arnold disk activity entropy would completely rekey the PRNG
Arnold whenever enough accumulated, regardless of network
Arnold manipulation. Similarly, in a system with a hardware entropy
Arnold source, adding disk entropy in a mixing mode would serve
Arnold little purpose, but if the pools were kept separate, disk
Arnold entropy would be a valuable backup in case the hardware
Arnold source failed or were compromised.
I think this makes sense only if the "entropy source" under
consideration isn't actually any good. If if is reasonably sound (and
in particular, its entropy amount estimated conservatively) then there
isn't a problem. For example, if an attacker floods with network
messages, and you use network timing as an entropy source, the design
job was to pick a conservative lower bound of entropy per arrival
given that the arrivals may all be controlled by an attacker. If
you've done that, then the attack doesn't hurt.
Arnold 2. It seems clear that the best solution combines strong
Arnold crypto primitives with entropy collection. I wonder how much
Arnold of the resistance expressed in this thread by has to do with
Arnold concerns about performance. For this reason, I think RC4
Arnold deserves further consideration. It is very fast and has a
Arnold natural entropy pool built in. With some care, I believe RC4
Arnold can be used in such a way that attacks on the PRNG can be
Arnold equated to an attacks on RC4 as a cipher. The cryproanalytic
Arnold significance of RC4's imperfect whiteness is questionable and
Arnold can be addressed in a number of ways, if needed. I have some
Arnold thoughts on a fairly simple and efficient multi-pool PRNG
Arnold design based on RC4, if anyone is interested.
Well, yes, but /dev/{u,}random already does use strong crypto (a
strong cryptographic hash, to be precise). I expect RC4 could do the
job but is there any reason to replace what's there now (MD5 and
SHA-1) with RC4 or anything else?
Arnold 3. With regard to diskless nodes, I suggest that the
Arnold cryptographic community should push back by saying that some
Arnold entropy source is a requirement and come up with a
Arnold specification (minimum bit rate, maximum acceptable color,
Arnold testability, open design, etc.). An entropy source spec would
Arnold reward Intel for doing the right thing and encourage other
Arnold processor manufacturers to follow their lead.
Obviously an entropy source is required, but I'm not prepared to
translate that into a requirement for dedicated hardware. I still
believe (based on experiments -- though not on PC hardware) that
network arrival timing done with low order bits from a CPU cycle
counter supply non-zero entropy.
Arnold A hardware RNG can also be added at the board level. This
Arnold takes careful engineering, but is not that expensive. The
Arnold review of the Pentium III RNG on www.cryptography.com seems
Arnold to imply that Intel is only claiming patent protection on its
Arnold whitening circuit, which is superfluous, if not harmful. If
Arnold so, their RNG design could be copied.
There are probably plenty of designs; at the block diagram level they
are pretty simple and pretty obvious. The devil is in the details.
By the way, various crypto accelerator chips now come with an RNG
built-in. Some may be subject to export control, which would make
them unuseable in a Linux contents, but perhaps not all of them.
paul
