Slashdot Mirror

I think GOSIP is recommended for use, not required, but let them explain their need for exceptions.

Or tell them to go away, as you're too busy trying meet GOSIP standards so your GOSIP network can then talk to their GOSIP network.

I think GOSIP is recommended for use, not required, but let them explain their need for exceptions.

Or tell them to go away, as you're too busy trying meet GOSIP standards so your GOSIP network can then talk to their GOSIP network.

I think GOSIP is recommended for use, not required, but let them explain their need for exceptions.

Or tell them to go away, as you're too busy trying meet GOSIP standards so your GOSIP network can then talk to their GOSIP network.

I work in a testing lab where we have to run large numbers of regression tests that would be incredibly time consuming if we didn't use automation tools.

I've been using Expect for test automation on the latest series of tests. Expect is an automation scripting tool that runs on top of Tcl. It is very useful for automating command-line based applications using "send &ltstring> expect &ltstring&gt" sequences.

As far as licensing is concerned, Expect was developed at the NIST, and has been released into the public domain. That's about as free as you can get.

-pf, link whore

Could I suggest someone protests to the delegated naming authority, which is listed as:

Federal Networking Council
4001 N. Fairfax Drive
Arlington, VA 22203
Phone: (703) 522-6410
EMail: execdir@fnc.gov
URL: http://www.fnc.gov

.

Too bad nothing is sacred, not even a Megabyte. Looking at the Historical Context* on the page http://physics.nist.gov/cuu/Units/bina ry.html the other guy put in his flame^H^H^H^H^Hpost, we used (until less than 2 years ago, I might add) to think of MB as 2^20 bytes. I suppose my age is showing a bit here. I am inclined to think that the IEC saw the error of their ways too, choosing Mebibytes as the spelling for the new prefix (I pronounce it maybe-bytes, as in depends on whom you ask what MB means :)

I would like to point out that Maxtor was one of the first to break ranks, and start using the tin-filled MB in 1995 (3 years before the IEC document quoted above). As shown here, the 245MB 7245AT specs. If you look near the bottom, the engineers even say "Yields: 245.6 Million Bytes (Approx. 234 MegaBytes)".

Official International SI norm:

1 MegaByte (MB) is 1,000,000 bytes..
1 MebiByte (MiB) is 1,048,576 bytes...

Get your facts straight, Maxtor is right..

And yes, about Maxtors timing issues.., own two myself (not the 80GB) and they suck...

More details: Large-Disk-HOWTO

http://www.nist.gov/public_ affairs/releases/g00-108.htm

I don't think this press release is referenced at the Science News article.

To start with, you need a good OCR engine. There are several out there that I've used that are very good (from Caere, Nestor, Mitek or CGK). These companies all offer libraries for putting together your own document processing engine. They return the text, often return font/pointsize information and even let you know the confidence of the return value. You could use a fullblown app and try and wrap it, but OCR Shop from Vividata is the only app with a command line interface, which you'd need to handle any reasonable volume.

From this, you can generate all sorts of output with the correct formatting. OCR Shop, which I worked on for Vividata, allowed output to many different formats, including HTML, Word and Framemaker. Depending on the complexity of your document, you can do a fairly good job of outputing what you see on the page. Outputing to PDF wouldn't be all that hard. We set that up as an output format for our scanning software at Vividata. Granted, it was a CCIT G4 bitmap wrapped in a PDF shell, but Acrobat is as close to a cross platform image viewer that most people will have installed that you can find.

So how to make it searchable. You can go the route of saving the bitmap image and do searching on the accompanying OCR text output. This way, you get the formatting of the document right, but you end up using up a lot more space. Or you can try and do the formatting correctly on the text document, fix up any typos (or not) and use that. Both have advantages.

I've gotten the itch on several occasions to put together an open source OCR program, with both command line and GUI interfaces. A lot of the pieces are already there. The best, free OCR engine I know of is the NIST OCR Engine. It's a bit old, the code needs some polishing and one would need to put train some memories for standard fonts, but it would make for a pretty nice little app. Then it's just a matter of creating some internal representation of the formatting and write some output functions for the different types of output (HTML, PDF, RTF...). But my copious free time has not yet given me that opportunity.

Skipjack is actually a 64-bit block cipher (with an 80-bit key).

The algorithm has been declassified. You can get the specification from NIST's Skipjack and KEA webpage.

In the deep past, it was DES. Everyone knew it, the code was readily available, the algorithm very heavily analyzed, and it was a near universal standard. In the future, it will be the AES winner, as the code will be readily available, the algorithm very heavily analyzed, and a near universal standard.

Currently, it has been more difficult. There was no clear standard when it became clear that DES's useful lifetime was over. People tended to use algorithms that were generally available and out for a while (therefore heavily analyzed), or which they have IP rights for. IDEA, 3DES, Blowfish, RC4, RC5, etc. 3DES and Blowfish being the most popular for open source and free projects, as they are both free of IP entanglements.

The AES process is relatively new. The five finalists have only been out there for a couple of years, and only been finalists for about a year and a half. Fortunatly, with the third AES conference behind us, and the winner due to be selected and announced within a couple of months, we will be returning to the days of DES, a common standard which everyone is free to use, with lots of implementations available.

Also, with the AES finalists, the IP entanglements weren't entirely clear. TwoFish and Rijndael were unentangled from the start, but Serpent had an initial patent filed, but then let the process lapse (so it is now unentangled). MARS and RC6 still have significant entanglements. The winner, of course, will become entanglement free (barring the IP attack scenario), but until then, chosing an AES candidate wasn't any better or worse then picking an older, available algorithm from an IP viewpoint or even from a security viewpoint (as they weren't very heavily analyzed by those other than the developers during the first round, as there were some 30 odd first round candidates).

Fortunatly, the AES winner will probably return us to the DES world: A trusted, entanglement free, well understood, secure algorithm.

• The algorithm has to be free and unencumbered by patents. The ElGamal public key algorithm is an example of an unencumbered algorithm, but it did not become unencumbered until the DH patent expired in 1997. The symmetric key algorithm Blowfish is the first unencumbered post-DES algorithm that people believe is secure, which is why it is so popular.
• The algorithm has to feel secure. This is way people stull use 3DES, even though it is far slower than Blowfish and most of the other new SK algorithms at the block cipher lounge and the AES candidates.
• The algorithm has to, once it meets the above two criteria, be efficient. Blowfish has an inefficient key generation cycle, but is otherwise efficient. Rijndael is the most efficient of the AES candidates.

One thing people can do is use a cryptosystem instead of a single algorithm. This makes implememtation much easier, since people don't need to become familiar with Applied Cryptography and the literature on crypto. This is why people like SSL--it is free outside of the US, and will become free in the US on September 20th, and is a complete system belived to be secure.

One of the nice things about crypto research is that most of the research papers out there are freely available on the internet.

- Sam

I really don't care for their choices at all. A lot of them are more like general approaches than algorthms, and I'm not at all sure they are the most influential. I think they are supposed to be "the cleverest of the common fancy methods"

Simple algorithms for common problems are much more widely used, and have far more impact and influence, but try telling *them* that!

I hope these links help. (Warning: many are technical) If anyone has personal favorites that are less dry than many of these, please post!.

10. 1987: Fast Multipole Method. A breakthrough in dealing with the complexity of n-body calculations, applied in problems ranging from celestial mechanics to protein folding. [Overview] [A math/visual approach]

9. 1977: Integer Relation Detection. A fast method for spotting simple equations satisfied by collections of seemingly unrelated numbers. [Nice article with links]

8. 1965: Fast Fourier Transform. Perhaps the most ubiquitous algorithm in use today, it breaks down waveforms (like sound) into periodic components. Everyone knows this one (or should) [Part II of my personal favorite FFT and wavelet tutorial]

7. 1962: Quicksort Algorithms for Sorting. For the efficient handling of large databases. [Definition][Basic Method][Mathworld][More technical explanation][A lecture with animations and simulations]

6. 1959: QR Algorithm for Computing Eigenvalues. Another crucial matrix operation made swift and practical. [Math] [Algorithm

5. 1957: The Fortran Optimizing Compiler. Turns high-level code into efficient computer-readable code. (pretty much self-explanatory) [History and lots of info]

4. 1951: The Decompositional Approach to Matrix Computations. A suite of techniques for numerical linear algebra. [matrix decomposition theorem] [Strategies]

3. 1950: Krylov Subspace Iteration Method. A technique for rapidly solving the linear equations that abound in scientific computation. [History] [various Krylov subspace iterative methods]

2. 1947: Simplex Method for Linear Programming. An elegant solution to a common problem in planning and decision-making. [English} [Explanation with Java simulator] [An interactive teaching tool

1. 1946: The Metropolis Algorithm for Monte Carlo. Through the use of random processes, this algorithm offers an efficient way to stumble toward answers to problems that are too complicated to solve exactly. [English] [Code and Math] [Math explained]

Dictionary of Algorithms, Data Structures, and Problems is a pretty good "dictionary" of algorithms. Another good place, if you know the name of the algorithm, is of course Google...

"Department Of Defense Trusted Computer System Evaluation Criteria" ("Orange Book"), 12/85
I knew the Orange book was online... if I ever find the others I'll let you know.

Malk-a-mite

One approach is conformance testing. In the USA, this has been done by the National Institute of Standards and Technology, Electronic Data Systems, and other private and government organisations. One problem is that a product can pass the test and also be a bloated, slow and buggy piece of junk.

Besides, all of the major encryption standards were developed in the US, so the EU's decision will not really affect distribution of the well-known algorithms

This would not be complete without mentioning the
Expect extensions to the Tcl language by Don
Libes.

For those of you who are unfamiliar with Expect,
it provides Tcl commands for scripting
interactive processes like telnet, ftp, or other
terminal driven apps. It's standard on most
UNIX installations(man expect).

Nice for webifiying those pecular terminal driven
tasks like telneting in to some machine and
pulling down info to be displayed in an actual
human readable format.

Check out the Expect Home Page. I know there's
a CGI tutorial floating around somewhere but
if you know Tcl it should be pretty obvious

KidSock

True, Linux can never be B1 (or any level) certified itself (neither can NT be C2 certified, contrary to Microsoft's marketing). It can, however be B1 ready, with all the features needed to produce a B1-rated system. Then, VA Linux Systems or Penguin Computing can produce and sell a truly B1 (or C1, for that matter) certified system. That would be a very nice thing to happen.

As for A1, I don't think any modern operating system can reach that level. The proof requirements for A1 certification would be prohibitively expensive for anything but the most scaled down system.

Orange Book criteria are completely obsolete. Read up on Common Criteria

O'Reilly is coming soon (august --supposedely) with a book called Building Linux Clusters.

I think some of you are going to find it quite interesting.

Note that I am working on my PhD thesis in this field of research (specialized in MPI), and we have softwares available at : http://www.itl.nist.gov/div895/savg/auto/ designed to help user work with data-types in MPI.

Please drop me a note at martial.michel@nist.gov if you desire more information on our project (we hope it will be added on the CD-Rom of the O'Reilly book).

O'Reilly is coming soon (august --supposedely) with a book called Building Linux Clusters.

I think some of you are going to find it quite interesting.

Note that I am working on my PhD thesis in this field of research (specialized in MPI), and we have softwares available at : http://www.itl.nist.gov/div895/savg/auto/ designed to help user work with data-types in MPI.

Please drop me a note at martial.michel@nist.gov if you desire more information on our project (we hope it will be added on the CD-Rom of the O'Reilly book).

For more details on this IEC/IEEE/CIPM standard, adopted December 1998, see http://physics.nist.gov/cuu/Units/binary.html

Note that the first syllable of the name of the binary-multiple prefix should be pronounced in the same way as the first syllable of the name of the corresponding SI prefix, and that the second syllable should be pronounced as "bee."

--Neal

Yep, It's being replaced by the common criteria, a joint product of Europe, Canada and the US. It's just been recently standardized into an ISO. These sites should be public:
Common Criteria Project at NIST
Trusted Product Evaluation Program

You can still create 'great technology' like very large scale integration and still space the pins 1/10 of an inch. You might even say that using a more complex system based on the mystical 360 forces you to think more, whereas a simple-minded 'power-of-10' system leads to a flabby, lazy intellect :)) For a short time during the French Rev. they even had a system of TIME based on 10! So why DON'T we have, like 100 seconds/minute, 100 minutes/hour, and maybe 20 hours/day? Then our technology would be even better.

I'd say a lot of US citizens are quite famalier w/ metric, it's taught in schools, all my auto tools are metric (for a VW and a Chevy "Suzuki" Sprint) and having a electrical engr. degree all college work in physics, etc is done in MKS. Also look at the National Institute of Standards and Technology fee schedule and see lots of referances to mm. But yes, roads are still measured in miles, oil in quarts, milk in gallons. It's slowly changing that direction, but what do you expect from a country with 97 year old senators?

NIST agrees with your first link. The issue, as I understand it is that leap seconds replace leap days for finer tweaking.
--

Basically, Java is worse than useless (i.e. it destroys repeatability) for scientific (i.e. repeatability is paramount) applications using Java. Thus, java is doomed to only act as the prettifying visualisation frontend (for which it is quite useful, BTW), rather than the engine of scientific applications. While you may currently say "so what? all scientific apps that are useful are written in C,C++, Fortran 77 or Fortran 90" - remember that some time in the future hardware Java Machines might come about (eg. Crusoe with a Java bytecode translator). With their short-sighted introduction of x86-specific floating point extensions to Java, Sun have destroyed the credibility of hypothetical future hardware JMs as a scientific platform, as well as rendering any numbers from JVMs suspect (that is to say, not necessarily following the same semantics as other parts of your system - this introduces an extra error term into the sigma-d_epsilon error function (or whatever your dimensional analysis/numerical methods lecturer called it), thus potentially producing less trustworthy results than either i)an all native code model or ii)an old-java-fp and native code mixed model or iii)an old-java-fp model). And, the current Java floating point architecture is heinously slow on many processor types...

Exerpt from
math.nist.gov/javan umerics/reports/jgfnwg-01.html#issues

Assiduously implementing Java's current strict floating-point semantics on the x86 using previously published techniques is very expensive, potentially more than an order of magnitude slower than slightly different semantics [Gol]. A less expensive technique developed recently [Gol98] will be discussed later. PEJFPS grants partial access to the double extended floating-point format found on the x86 in order to overcome the speed problem. However, the reckless license to use or not to use double extended granted by PEJFPS destroys Java's predictability (see recent submissions to the numeric-interest mailing list, http://www.validgh.com/java/).

Does this help?

[The exclamation point after 100 is mathematical notation for factorial.]

It is worth noting that malicious, as opposed to merely badly-behaved, hosts, can overload the network by using many different source addresses in their datagrams, thereby impersonating a large number of different hosts and obtaining a larger share of the network bandwidth. This is an attack on the network; it is not likely to happen by accident.

That's the fundamental problem; there's no way in IP to validate source addresses. There's IPsec, which provides cryptographic authentication at the IP level, but nobody uses it yet. This new attack may result in a move to implement IPsec more broadly. This is the proper technical fix.

A related problem is that attacks based on taking over a large number of unsecured hosts and using them as zombies to attack a single site is indistinguishable from heavy load. If the zombies simply make legitimate HTTP requests, the traffic looks completely normal.

An A1 rating of a high-rated system is worth reading. This gives you an idea of what it takes to get it right. At the lower levels, it's easier; Microsoft NT 4.0 with service pack 6A plus a "C2 hotfix set" finally got a C2 rating (the lowest offered), after years of failed attempts. Microsoft had to use the new "outside evaluator" system to do it, rather than having NSA itself do the evaluation. The difference is that NSA only gives you two tries to pass. You can pay an outside evaluator to let you try again and again. NSA allows this at the lowest security level to encourage vendors to try to meet the minimal C2 requirements.

It makes a lot of sense for NSA to fund an effort based on Linux; they'll get something they can run on popular hardware. But some major kernel changes will be needed to get into the B levels. (NSA never had much interest in C-level systems.)

I've been out of that world for a long time now, but from 1978 to 1982 I worked on KSOS, an early NSA-funded attempt to build a secure UNIX-like OS. The original design was done at SRI International, and we at Ford Aerospace implemented it. It eventually worked, but was too slow. It was for PDP-11 machines (0.5 MIPS, 64K address space per process), and was implemented in Modula I, since C was considered unsafe even back then. The combination of an inefficient Modula compiler and a small address space ruined the thing; we had to cut out speed optimizations to make it fit. This was one of the first systems designed against the Orange Book criteria, which, incidentally, started life as Grace Nibaldi's master's thesis.

BSD Unix, incidentally, was viewed as hopeless from a DoD security standpoint. The kernel was far too complicated. A rewrite in Ada was considered in the early 1980s, but rejected. The DoD view at the time was that BSD was a dead end, and Mach was the future. They wanted something at least as secure as Multics, which was a system from the late 1960s rated at B2 in 1985. But that's another story.

An A1 rating of a high-rated system is worth reading. This gives you an idea of what it takes to get it right. At the lower levels, it's easier; Microsoft NT 4.0 with service pack 6A plus a "C2 hotfix set" finally got a C2 rating (the lowest offered), after years of failed attempts. Microsoft had to use the new "outside evaluator" system to do it, rather than having NSA itself do the evaluation. The difference is that NSA only gives you two tries to pass. You can pay an outside evaluator to let you try again and again. NSA allows this at the lowest security level to encourage vendors to try to meet the minimal C2 requirements.

It makes a lot of sense for NSA to fund an effort based on Linux; they'll get something they can run on popular hardware. But some major kernel changes will be needed to get into the B levels. (NSA never had much interest in C-level systems.)

I've been out of that world for a long time now, but from 1978 to 1982 I worked on KSOS, an early NSA-funded attempt to build a secure UNIX-like OS. The original design was done at SRI International, and we at Ford Aerospace implemented it. It eventually worked, but was too slow. It was for PDP-11 machines (0.5 MIPS, 64K address space per process), and was implemented in Modula I, since C was considered unsafe even back then. The combination of an inefficient Modula compiler and a small address space ruined the thing; we had to cut out speed optimizations to make it fit. This was one of the first systems designed against the Orange Book criteria, which, incidentally, started life as Grace Nibaldi's master's thesis.

BSD Unix, incidentally, was viewed as hopeless from a DoD security standpoint. The kernel was far too complicated. A rewrite in Ada was considered in the early 1980s, but rejected. The DoD view at the time was that BSD was a dead end, and Mach was the future. They wanted something at least as secure as Multics, which was a system from the late 1960s rated at B2 in 1985. But that's another story.

You can get them from > National Institute of Standards and Technology (NIST), At least it's a starting point.

I think the AES competition (www.nist.gov/aes), a competition for the replacement of DES by the U.S. government, should finally put a end to the lie that the U.S. has some kind of monopoly on encryption. A full 40% of the finalists were foreign in origin, despite a selection process that was biased for American solutions.

Similarly, while MIT/RSADI hold the U.S. patent on the RSA public key encryption method used in SSH, most modern cryptographers believe that RSA public key encrpytion is obsolete. Most of the work on its proposed replacement, elliptic curve cryptography, is being done in Britain and Canada (in fact, the biggest vendor of elliptic curve cryptography is Canadian).

Don't get me wrong, the U.S. still has many great cryptographers. Bruce Schneier, Ron Rivest, the list goes on. But I seriously doubt that the U.S. still does the majority of public cryptographic research. If you don't believe me, go browse the cryptographic links section on my home page.

-E

Actually, Y2K is correct. You must be thinking of Y2Ki.

In my opinion "The Matrix" was conceived as a trilogy from the beginning, and that means, that the authors created a longer story - and we have seen only the first part of it. Whatever rumors there might be about Wachowski brother thinking about this or that[4], methinks the story is already there, and what we saw in the first part will fit in the second

By the way: I am not a fanatic Matrix advocate - in my opinion, the basic message, the idea and so on have been already described hundreds of times, and in a much deeper way - stories by P.K.D. or Stanislaw Lem[5], for example. However, Matrix was a very good movie - the first one to touch this subject with so much expression, so much esthetics, and so deeply. IMO, of course.

Regards,

January

[1]The Matrix - screenplay

[2]The MATRIX FAQ

[3]Oracle Turing Machine

[4]Matrix 2 rumors

[5]A very good site on Lem

In practical terms, there isn't must difference between B3 & A1, they have the same security setup, but A1 has been formally proven to be secure, while that's not a requirement for B3. However, I'm pretty sure that most B3 systems have been formally proven, just not in the documentation & verbosity to get certified for A1.

Yes, gop."gov" is more of an organization, not a government body, such as noaa.gov, nasa.gov, or nist.gov.

There should be a line drawn between special interests bodies and official government services.

This interval is known as the "Planck time", and has a value of 5.3906 x 10-44 s according to this link.

Skipjack is not a good choice for several reasons:

1. Skipjack only has an 80 bit key. Even 3DES, at 112 bits, is better than that. Last year, Deep Crack broke a DES key in 56 hours, and the machine cost under $250,000. Assuming the government spent an even billion on a similar machine for Skipjack, they could brute force a key in 26 years. This is unacceptable for the truely paranoid. Rijndael, or any of the other AES candidates, has key sizes of 128, 192, and 256 bits. With a 256 bit key, a brute force search would require more energy than could be obtained by converting all the matter in the solar system.
2. Skipjack has a 64 bit blocksize. As long as you're going with a non-standard algorithm, you might as well use one of the AES candidates which all have 128 bit block sizes.
3. Skipjack doesn't seem to have been sufficiently overengineered to inspire confidence. A version of Skipjack reduced from 32 to 31 rounds can be broken slightly faster than through brute force (look here for details). This isn't a fatal weakness by itself, but it doesn't exactly look good either.
4. If you're woried about the government trying to read your mail, then not using an algorithm they came up with (and thus know more about than anyone else) is just plain common sense.

PS: I did an April Fools joke on Congress back in the early 90s involving a fake press release from "UIP" that droned on and on in technocrat-babble about "the national transportation vehicle initiative" whereby the Feds would build this enormous fusion powered truck for "national competitiveness". In it, I portrayed Craig Fields as having nothing but glowing praise for "the public private partnership" from his new position as President of gallium arsenide technology leader, Cray Computer Corporation where he had replaced Seymour Cray who, my fictitious story went, "died in a jeeping accident in the Rocky Mountains". This "joke" was sent to every congressional office years before Seymour Cray died in a jeeping accident in the Rocky Mountains. "Funny" how Cray died shortly after he violated his own historic avoidance of direct architectural service to the spookshops.

In reality, US intelligence isn't all it's cracked up to be, and is a hotbed of bureaucrats and paper pushers. A program on this on NPR revealed that:

* the intelligence head of the Iran division didn't speak Farsi. Most of them didn't.

* nobody had a clue the India nuclear blasts were going to occur, inspite of satellite reconnaissance AND the fact that the ruling party had announced it in their election brochure. Talk about missing a clue.

* Cifford Stoll's book The Cuckoo's Nest details how shocked he was to find govt. agencies spending millions of dollars to design security systems had VERY poor security. In fact, many of them had guest access on! The East German crackers he was tracking were easily able to obtain root access and were roaming free. (Read the book, it's excellent).

I must say that not all of this is the NSA's domain. However, in general the bureaucracy has seeped in so much that many CIA agents complain their performance is mainly judged on such factors as whether they had their oil change done every 3000 miles, filled in time sheets, etc. I don't see why the NSA should be different.

As for having a parking lot full of cars - what do you expect? It's an intelligence agency and they are obviously SUPPOSED to work overnight when it's daytime in the middle east, Russia, and China. This is like assuming an employee is busy if he is sitting in his chair - we all know the big secret about that one.

Oh, and let's not forget the outdated maps when they bombed Belgrade. Frankly, I think Hollywood does these agencies a favor when it portrays them as efficient geniuses.

BTW, I think the computer stuff is handled by the NCSC - National Computer Security center.

From

http://csrc.nist.gov/secplcy/csa_87.txt

"Recently, NSA has been given the responsibility
to establish and maintain technical standards for secure, or
"trusted" computers. NSA does this through its administration of
the Department of Defense (DOD) National Computer Security Center. "

It's a long read, sometimes interesting.

"Skipjack", has now been released and cryptoanalyzed by the public cryptography community. Interestingly, it has been found to have possible exploits at 14 rounds, and has exactly 15 rounds.

Don't listen to people who just make stuff up. Every fourth year is a leap year, every hundredth year is not, and every 400th year is. The algorithm (as documented at the US National Institute of Standards among other places) remains unchanged since the 16th century.

From the round 1 report:
"Serious questions have been raised about HPC (original version) due to a very large number of equivalent keys."

There's a modified version, but HPC is pretty weird and hard to analyze. It's also slow on anything other than 64-bit platforms, so Serpent was chosen instead. CAST-256 has security similar to Serpent, but it's slower and has a higher ROM requirement (not good for smart cards).

Yeah, Rijndael appears to have a good chance at becoming the AES.

Check out NIST's Round 1 Report (PDF) for the raw details if you haven't already.

Of the five that made it to round 2, Mars and RC6 can probably be counted out right away. Mars is too complicated and RC6 doesn't have a large security margin. And both are highly platform-dependant for their speed.

Serpent (one of the non-US ones) will probably be counted out because of it's slow speed, although the high security margin might still save it. One could argue that as CPUs get faster speed becomes a non-issue compared to security. Just look at the popularity of Triple-DES even today.

Rijndael (the other non-US one) and Twofish appear to be the favorites. The report listed no real complaints about Rijndael. Twofish is kinda complicated, but has some space/time tradeoff options that might be worth it for low-memory systems.

Rijndael has a structure that can be parallelized. This could be a very good thing if processing goes that way. Considering that AES is expected to serve for decades, performance on future processors could be very important, though entirely speculative.

Just don't hold your breath. It'll probably be years before we see a winner.

Damn clicking on the wrong button. Here is the URL again and this time clickable.

http://physics.nist.gov/cuu/Units/binary.html

I saw a TEMPEST ELINT FAQ somewhere out there, years ago. Searching...

One overview

And a bit about legality

Mmmmmmm, ELINT.

GMT is out dated. UTC is the more proper convention.

~afniv
"Man könnte froh sein, wenn die Luft so rein wäre wie das Bier"

FWIW, the (NIST) is currently evaluating several candidates for the new Advanced Encryption Standard (AES). This standard will presumably become the officially approved US Gov encryption methodology. One nice thing about this project is that most of the candidates have made their algorithms available for public scrutiny. Furthermore, it appears that there is concern about IP issues (e.g., patents).

This was taken from the AES site:

A process to develop a Federal Information Processing Standard (FIPS) for Advanced Encryption Standard (AES) specifying an Advanced Encryption Algorithm (AEA) has been initiated by NIST. NIST is currently soliciting candidate algorithms for inclusion in the AES. It is intended that the AES will specify an unclassified, publicly-disclosed encryption algorithm available royalty-free worldwide, that is capable of protecting sensitive government information well into the next century. It is also hoped that this standard will be as widely accepted as the Data Encryption Standard (DES) in the private and public sectors.

I looked at one of the algorithms, but it just made my head hurt.:)