Re: Field slide attacks and how to avoid them.
But XDR is so BORING compared to a REAL standard like ASN.1! It doesn't have infinite possibilies for object definitions requiring help from standards committees, multiple incompatible data representations with different kinds of ambiguity, or ugly API packages that are too large to believe that the implementers debugged them adequately. That's just no fun at all! (I realize it doesn't do everything in the world, or have all the power, expressiveness, or bit-twiddling that ASN.1 or even PGP/OpenPGP data formats have, but there's a lot to be said for something that's minimal and works.) At 04:50 PM 09/10/2001 -0400, Kevin E. Fu wrote: We use hashes of marshalled XDR representations of data in the SFS read-only file system [2]. This allows us to protect the integrity of public, read-only content without having to worry about simple splicing attacks. The eXternal Data Representation Standard is popular for implementing things like NFS [2, 4]. ... [0] 6.033 Spring 2001 Quiz 2. http://web.mit.edu/6.033/www/handouts/s01_2.ps [1] Dos and Dont's of Client Authentication on the Web, USENIX Security 2001, http://cookies.lcs.mit.edu/ [2] NFS Version 3 Protocol Specification, RFC 1813 [3] SFS Read-only File System, USENIX OSDI 2000, http://www.fs.net/ [4] XDR: External Data Representation, RFC 1014 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: FC: Majority of Americans want anti-encryption laws, poll says
On Tue, 18 Sep 2001, Declan McCullagh wrote: The survey was commissioned by Newsweek. An explanation from Princeton Survey Research Associates and the exact wording of the question asked (which did cover privacy and business impact) is here: http://www.politechbot.com/p-02530.html The wording asked if people favor 'reducing' crypto, a wording so horribly slanted as to be outright misleading - there's a big difference in the way one 'reduces' emissions from federal vehicles and the way one *bans* crypto. -Bram Cohen Markets can remain irrational longer than you can remain solvent -- John Maynard Keynes - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: chip-level randomness?
On Tue, 18 Sep 2001, Pawel Krawczyk wrote: On Mon, Sep 17, 2001 at 01:44:57PM -0700, Bram Cohen wrote: What is important, it *doesn't* feed the built-in Linux kernel PRNG available in /dev/urandom and /dev/random, so you have either to only use the hardware generator or feed /dev/urandom yourself. That's so ... stupid. Why go through all the work of making the thing run and then leave it unplugged? It's not that stupid, as feeding the PRNG from i810_rng at the kernel level would be resource intensive, You only have to do it once at startup to get enough entropy in there. not necessary in general case Since most applications reading /dev/random don't want random numbers anyway? and would require to invent some defaults without any reasonable arguments to rely on. Like how often to feed the PRNG, with how much data etc. At startup and with 200 bits of data would be fine. Of course, there's the religion of people who say that /dev/random output 'needs' to contain 'all real' entropy, despite the absolute zero increase in security this results in and the disastrous effect it can have on performance. -Bram Cohen Markets can remain irrational longer than you can remain solvent -- John Maynard Keynes - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Rijndael in Assembler for x86?
[EMAIL PROTECTED] wrote: Perry E. Metzger [EMAIL PROTECTED] wrote: Because it is typically slower by many times than hand tuned assembler. On 14 Sep 2001, at 14:24, Ian Goldberg wrote: Are you sure? For general code, that certainly hasn't been true in a long time; optimizing compilers nowadays can often do *better* then hand-coded assembler. So say compiler writers. I have not found this to be true. Perhaps it is true of some compilers and some people's assembler, and some code. I've done quite a bit of assembler for crypto in the last few years and it very much depends on the CPU/compiler (obviously). The only platform that I have not been able to beat the compiler by %10 or more for an algorithm is PA-RISC. Either my C code is good enough to give the compiler all the help it needs or I need to revisit the architecture :-). The biggest wins are for algorithms where the C compiler does not give access to underlying primitives, ie 32*32-64, or where special tricks can be used due to data relationships that the compiler cannot know about. For x86, there are too few registers and lots of black magic going on. At least for the pentium VTune would reveal everything. For the Ppro/II/III, depending on the compiler (gcc vs VisualC) the C code could sometimes get within %30 of the ASM. For the Pentium 4, ASM is good again. It seems to be a very 'brittle' CPU. Eg. for sha1 (The numbers are relative but may or may not have any relation to something in the real world :-) | P4 |Athalon |P2 Celeron | 1.7ghz | 1.4ghz | 333mhz| |lnx gcc |cygwin gcc|lnx gcc| SHA1 586| 78.594| 135.937 | 26.038| SHA1 686| 81.986| 141.996 | 32.481| SHA1 786| 135.419| 137.804 | 29.106| SHA1 fast | 47.864| 83.846 | 20.828| SHA1 small | 54.322| 62.599 | 12.534| Notice how the different assembler version are all around the same speed for the P2 and Athalon. Even the ratio between the C code versions is similar. But now look at the P4. Special magic can be used to make things very fast, and the 'small' C code version is faster than the loop unrolled version (trace cache thrashing?) For PA-RISC, I've done 1.1, 2.0 and 2.0W code and for some algorithms I cannot beat the optimizer. For others, specifically bignum stuff, 2 to 4 times faster. In this case all multiples are done in the FP unit and data has to be swapped between CPU and FPU via memory so there are lots of opportunities to use 64bit loads etc. HP has good optimizers for a rather tricky architecture. Sparc, I've only done digests, 30-40% speedup seem normal. Simple architecture, simple for the compiler to do a good job. ARM, the compilers are good and the CPUs are simple, I consistently only get 20-40%. The real win comes when trying to get fast with small code size. It is possible to make things much faster for the same reduced footprint. Xscale could be interesting since there are now inter instruction register dependencies. I've normally worked on StrongARM where there are none. Itanium. Amazing speedups with assembler, but hard to write. It is a vector processor if there ever was one. Anything that can do two 64*64-128 multiplies per cycle but with a 15 cycle latency, and no OOO is going to be tricky. For both ARM and PA-RISC I've been able to use instruction set features to improve performance. In theory the algorithms could be coded in C, but it takes CPU architecture/compiler knowledge to write the code :-). eric - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Bush's anti-terror bill appears not to include crypto restrictions
http://www.wired.com/news/politics/0,1283,46953,00.html Bush Bill Rewrites Spy Laws By Declan McCullagh ([EMAIL PROTECTED]) 2:00 a.m. Sep. 19, 2001 PDT WASHINGTON -- The Bush administration will ask for more power to eavesdrop on phone calls, the Internet and voicemail messages, according to an outline of a bill obtained by Wired News. In response to last week's catastrophic terrorist attacks, President Bush plans to ask Congress to approve far-reaching legislation that rewrites U.S. laws dealing with electronic surveillance, immigration and support for terrorists. We will call upon the Congress of the United States to enact these important anti-terrorism measures this week, Attorney General John Ashcroft said Monday. We need these tools to fight the terrorism threat which exists in the United States, and we must meet that growing threat. According to the two-page outline -- which lacks key details and could change before it's sent to Capitol Hill -- police would be able to conduct more wiretaps and use the Carnivore surveillance system in more situations without court orders. That section of the bill appears to mirror an amendment the Senate approved last Thursday evening. No restrictions on encryption products, a prospect feared by some civil libertarians, appear in the outline. The bill hands prosecutors a courtroom edge, saying that accused terrorists should stay in jail by default, that detention of suspected terrorists is mandatory, and that the Immigration and Naturalization Service will have more authority to kick immigrants suspected of being terrorists out of the United States. [...] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Bush's anti-terror bill appears not to include crypto restrictions
-- On 19 Sep 2001, at 11:01, Declan McCullagh wrote: According to the two-page outline -- which lacks key details and could change before it's sent to Capitol Hill -- police would be able to conduct more wiretaps and use the Carnivore surveillance system in more situations without court orders. That section of the bill appears to mirror an amendment the Senate approved last Thursday evening. No restrictions on encryption products, a prospect feared by some civil libertarians, appear in the outline. Since we are now at war, that is not nearly as bad as they could have gotten away with. The legislation authorizes the government to do stuff that they were already doing, and will never stop doing, legal or illegal. The bill hands prosecutors a courtroom edge, saying that accused terrorists should stay in jail by default, that detention of suspected terrorists is mandatory, Not so good. Anyone can easily suspect me of being a terrorist, if I should discuss certain topics that are of interest to this list. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG OxSgK6f7bogCHTXZRxbqohyWo1hd3WuRpZdrxBf 4Bv3zdasO+K/WRhUy/l7ZdgToCl5eZFsH+iQ6vwXV - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Field slide attacks and how to avoid them.
Kevin E. Fu [EMAIL PROTECTED] writes: But XDR is so BORING compared to a REAL standard like ASN.1! It doesn't have infinite possibilies for object definitions requiring help from standards committees, multiple incompatible data representations with different kinds of ambiguity, or ugly API packages that are too large to believe that the implementers debugged them adequately. That's just no fun at all! I can feel this sliding into a specification language debate, but I have to put in a word to defend ASN.1 here. When used by a skilled practitioner, ASN.1 can be truly elegant. The problem is that, like BASIC, it looks deceptively simple, so that everyone thinks they can write a spec in ASN.1 after five minutes study of an ASN.1 introductory guide, and they usually do. The result is a great confused muddle which noone can figure out and everyone implements slightly differently, leading to ASN.1's reputation of being a pain to work with (to paraphrase the famous FORTRAN comment, The determined hack can write crap in any language). Having had experience working with ASN.1, XDR, the SSL specification notation, and PGP, I definitely prefer ASN.1 for its ability (when used correctly) to provide a clear, unambiguous definition of a data exchange format. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: chip-level randomness?
On Wed, Sep 19, 2001 at 01:12:44AM -0700, Bram Cohen wrote: not necessary in general case Since most applications reading /dev/random don't want random numbers anyway? Here I meant exactly what you said about /dev/random religion. On the other hand feeding the /dev/random with i810 during normal system operation is not bad idea, as /dev/random is not a PRNG but pool, that can be emptied if not feed enough from other semi-random events (interrupts, keyboard). At startup and with 200 bits of data would be fine. Of course, there's the religion of people who say that /dev/random output 'needs' to contain 'all real' entropy, despite the absolute zero increase in security this results in and the disastrous effect it can have on performance. Ok, I get your point now. I'm not sure if reading a blocking device (i810) from kernel is a very good idea, however. That's sort of things that is very good suited for userland, when the system goes multiuser and multiprocess. Actually, it would be a quite good idea for the Linux distribution vendors to add a "dd if=/dev/intel_rng of=/dev/random bs=1k count=1" to the PRNG initialization scripts. If it fails, then you probably don't have i810 and everything works the old way... Maybe it's even already done, as the author of i810 daemon seems to be from MandrakeSoft. -- Pawe Krawczyk *** home: http://ceti.pl/~kravietz/ security: http://ipsec.pl/ *** fidonet: 2:486/23 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: chip-level randomness?
At 1:12 AM -0700 9/19/01, Bram Cohen wrote: Of course, there's the religion of people who say that /dev/random output 'needs' to contain 'all real' entropy, despite the absolute zero increase in security this results in and the disastrous effect it can have on performance. If I am generating one time pads, I would certainly prefer /dev/random output to /dev/urandom output. There is much less algorithm exposure. (Although I do still have to worry about the whitening and combining algorithms.) Cheers - Bill - Bill Frantz | The principal effect of| Periwinkle -- Consulting (408)356-8506 | DMCA/SDMI is to prevent| 16345 Englewood Ave. [EMAIL PROTECTED] | fair use. | Los Gatos, CA 95032, USA - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: chip-level randomness?
Bram Cohen wrote: On Tue, 18 Sep 2001, Pawel Krawczyk wrote: [..] It's not that stupid, as feeding the PRNG from i810_rng at the kernel level would be resource intensive, You only have to do it once at startup to get enough entropy in there. If your machine is left on for months or years the seed entropy would become a big target. If your PRNG status is compromised then all future uses of PRNG output are compromised, which means pretty much everything crypto. Other attacks on the PRNG become possible. and would require to invent some defaults without any reasonable arguments to rely on. Like how often to feed the PRNG, with how much data etc. The Intel rng outputs about 8kB/s (I have heard of higher rates). Using all this entropy to reseed a PRNG on a reasonably modern machine would not take up _that_ much resources. And it would pretty much defeat any likely attacks on the PRNG. At startup and with 200 bits of data would be fine. So you need a cryptographically-secure PRNG that takes a 200-bit seed. As the output is used by programs that may use strange and not-yet-invented algorithms which may interact with and weaken the PRNG, how are you going to design it? And what happens if your PRNG is broken? Everything is lost, the attacker has got root so to speak. Of course, there's the religion of people who say that /dev/random output 'needs' to contain 'all real' entropy, despite the absolute zero increase in security this results in and the disastrous effect it can have on performance. Sometimes it may have no effect on security, but it can affect it badly. Brute force attacks on the PNRG could be more efficient than on the cipher if 256 bit or higher keys were used. With the possible introduction of QC looming it might well be advisable to use such key-lengths for data that requires long-term security. I agree that performance hits arise if an all-real-random approach is used, but personally I am in favour of using all the entropy that can easily be collected without taking those hits. The Intel rng can do this nicely (although I would use other sources of entropy as well). -- Peter Fairbrother - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: chip-level randomness?
The real-RNG in the Intel chip generates something like 75 kbits/sec of processed random bits. These are merely wasted if nobody reads them before it generates 75kbits more in the next second. I suggest that if application programs don't read all of these bits out of /dev/intel-rng (or whatever it's called), and the kernel /dev/random pool isn't fully charged with entropy, then the real-RNG driver should feed some of the excess random bits into the /dev/random pool periodically. When and how it siphons off bits from the RNG is a separate issue; but can we agree that feeding otherwise-wasted bits into a depleted /dev/random would be a good idea? A better way to structure this might be for /dev/intel-rng to register with /dev/random as a source of entropy that /dev/random can call upon if it depletes its pool. /dev/random would then be making decisions about when to stir more entropy into the pool (either in response to a read on /dev/random, or to read ahead to increase the available pool in between such reads). Thus, when demand on /dev/random is high, it would become one of the application programs that would compete to read from /dev/intel-rng. Since /dev/random is the defined interface for arbitrary applications to get unpredictable bits out of the kernel, I would expect that in general, /dev/random is likely to be the MAJOR consumer of /dev/intel-rng bits. (Linux IPSEC uses /dev/random or /dev/urandom for keying material. It can easily consume many thousands of random bits per second in doing IKE's Diffie-Hellman to set up dozens of tunnels. Today this surge demand occurs at boot time when setting up preconfigured tunnels -- a particularly bad time since the system hasn't been collecting entropy for very long. /dev/intel-rng's high-spead stream can significantly improve the quality of this keying material, by replenishing the entropy pool almost as fast IPSEC consumes it. Over time, IPSEC's long-term demand for random bits will increase, since opportunistic encryption allows many more tunnels to be created, with much less effort per tunnel by the system administrator.) Also, the PRNG in /dev/random and /dev/urandom may someday be broken by analytical techniques. The more diverse sources of true or apparent randomness that we can feed into it, the less likely it is that a successful theoretical attack on the PRNG will be practically successful. If even a single entropy source of sufficiently high speed is feeding it, even a compromised PRNG may well be unbreakable. John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: chip-level randomness?
On Wed, 19 Sep 2001, Peter Fairbrother wrote: Bram Cohen wrote: You only have to do it once at startup to get enough entropy in there. If your machine is left on for months or years the seed entropy would become a big target. If your PRNG status is compromised then all future uses of PRNG output are compromised, which means pretty much everything crypto. Other attacks on the PRNG become possible. Such attacks can be stopped by reseeding once a minute or so, at much less computational cost than doing it 'continuously'. I think periodic reseedings are worth doing, even though I've never actually heard of an attack on the internal state of a PRNG which was launched *after* it had been seeded properly once already. -Bram Cohen Markets can remain irrational longer than you can remain solvent -- John Maynard Keynes - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NYC events and cell phones
On Mon, 17 Sep 2001, Greg Rose wrote: There is one very simple reason why they might have wanted the encryption switched off. Wiretapping at the base station requires a wiretap order, whereas sniffing the airwaves in a matter of national security is something the NSA is allowed to do (but they can't get a wiretap order in a hurry). I don't know any facts in this matter at all, but I wouldn't be surprised if someone, somewhere, requested air interface encryption to be turned off. Would switching off crypto improve the performance of the base stations at all? If so, the motivation may have been less sinister. -d [Moderator's note: I was under the impression most base stations did the crypto in hardware, so the answer would be no, no performance gain for such equipment. Besides, the main concern would be open channels, not CPU load. Anyone know better? --Perry] -- | Damien Miller [EMAIL PROTECTED] \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Field slide attacks and how to avoid them.
At 03:55 20/09/2001, Peter Gutmann wrote: Paul Crowley [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Peter Gutmann) writes: Kevin E. Fu [EMAIL PROTECTED] writes: But XDR is so BORING compared to a REAL standard like ASN.1! I can feel this sliding into a specification language debate, but I have to put in a word to defend ASN.1 here. Those choosing data formats for crypto purposes might want to consider the simple and elegant format S-expression used by SPKI, described here: And those who enjoy pain shouldn't forget X.12, EDIFACT, and HL7. Surely we should all be using some sort of *XML* format! ;-) J - James Robertson Step Two Designs Pty Ltd Knowledge Management Consultancy, SGML XML Illumination: an out-of-the-box Intranet solution http://www.steptwo.com.au/ [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: chip-level randomness?
- Original Message - From: Theodore Tso [EMAIL PROTECTED] To: John Gilmore [EMAIL PROTECTED] Cc: Pawel Krawczyk [EMAIL PROTECTED]; Bram Cohen [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, September 20, 2001 5:17 AM Subject: Re: chip-level randomness? [...] On the other hand, for most people, on balance it's probably better for the kernel to just blindly trust the 810 random number generator to be free from faults (either deliberate or accidentally induced), since the alternative (an incompletely seeded RNG) is probably worst for most folks. Not only that: I don't think that feeding predictable input to the entropy pool is going to make the PRNG's output any worse. If you don't bump up the entropy estimator (risking a misleading estimate), it's a sort of Pascal's Wager: you may or may not be better off, but surely you won't be worse off. Enzo - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Field slide attacks and how to avoid them.
Or also their XML equivalents: http://xml.coverpages.org/xml-spki.html Enzo - Original Message - From: Paul Crowley [EMAIL PROTECTED] To: Peter Gutmann [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, September 20, 2001 1:49 AM Subject: Re: Field slide attacks and how to avoid them. [EMAIL PROTECTED] (Peter Gutmann) writes: Kevin E. Fu [EMAIL PROTECTED] writes: But XDR is so BORING compared to a REAL standard like ASN.1! I can feel this sliding into a specification language debate, but I have to put in a word to defend ASN.1 here. Those choosing data formats for crypto purposes might want to consider the simple and elegant format S-expression used by SPKI, described here: http://theory.lcs.mit.edu/~rivest/sexp.txt [Moderator's note: I'm a big fan of that format. --Perry] -- __ Paul Crowley \/ o\ [EMAIL PROTECTED] /\__/ http://www.cluefactory.org.uk/paul/ Conservation of angular momentum makes the world go around - John Clark - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Feds: Hijackers didn't use Crypto
http://dailynews.yahoo.com/h/nm/20010918/ts/attack_investigation_dc_23.html Tuesday September 18 7:55 PM ET News Home - Yahoo! - My Yahoo! - News Alerts - Help FBI Investigating Florida Terrorist Connection (WKMG, Orlando) By James Vicini WASHINGTON (Reuters) - The FBI (news - web sites) is investigating whether other airplanes may have been targeted for hijacking as it seeks to question more than 190 people about last week's deadly airline attacks, U.S. Attorney General John Ashcroft (news - web sites) said on Tuesday. Ashcroft also said 75 people who may have helpful information about the attacks are in custody for immigration violations, and new steps were adopted allowing even longer detention of such individuals before charges must be brought. ``We are looking at the possibility that there may have been more than four planes targeted for hijacking, but we are not able at this time to confirm that,'' he told a news conference at FBI headquarters. Two of the airplanes hijacked a week ago slammed into New York's World Trade Center, another into the Pentagon (news - web sites) outside Washington and a fourth into a field in rural Pennsylvania. The toll of people officially listed as dead or missing following the Sept. 11 assaults approached 6,000 on Tuesday. Ashcroft said he directed the head of the U.S. Immigration and Naturalization Service to revise its regulations, which had allowed for 24 hours for a decision on whether to charge a person taken into custody because of a violation. ``The revision announced last night expands the 24-hour time period to 48 hours, or to an additional reasonable time, if necessary, under an emergency, or in other extraordinary circumstances,'' Ashcroft said. EVERY LEGAL STEP ``We have a responsibility to use every legal means at our disposal to prevent further terrorist activity by taking people into custody who have violated the law and who may pose a threat to America,'' he said. Federal law enforcement officials said investigators were trying to determine whether any of those in custody may have planned other hijackings and they stepped up the search for accomplices in the biggest investigation in FBI history. In Washington, D.C., an FBI official told reporters the hijackers and their known associates used public computers, such as those in libraries, as well as their own personal computers to communicate. ``They did use it (the Internet) and they used it well,'' the official said of the e-mails of the hijackers and their associates. The FBI has been able to get e-mails that date back as far as 30 to 45 days, the official said. The official said the e-mails were in English and Arabic, that there were hundreds of communications, and the e-mails were not just limited to the United States. The hijackers did not use encryption techniques, the official said. The official said the FBI had received good cooperation in the investigation from Internet service providers, along with banks in tracing the money trail and the airline industry. In south Florida, where a number of the suspected hijackers are thought to have lived recently, the FBI searched library computer records, librarians said on Tuesday. In Fort Lauderdale on Monday, FBI officials searched Broward County Library records of patrons who signed up to use some 600 computers with Internet access at 37 library branches, dating back to Sept. 1, 2000, Libraries Director Sam Morrison told Reuters on Tuesday. Ashcroft said the list of more than 190 people wanted for questioning had been sent to federal, state and local law enforcement officials and to the airline industry. The list on Friday had more than 100 names. The officials said the FBI was investigating whether any of the 75 individuals -- up from 49 a day ago -- being held for immigration violations in the course of questioning about the attacks or those arrested as material witnesses may have been plotting other hijackings. SAUDI ARABIAN-BORN RADIOLOGIST QUESTIONED In San Antonio, a Saudi Arabian-born radiologist had been detained and was being questioned by the FBI after his apartment was raided last week, FBI agents said. He works at the University of Texas Health Science Center in San Antonio. The FBI would not say whether he was suspected of being connected to two men who are in custody in New York after they were removed from an Amtrak train in Fort Worth, Texas, last week carrying box-cutters and a large amount of cash. The train was headed for San Antonio, and agents said the box-cutters were similar to those believed to have been used by hijackers in the attacks. The federal law enforcement officials said the FBI remained interested in the two men, who gave their names to police in Texas as Ayub Ali Khan, 51, and Mohammed Jaweed Azmath, 47. They were flown to New York for questioning, they said. Investigators also remained interested in the first man who was arrested last week on a material witness warrant, the
Re: chip-level randomness?
Bram, I need _lots_ of random-looking bits to use as covertraffic, so I'm using continuous reseeding (of a BBS PRNG) using i810_rng output on i386 platform as well as other sources (the usual suspects plus CD latency plus an optional USB feed-through rng device a bit like a dongle). I don't use a rng on Apple, 'cos it doesn't have one. Others would perhaps not need so many bits. I do hash them, but I don't really trust any hash, algorithm, or rng, so I use all the entropy I can get from anywhere and mix it up. I try to arrange things so each source is sufficient by itself to provide decent protection. It might be a better idea to schedule reseeding of the PRNG depending on usage rather than time for more everyday use. Actually I don't disagree with you much, except I'd like to see reseeding more often than once a minute. There is another reason to use a PRNG rather than a real-rng, which is to deliberately repeat random output for debugging, replaying games, etc. Not very relevant to crypto, except perhaps as part of an attack strategy. -- Peter On Wed, 19 Sep 2001, Peter Fairbrother wrote: Bram Cohen wrote: You only have to do it once at startup to get enough entropy in there. If your machine is left on for months or years the seed entropy would become a big target. If your PRNG status is compromised then all future uses of PRNG output are compromised, which means pretty much everything crypto. Other attacks on the PRNG become possible. Such attacks can be stopped by reseeding once a minute or so, at much less computational cost than doing it 'continuously'. I think periodic reseedings are worth doing, even though I've never actually heard of an attack on the internal state of a PRNG which was launched *after* it had been seeded properly once already. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Bush's anti-terror bill appears not to include crypto restrictions
On Wed, Sep 19, 2001 at 09:23:56AM -0700, [EMAIL PROTECTED] wrote: Not so good. Anyone can easily suspect me of being a terrorist, if I should discuss certain topics that are of interest to this list. Yeah, the draft sent to Congress late Wednesday doesn't have crypto restrictions, but it does have a lot of wiretapping and FISA stuff. Probably the most dramatic changes to wiretapping/electronic surveillance law since CALEA. Wartimeliberty.com has posted the text of the draft bill, called the Mobilization Against Terrorism Act: http://www.wartimeliberty.com/article.pl?sid=01/09/20/0333204 The outline (if you want a quick summary) is here: http://www.wartimeliberty.com/article.pl?sid=01/09/19/2311225mode=thread -Declan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
