IP: WHITE HOUSE PROPOSES MASSIVE COMPUTER MONITORING SYSTEM
--- begin forwarded text Date: Tue, 27 Jul 1999 22:51:23 -0400 To: [EMAIL PROTECTED] From: "L.J.Alberts" [EMAIL PROTECTED] Subject: IP: WHITE HOUSE PROPOSES MASSIVE COMPUTER MONITORING SYSTEM Sender: [EMAIL PROTECTED] Reply-To: "L.J.Alberts" [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- X DRUDGE REPORT X TUESDAY, JULY 27, 1999 20:28:41 ET X WHITE HOUSE PROPOSES MASSIVE COMPUTER MONITORING SYSTEM; WILL TRACK BANKING, TELECOMMUNICATIONS AND OTHER NETWORKS The Clinton administration has developed a plan for an extensive computer monitoring system, overseen by the FBI, that will track banking, telecommunications and other industries, it will be reported on Wednesday. The National Security Council is conducting a legal and technical review of the new Clinton plan, a final report is scheduled to be made public in September. NEW YORK TIMES reporter John Markoff has been shown a draft, according to publishing sources, and was busy on Tuesday afternoon preparing a story. In some government circles, the proposed system has been nicknamed "Hillary." The plan calls for the development of a "sophisticated software system to monitor activities on non-military government networks" and a separate system to "track all transactions used in the banking, telecommunications and transportation industries." The system is intended to alert law enforcement officials to computer attacks that might cripple governmental or the nation's economy. But it could also become a massive government utility used for surveillance of citizens, critics contend, with great potential for misuse. "Law enforcement agencies obviously would be under great temptation to expand the use of the information in pursuit of suspected criminals," the TIMES will report. The plan has drawn fire from civil libertarians because it blends "civilian and military functions" in protecting the nation's computer networks. Law enforcement agencies would be under great temptation to expand the use of the information in pursuit of suspected criminals. And the plan would put a new and powerful tool into the hands of the FBI. Developing. _ Reports are moved when circumstances warrant (c)DRUDGE REPORT 1999 Not for reproduction without permission of the author -BEGIN PGP SIGNATURE- Version: PGP Personal Privacy 6.5.1 iQEVAwUBN55wKuX/Rf8MRjfTAQH2qQf/fi2ru8l5gv5zkJ0zXoMPaPX+27yavkeY M0baGGRwFdhNxGt9RwWDZf4YZ36m6oZ4iF3BVM8+ujVByCtWUcP+Q1nDDmti/nZo ob69QPEACe0Nxc2g7ODvtcpsp95JA7BzMXDrYC4ryZWFdOF2xpe7D/fMYDcrpHr8 Mcgq4GibDPoXvrRszDj/Wqpao/B1f/GYtwv2vKGi0Pke9mnNMxoRTdIooUai9Qa+ kjWFsoyMBuY+qPA98u9n6C0Xbrrt1+CHM2SNYSXVEXpckg+qEcpIq58mUlvH4GI5 Dq18a4zfaVk837V06ZbczGwg1RCaJhh/hWVOTNrYTTXSZ7clIziVHg== =5A6h -END PGP SIGNATURE- To subscribe or unsubscribe, email: [EMAIL PROTECTED] with the message: (un)subscribe ignition-point email@address or (un)subscribe ignition-point-digest 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'
Computer Monitoring System
Title: Computer Monitoring System From the N.Y. Times web site: --- July 28, 1999 U.S. Drafting Plan for Computer Monitoring System By JOHN MARKOFF The Clinton Administration has developed a plan for an extensive computer monitoring system, overseen by the Federal Bureau of Investigation, to protect the nation's crucial data networks from intruders. The plan, an outgrowth of the Administration's anti-terrorism program, has already raised concerns from civil liberties groups. A draft prepared by officials at the National Security Council last month, which was provided to The New York Times by a civil liberties group, calls for a sophisticated software system to monitor activities on nonmilitary Government networks and a separate system to track networks used in crucial industries like banking, telecommunications and transportation. --- the rest of the article can be found at: http://www.nytimes.com/library/tech/99/07/biztech/articles/28compute.html
Re: depleting the random number generator -- repeated state
At 3:22 PM -0700 7/27/99, Jon Callas wrote:
I built a PRNG that used an RC4 variant as John Kelsey said. The thing is
also actually very Yarrow-like. I modified it later to use a state array
512 long instead of 256 long, just so it would have a larger entropy pool.
When I added more entropy, I added entropy using the same basic algorithm
as RC4 key setup. The difference was that the S-array was not 0..256, but
whatever the state of the array was. You simply *don't* use the input
mechanism that Anonymous described.
I'll also note that the state-loop that Anonymous described can easily be
detected and corrected. Given that this is a PRNG, not a cipher,
predictability is not a requirement (although you can algorithmically
correct in a way that will still make it a cipher).
Someday, I need to update the Entropy Manager (as I called it) and
re-release it.
Jon
I believe the input mechanism Anonymous described *is* the RC4 key setup
mechanism. In any case, I take Anonymous' remarks about the brittle nature
of RC4 very seriously. I wouldn't mess with it just to double the entropy
pool. If you think more entropy is needed, build a side buffer or run two
copies of RC4.
There is a lot to be said for using a known cryptographic object like RC4
to build other tools. It is very valuable to be able to translate any
imagined attack on the system your are proposing into an equivalant attack
on RC4. You then incorporate all past and future analysis of RC4 to your
system.
Anyway here is my latest nonce maker proposal, based on the thread so far
(in pseudocode):
private unsigned byte i, j, S[256]
mix(K) {
i = i + 1
j = j + S[i] + K
swap S[i] and S[j]
t = S[i] + S[j]
return S[t]
}
setup() {
i = j = 0
for m = 0 to 255 S[m] = m
for m = 1 to 256 mix(get_a_true_random_byte())
i = j = 0
for m = 1 to 256 mix(0)
}
deposit(string) {
prev = mix(0)
for m = 1 to length(string) prev = mix(string[m-1] xor prev)
i = j = 0
}
getnonce(length) {
bytestring nonce
deposit(current_time())
for m = 1 to length concatinate (nonce, mix(0))
return nonce
}
mix is equivalent to the RC4 setup loop. It is also the RC4 cipher loop if
K=0. The indicies i and j are reinitialized every time mix is run in setup
mode to keep out of the repeated state. All entropy deposits are
RC4-encoded to prevent any chosen-entropy attack.
You would call deposit at opportune times like key presses, mouse moves,
disk and network I/O. Because i and j are reset so often and because nonces
and deposits are likely to be short, the begining of the S arrray will get
more mixing than the rest of the array. Therefore, it might be desirable to
stir the S array throughly every so often, perhaps by calling mix(0)
repeatedly during idle time.
Arnold Reinhold
Re: US Urges Ban of Internet Crypto
In [EMAIL PROTECTED], on 07/27/99 at 09:17 PM, John Young [EMAIL PROTECTED] said: use of the Internet to distribute encryption products will render Wassenaar's controls immaterial." The bitch is getting a clue. :) -- --- William H. Geiger III http://www.openpgp.net Geiger ConsultingCooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP MR/2 the only way for secure e-mail. OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html Talk About PGP on IRC EFNet Channel: #pgp Nick: whgiii Hi Jeff!! :) ---
Re: US Urges Ban of Internet Crypto
[Forwarded because no one has brought up this notion in a while. My problem with it is that most people don't seem to like the 2nd amendment any more so this can hardly help to popularize the cause. My feeling is that the 4th and 5th amendments have more potential protection in them. --Perry] John, et al., In a moment of logic, as if that mattered, WHEREAS By the declaration of the state, cryptographic capacity is a weapon, and WHEREAS By the facts of use, cryptographic capacity is a personal weapon, and WHEREAS The (US) Second Amendment denies the (US) federal government the authority to restrict personal weapons, THEREFORE The right to bear crypto is a (US) constitutional right. Of course, logic has nothing to do with it because the very definition of politics is the art of making decisions based on the manipulation of emotion, but I am, whether by choice or by genotype, a man of logic and not of emotion, though I am pissed off... --dan
US Urges Ban of Internet Crypto
John Young writes: Nations do not control distribution of intangible items. While I recognize that this issue is controversial, unless we address this situation, use of the Internet to distribute encryption products will render Wassenaar's controls immaterial." I just love this sentence. So, let's create unenforcible legislation, and then try to pave over all the world in the attempt to make reality comply. Name's Janet Reno, huh? What's worse, the gullible Germans will probably heel.
Re: linux-ipsec: Re: TRNG, PRNG
At 08:02 PM 7/22/99 +0200, Anonymous wrote: That is: 1a') When there is entropy in the pool, it [/dev/urandom] gobbles it all up before acting like a PRNG. Leverage factor=1. This causes other applications to stall if they need to read /dev/random. This does not seem to be a big problem, and in fact is arguably the right behavior. What it means is, /dev/urandom provides the best quality random numbers possible, given the entropy available. H. People usually take the "minimax" approach to security analysis; that is, we design our defenses assuming the opponents make their best move. Therefore I don't undestand the argument for using "best available" bits. ISTM that if a certain quality X+ is required, it should be required always, unless proven otherwise. To say it the other way, if a certain quality X- suffices sometimes it should suffice always, unless proven otherwise. In my case X- is the unreseeded PRNG behavior of /dev/urandom. The designers of linux-ipsec have evidently decided this is good enough, because that's where they get key material. In my application, many keys will be generated during conditions where the TRNG has been totally depleted. I must assume that attackers will know this, and will be able to focus their attacks on those keys. If you are telling me that the unreseeded PRNG is not good enough, then I have deployed an insecure system. That would be bad, and there would be no way to fix it short of a hardware TRNG. OTOH if the unreseeded PRNG *is* good enough, then it is wastefully selfish for it to gobble up all the TRNG bits. It is improper to assume that the application that is gobbling up all the PRNG bits is the only application running on this machine. In my case there are other applications for which one could make a very good argument that they need TRNG bits under conditions when IPsec does not. Also.. At 12:40 PM 7/22/99 -0700, bram wrote in part: In particular, consider the following reseeding schedule: a) Every N minutes... b) Every Z bits of PRNG output... c) As soon as a quantum of TRNG material is available ... ... whichever comes *LAST*, and where N and Z are chosen to ensure a good leverage ratio. a) and b) don't help much - the true answer is c). One could argue (a) and (b) *do* add something -- they address the problem that started this thread, namely the seemingly-needless depletion of the TRNG. Right?
Re: depleting the random number generator -- repeated state
At 10:49 AM -0400 7/28/99, Arnold G. Reinhold wrote: I believe the input mechanism Anonymous described *is* the RC4 key setup mechanism. In any case, I take Anonymous' remarks about the brittle nature of RC4 very seriously. I wouldn't mess with it just to double the entropy pool. If you think more entropy is needed, build a side buffer or run two copies of RC4. It doesn't double the entropy pool. It increases it from being order 256! to being order 512!. Incidentally, the remarks about brittleness apply just as much to a variant that is 9 bits wide as well as 8 bits wide. There are certain states you don't want it to be in. Look for them. Compensate. There is a lot to be said for using a known cryptographic object like RC4 to build other tools. It is very valuable to be able to translate any imagined attack on the system your are proposing into an equivalant attack on RC4. You then incorporate all past and future analysis of RC4 to your system. I agree completely. But also read Schneier's remarks on wide variants of RC4 -- which were my inspiration to use a wide variant. The math all works the same, strengths and vulnerabilities. [...] ... All entropy deposits are RC4-encoded to prevent any chosen-entropy attack. You would call deposit at opportune times like key presses, mouse moves, disk and network I/O. Because i and j are reset so often and because nonces and deposits are likely to be short, the begining of the S arrray will get more mixing than the rest of the array. Therefore, it might be desirable to stir the S array throughly every so often, perhaps by calling mix(0) repeatedly during idle time. That's one of the places where we differ. I never directly add in entropy deposits. I run a separate entropy pool that is hash-based, and periodically tap that pool to update the secondary pool. I get really nervous about adding entropy directly into a single pool. I also like to capitalize on the properties of hash functions for prepping the entropy. Jon
Re: depleting the random number generator -- repeated state
At 2:51 PM -0400 7/28/99, Steven M. Bellovin wrote: In message v04011701b3c4f4fbabb1@[24.218.56.100], "Arnold G. Reinhold" writes I'd spin it the other way. The best approach to making nonces -- DH exponents, symetric keys, etc -- is to use a true source of randomness. That eliminates one area of risk. However most computers do not come with random number sources, so one uses unpredictable events and so on to glean entropy. To harvest that entropy you use a whitener. If you use a cryptographic function to do your whitening you get the added advantage of shielding the randomness pool from an attacker. Define "best approach". Perhaps I should have said "The best approach ... is to use a *theoretically perfect* source of randomness." I tried to point out such things don't exist and come to the same conclusion you do, namely "A sound design mixes both." At 11:16 AM -0700 7/28/99, Jon Callas wrote: At 10:49 AM -0400 7/28/99, Arnold G. Reinhold wrote: I believe the input mechanism Anonymous described *is* the RC4 key setup mechanism. In any case, I take Anonymous' remarks about the brittle nature of RC4 very seriously. I wouldn't mess with it just to double the entropy pool. If you think more entropy is needed, build a side buffer or run two copies of RC4. It doesn't double the entropy pool. It increases it from being order 256! to being order 512!. Good point, but the ratio of log2(512!) to log2(256!) is only 2.3, a little more than double the number of bits. That's not worth leaving the accumulated body of RC4 analysis, IMHO. That's one of the places where we differ. I never directly add in entropy deposits. I run a separate entropy pool that is hash-based, and periodically tap that pool to update the secondary pool. I get really nervous about adding entropy directly into a single pool. I also like to capitalize on the properties of hash functions for prepping the entropy. Can you say what you fear might happen if you directly add entropy deposits? I don't see the problem. Arnold Reinhold
Re: US Urges Ban of Internet Crypto
I recognize that this issue is controversial, unless we address this situation, use of the Internet to distribute encryption products will render Wassenaar's controls immaterial." Gee, I thought Reinsch said it didn't matter that encryption software was distributed on the Internet because nobody will trust anything they download off the Internet... :-) Trying to debate these people rationally is like trying to nail Jello to a wall. Phil
