December 2003 - cypherpunks-legacy

No Subject
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

> > if the clipper chip passed. what's stopping > > corrupt government people from selling access > > to the encryption to the highest bidders to spy > > on competitors communications. > Nothing. > --Dave. What stops a *corrupt* government from shooting you if you dissent? You have to assume *some* degree of respect of laws or the constitution; the fact is that those in power, *when* in power, could possibly ignore all laws. Obviously, there's no point discussing such situations; obviously however pro- Clipper etc a government may be, it is still very far from any such situation. ----------------------------------------------------------------------- Rishab Aiyer Ghosh "What is civilisation rishab(a)doe.ernet.in, rishab(a)dxm.ernet.in but a ribonucleic Voicemail +91 11 3760335; Vox/Fax/Data 6853410 hangover?" H-34C Saket New Delhi 110017 INDIA -----------------------------------------------------------------------

3 2

Re: The Coming Police State
by geoffw＠nexsys.net 17 Dec '03

17 Dec '03

A VIRUS program and a WORM are two different kinds of programs. THEY ARE NOT EQUIVILENT. For more clarification may I suggest "Compuyter's under Attack" by Denning.

2 1

Re: ID Chips...
by frode＠toaster.SFSU.EDU 17 Dec '03

17 Dec '03

Jim choate <ravage(a)bga.com> writes: > As I understand it there was a proposal to install such chips in children > to prevent kidnapping and such last year in Congress (don't remember if it > was House or Senate). > ... Do you remember who the representative was? (Or does anyone else?) This is good material to make sure the person does not get re-elected! F.

2 1

RE: The Agency Whose Name May Not Be Spoken
by Pat Farrell 17 Dec '03

17 Dec '03

In message Fri, 11 Mar 1994 11:10:15 -0800 (PST), tcmay(a)netcom.com (Timothy C. May) writes: > Makes you wonder what TLAs are still largely unknown to the public. There are probably a fair number of obscure ones. Two that I know aren't often talked about are: DCA - Defense Communications Agency - responsible for DoD communication, MilNet, STU-III encrypted phones, and assorted odds and ends. DIA - Defense Intellegence Agency - DoD's own personal CIA. Pat Pat Farrell Grad Student pfarrell(a)gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include <standard.disclaimer>

3 2

Clipper Cracks Appear
by VACCINIA＠UNCVX1.OIT.UNC.EDU 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Seeing as it is politics week here at cpunks, I have found some interesting comments from our friends at whitehouse.gov. Commentary by John Carey in BusinessWeek Magazine (Big Brother Could Hobble High Tech, 3/24/94 pg. 37) states that: So why is the Whitehouse pushing the retrograde notions? One reason is the Clintonites fear of appearing soft on crime and terrorism. "No one wants the head of the FBI walking around saying: 'I don't have the tools to do my job'" says Bellsouth's Markey. Things aren't entirely bleak. The administration, taken aback by vehement opposition from industry, congress and civil libertarians, is suggesting it may back off. "People are willing to work things out" says White House Staff secretary John D. Podesta, who is involved in technology issues. FBI director Freeh says he's willing to accept higher hurdles to get court appointed surveilence. And there are tantalizing hints that the white house is reconsidering its hard line on the clipper chip. <end> Seems that we are having an effect and cracks are starting to leak compromise from the Gov't. This is, however, just the beginning. A ploy used successfully by many groups (New York city's transit authority are masters at this) is to put forth an outrageous proposal, such as clipper etc. Then they soften the demands so that the opponent becomes disarmed, allowing that which the Gov't had intended to pass all along to go through as a compromise. This cannot be allowed. Time to step up the attack a notch. Write the whitehouse and ask them if they want to go down in history as the presidency that ushered in the era of Big Brother. I know Bill won't read it but someone has to. Keep on your congresscritters (I like that word) and put stuff in your local paper. Arm the populace. Lastly, I think many of you are giving this countries people less credit than they deserve. Many simple men and women founded this country. Try not to be so pompous. Scott G. Morham !The First, Vaccinia(a)uncvx1.oit.unc.edu ! Second PGP Public Keys by Request ! and Third Levels ! of Information Storage and Retrieval !DNA, ! Biological Neural Nets, ! Cyberspace -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLYJyUz2paOMjHHAhAQEbCgP/XobypXWta9OBbOAXePNWY7zznS6HHnxS 4fb7MWKlSjRxe283D2oWV0PnNttMLfAcEOknWT8l9/Z8Ef/RUNMo2vRENToE65If oVoUh/lne+PgVpiyT8+oXc8QSFe+8qWJBNL6L1T5YMpghDYYX7bpCn07dCsUQSIb gFItcKbPp8o= =4HsY -----END PGP SIGNATURE-----

2 1

Block Mixing Transforms
by ritter＠cactus.org 17 Dec '03

17 Dec '03

Ritter Software Engineering 2609 Choctaw Trail Austin, Texas 78745 (512) 892-0494, ritter(a)cactus.org Keyed Balanced Size-Preserving Block Mixing Transforms Terry Ritter March 12, 1994 Introduction Modern block ciphers seek to emulate extremely large substitution tables algorithmically, using complex combinations of various simple internal mechanisms. These internal mechanisms include small substitutions and trivial combinings, but the art and mystery of block cipher design is how to couple these simple and weak operations in ways which produce a strong overall cipher. One apparently new type of mechanism which might be useful in block cipher design would take two blocks in, share data between them, and then produce two generally-different blocks as a result. In particular, this mechanism might be used to mix data to (and from) a pair of substitutions, thus hopefully producing a stronger result than the two substitutions operating separately and independently. In most cases, it would be necessary for the mechanism to have an inverse, and to produce output blocks of the same size as the input. The result would be a mechanism which could be inserted anywhere in the internal data paths common in block-cipher designs. Block Mixing Transforms Consider constructs like this: A B | | v v Mixing Transform | | v v X Y X Y | | v v Inverse Transform | | v v A B Capital letters represent data blocks. Alternately, we can describe the transform, in general, as: X := f1( A, B ); Y := f2( A, B ); A := f3( X, Y ); B := f4( X, Y ); The intent of such a system is to mix two input blocks in a complex yet reversible way. This could provide two advantages: 1) It should make each output bit a function of all the input bits (on average), thus providing a way to expand block size while using smaller block-cipher functions. Hopefully the construct would also defeat attempts to "divide-and-conquer" the smaller functions separately. 2) It could provide a way to connect block-cipher functions in sequence, while eliminating any fixed direct connection between the blocks, such connections being vulnerable to "fix-in-the-middle" attack. A mixing transform is not unlike a "butterfly" section in a fast Fourier transform (FFT) [3]. But the usual FFT operates on complex values which are normally represented in floating-point. When implemented in fixed-point (as needed for mixing data blocks), the normal FFT butterfly expands the range of the input values, thus requiring a larger amount of storage (a larger block size) for the result. Fast Hadamard / Walsh transforms [2] behave similarly. For cryptography, we need transforms which are "size preserving" so that we can perform fixed-size block operations (such as DES) either on the input data or on the transformed results. It was not clear to me that this was going to be possible (at least with equations of practical complexity) until Eli Biham provided some examples of size-preserving mixing transforms: X := A - B; Y := 2A - B; A := Y - X; B := Y - 2X; for n-bit blocks, A, B, X, and Y, and arithmetic mod 2^n. There are actually many such transforms, and Biham has found a generalized form: (-1 1 ) (-w w-1) and (w-1 -1) (w -1) where w is some constant. For example, when w = 2: X := -1*A + 1*B = B - A Y := -2*A + (2-1)*B = B - 2A A := (2-1)*X + -1*Y = X - Y B := 2*X + -1*Y = 2X - Y with the arithmetic mod 2^n. To see inverse, note that A = X - Y = (B - A) - (B - 2A) = A B = 2X - Y = 2(B - A) - (B - 2A) = B These are fixed, linear transformations. If we know the input values, and the transformation, we will also know the output values. Even when the full equation is unknown, the simplicity and linearity of these transforms means that they require special protection in cryptographic applications. Mixing transforms can only be used when both the input and the output values cannot be exposed simultaneously. Alas, the transform mentioned above has a problem: Specifically, the least-significant-bit (lsb); that is, lsb(Y) = lsb(B). This is because the expression B - 2A has shifted A left one bit, leaving the bottom bit of B exposed. This provides a bit of direct correlation between an input value and an output value. This is probably sufficient to support a practical "fix-in-the-middle" attack if the transform is used to isolate two DES operations. Consider these correlation experiments on the above transform with 4-bit blocks: x3 x2 x1 x0 y3 y2 y1 y0 b0 64 64 64 64 64 64 64 128 b1 64 64 64 64 64 64 64 64 b2 64 64 64 64 64 64 64 64 b3 64 64 64 64 64 64 64 64 a0 64 64 64 64 64 64 64 64 a1 64 64 64 64 64 64 64 64 a2 64 64 64 64 64 64 64 64 a3 64 64 64 64 64 64 64 64 This is a 0 -> 0 correlation count. For each possible input value (over both A and B), for each input bit which is zero (somewhere in A and B) and each output bit which is zero (somewhere in X and Y), a count is recorded. The count of 128 means that y0, the lsb of Y, occurs twice as often as expected when the lsb of B is zero. Similarly, 64 64 64 64 64 64 64 0 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 a 0 -> 1 correlation count, shows that no cases exist where the lsb of B is a one and the lsb of Y is a zero. Cryptographic Mixing In [8] I introduced a new type of reversible stream-cipher combiner (the first stream-cipher combiner, which we now call "exclusive-OR" or "mod-2 addition" was described by Vernam [12]). "Combiner" is the traditional cryptographic name for a mixing function. [11,5,1] (Non-reversible combiners are also used, typically to make confusion sequences difficult to penetrate. [e.g., 6]) Combiners and mixing transforms have much in common. Basically, a combiner will look like any other two-input one-output function: A B | | v v Mixing Function | v C C B | | v v Inverse Function | v A The capital letters represent the block size; in a typical stream cipher these are byte values. A is the plaintext, B the confusion stream, C the ciphertext. Note that exactly the same confusion stream is needed to recover the original data; this is the heart of stream-cipher security. There are many two-input functions, but most are not useful as cryptographic data combiners, which must be reversible and must have no correlation between either input and the output. Combiners which do have correlation [e.g., 4] fall to statistical attacks [e.g., 10]. If we see mixing transforms as a matched-set of cryptographic combiners, we can see that correlation is a problem with the example transform. (Biham did have an example of one balanced but non-keyed transform based on rotation and subtraction mod 2^n.) Mixing in Mod-2 Polynomials Since the "weak" exclusive-OR form of combiner has long been available, modern combiner designs are normally intended to be "stronger" and, thus, are more complex. But it is not at all clear that "stronger" is what we need in a mixing transform. Presumably, "strength" can be provided more efficiently by some other function, like DES, or a substitution table. Thus, we may really want a modest-strength extremely-fast mixing solution, and one approach is to consider the well-known field of mod-2 polynomials. In mod-2 arithmetic, addition is the same as subtraction X + Y = X - Y and any value added to itself is zero X + X = 0 so, in general, multiplication cannot be achieved by addition X + X <> 2X (assuming X is non-zero) but is instead achieved by shifting. Then 2X + X = 3X so multiplication is not restricted to binary powers. Of course 3X + X = 2X which just shows that mod-2 arithmetic can be surprising. It is interesting to see just how unusual good mixing transforms are. Consider a first approach X := A + B; Y := A - B; (mod-2, mod-p, where p is some primitive mod-2 polynomial of appropriate degree for the size of the data blocks). While this is a reasonable approach in the integers, in mod-2 polys, A + B = A - B. This means that X = Y, and the two resulting identical blocks cannot possibly carry enough information to provide an inverse transform for two arbitrary input blocks. It does not work. Next consider X := A + B; Y := A + 2B; with inverse operations A := (2X + Y) / 3; B := (X + Y) / 3; (mod-2, mod-p), and the division done by multiplying by the inverse of 3, mod p. (Appropriate inverse equations may not always exist; finding the inverse equations is interesting in itself.) This works. But here X is never affected by p at all, thus producing an extremely regular (and un-keyed) transformation. And the inverse multiplication is, in general, far more expensive than multiplication by a small integer. Finally, consider X := 2A + 3B; Y := 3A + 2B; A := 2X + 3Y; B := 3X + 2Y; Again, operations are mod-2 and mod-p, where p is some primitive mod-2 polynomial of appropriate degree for the data blocks X, Y, A and B. This works, and the transform is a self-inverse. The primitive affects the result in both data blocks. And the multiplications are simple. Correlation experiments conducted as before show a nice, balanced, uncorrelated system: 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 These functions are extremely fast. Addition is a simple exclusive-OR. Multiplication by two is simply a left-shift and a conditional add of the primitive. Multiplication by three is a multiplication by two plus an addition. Keyed Mixing Transforms The mod-2 polynomial transforms depend on having some primitive of the appropriate degree. Different primitives produce different mixing functions, with similar overall performance. This leads to the possibility of keying the transforms by selecting arbitrary primitives. (Some references to primitive-finding algorithms are given in [9].) Rabin gives the number of degree-n primitives as about p^n / n [7]. Thus, for degree 64, we have about 2^64 / 2^6 or about 2^58 primitives. This means that each randomly-selected degree-64 primitive carries about 58 bits of key. Of course, this key can only be effective to the extent that the linear transformation cannot be attacked and the primitive thus deduced. Some Consequences If a single input bit changes on one of the mixing transform input blocks, we can be sure that at least one bit will change in both output blocks. If two input bits change, we can be sure that these bits will not "cancel" each other; changes will still occur in the output blocks. If many input bits are changed, and the transform primitive is known, it is possible to engineer a no-change in one output block (although this is unlikely to happen by chance). Should this be undesirable, it might be made impossible by design (such as ciphering the input blocks before mixing), or by keying the transform (so the necessary bit patterns are unknown). If it becomes possible to define the input to, and what the output must be from a ciphering element, it will be possible to key-search that element independent of other elements, and this is what we hope to avoid. To prevent this it may be necessary to use keyed input and output transforms, or even multiple ciphering levels between transforms. Applications It is crucial to remember that these simple, high-speed, but linear mixing transforms can be said to have "strength" only if the input and output values are never both available. That is, these structures do not by themselves handle "known-plaintext" attack. (Of course, the same could be said for many other simple internal mechanisms used in block cipher construction.) Simple constructs like A B | | v v MixTrans | | v v C D are not likely to be very useful as ciphers by themselves, even if the mixing transformation is keyed and the blocks are large. On the other hand, constructs like A B | p1 | v v v MixTrans | | v v DES1 DES2 | | | p2 | v v v MixTrans | | v v C D are considerably more interesting. Note that this construct ciphers a double-size DES block at single-DES rates. It seems to require keyed mixing transforms. Similarly, A B | | v v DES1 DES2 | | | p | v v v MixTrans | | v v DES3 DES4 | | v v C D will cipher a double-size DES block at double-DES rates, and at least superficially avoids all weakness in the mixing transform by placing strength in each input and output port. This may avoid the need to key the mixing transform. Alternately, A B | k1 | v v | XOR <- DES1-----| | | | k2 | | v v |---- DES2 -> XOR | | | p | v v v Mixing Transform | | | k3 | v v | XOR <- DES3 ----| | | | k4 | | v v |---- DES4 -> XOR | | v v C D also ciphers at double-DES rates. Of course, larger external blocks mean an increase in the number of internal data paths, making various sorts of interconnection configurations possible. Thus A B C D | p1 | | p2 | v v v v v v MixTrans1 MixTrans2 p3 | | p4 | | v v v v v v -Trans3 MixTrans4 Mix- | | | | v v v v DES1 DES2 DES3 DES4 | | | | | p5 | | p6 | v v v v v v MixTrans5 MixTrans6 p7 | | p8 | | v v v v v v -Trans7 MixTrans8 Mix- | | | | v v v v E F G H will cipher quadruple-size DES blocks at single-DES rates, A B C D | | | | v v v v DES1 DES2 DES3 DES4 | | | | | p1 | | p2 | v v v v v v MixTrans1 MixTrans2 p3 | | p4 | | v v v v v v -Trans3 MixTrans4 Mix- | | | | v v v v DES5 DES6 DES7 DES8 | | | | v v v v E F G H will cipher quadruple-size DES blocks at double-DES rates, and A B C D | k1 | | k2 | v v | v v | XOR <- DES1 ----| XOR <- DES2 ----| | | | | | k3 | | k4 | | v v | v v |---- DES3 -> XOR |---- DES4 -> XOR | | | | | | | | | p1 | | p2 | v v v v v v MixingTransform1 MixingTransform2 p3 | | p4 | | v v v v v v -Transform3 MixingTransform4 Mixing- | | | | | k5 | | k6 | v v | | v | XOR <- DES5 ----| XOR <- DES6 ----| | | | | | k7 | | k8 | | v v | v v |---- DES7 -> XOR |---- DES8 -> XOR | | | | v v v v E F G H will also cipher quad-size blocks at double-DES rates. But in each case, four double-level mixing transforms could be replaced by a single double-size mixing transform: A B C D | | p1 | | v v v v v ---------mix1--------- | | | | v v v v DES1 DES2 DES3 DES4 p2 | | | | v v v v v ix2--------- --------m | | | | v v v v E F G H A B C D | | | | v v v v DES1 DES2 DES3 DES4 | | | | | | p | | v v v v v ---------mix---------- | | | | v v v v DES5 DES6 DES7 DES8 | | | | v v v v E F G H A B C D | k1 | | k2 | v v | v v | XOR <- DES1 ----| XOR <- DES2 ----| | | | | | k3 | | k4 | | v v | v v |---- DES3 -> XOR |---- DES4 -> XOR | | | | | | p | | v v v v v ---------------------mix---------------------- | | | | | k5 | | k6 | v v | | v | XOR <- DES5 ----| XOR <- DES6 ----| | | | | | k7 | | k8 | | v v | v v |---- DES7 -> XOR |---- DES8 -> XOR | | | | v v v v E F G H These are new ciphering architectures. Clearly, it is not known how strong these constructs would be. However, this situation can hardly be considered unusual. Other opportunities exist when constructing completely new block ciphers. These might, for example, be based on byte-wide key- permuted substitutions, thus avoiding differential attacks on fixed "optimal" tables. Thus ------------------------------mix------------------------------ --------------mix-------------- --------------mix-------------- ------mix------ ------mix------ ------mix------ ------mix------ --mix-- --mix-- --mix-- --mix-- --mix-- --mix-- --mix-- --mix-- mix mix mix mix mix mix mix mix mix mix mix mix mix mix mix mix S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S mix mix mix mix mix mix mix mix mix mix mix mix mix mix mix mix --mix-- --mix-- --mix-- --mix-- --mix-- --mix-- --mix-- --mix-- ------mix------ ------mix------ ------mix------ ------mix------ --------------mix-------------- --------------mix-------------- ------------------------------mix------------------------------ enciphers 256-bit blocks through 32 keyed 8-bit substitutions by using five levels of input keyed mixing transform and five levels of output keyed mixing transforms of varying size. Clearly, there are a plethora of alternate interconnection possibilities here. For example, the mixing rows could be permuted, different sizes of mixing combined in some rows, the mixing not arranged on 2^n boundaries, etc., etc. Since the mixing transforms are extremely fast, we would expect this 256-bit system to be much faster than 64-bit single-DES. And, S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S mix mix mix mix mix mix mix mix mix mix mix mix mix mix mix mix --mix-- --mix-- --mix-- --mix-- --mix-- --mix-- --mix-- --mix-- ------mix------ ------mix------ ------mix------ ------mix------ --------------mix-------------- --------------mix-------------- ------------------------------mix------------------------------ --------------mix-------------- --------------mix-------------- ------mix------ ------mix------ ------mix------ ------mix------ --mix-- --mix-- --mix-- --mix-- --mix-- --mix-- --mix-- --mix-- mix mix mix mix mix mix mix mix mix mix mix mix mix mix mix mix S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S enciphers 256-bit blocks through 64 keyed 8-bit substitutions by using nine levels of mixing transforms of varying size. With the substitutions all keyed, we can probably avoid keying the mixing transforms. Again, there are a plethora of alternate interconnection possibilities. Summary Practical, high-speed, keyed, balanced, and size-preserving block mixing transforms are introduced for cryptographic service. References [1] Arko, R. 1961. Mechanical Signal Combiner. U.S. Patent 3,159,712. [2] Beauchamp, K. 1984. Applications of Walsh and Related Functions. Academic Press. [3] Brigham, E. 1974. The Fast Fourier Transform. Prentice-Hall. [4] Geffe, P. 1973. How to protect data with ciphers that are really hard to break. Electronics. January 4. 99-101. [5] Kohler, H. 1951. Combining Circuits. U.S. Patent 2,567,214. [6] Massey, J., and R. Rueppel. 1989. Method of, and Apparatus for, Transforming a Digital Data Sequence into an Encoded Form. U.S. Patent 4,797,922. [7] Rabin, M. 1980. Probabilistic Algorithms in Finite Fields. SIAM Journal on Computing. 9(2): 273-280. [8] Ritter, T. 1990. Substitution Cipher with Pseudo-Random Shuffling: The Dynamic Substitution Combiner. Cryptologia. 14(4): 289-303. [9] Ritter, T. 1991. The Efficient Generation of Cryptographic Confusion Sequences. Cryptologia. 15(2): 81-139. [10] Siegenthaler, T. 1985. Decrypting a Class of Stream Ciphers Using Ciphertext Only. IEEE Transactions on Computers. C-34: 81-85. [11] Smith, H. 1950. Combining Circuit. U.S. Patent 2,496,317. [12] Vernam, G. 1919. Secret Signaling System. U.S. Patent 1,310,719. --- Terry Ritter ritter(a)cactus.org (alas, cactus.org dies March 18) ritter(a)io.com (perhaps temporarily)

2 1

brainstorming on cpunks' eve
by Matt Thomlinson 17 Dec '03

17 Dec '03

As is mentioned in tims' latest Rant(tm), I've been working on ideas for creating other cypherpunk services that would be possible to deply to the net. I've come up with a few, but they are of dubious quality. I'm hoping that by posting ideas I know are flawed/of little use that followup disscussion might refine them. We saw a use for remailers -- to gain a certain anonymity not present in cyberspace. How about information drops? How about digital cash drops (alt.cash.drop anyone?) I know digicash isn't the rage, and such a group would probably do zero good for some time, but I'd like to start talking about the ideas. With payments in digicash, you could supply a public key (newly created, of course). After the cash is generated/remitted by the other party, it would be encrypted and posted to the group. Noone could use the cash as it sat there, since they can't unwrap the cash. (I like to think of it as dropping the cash in a sealed envelope). I'm trying to think of both uses and problems this exhibits. Lots of extra "session keys" is the only drawback I see. Other possible net services: random number services, which don't keep logs of the numbers it produces -- have it spit a statistically-correct random stream each time a port is opened? Would this be that useful? Also, one could set up a hashing/signing service, more akin to a time stamp service. Mail would be sent to your service, which would attach the output of 'date' to the bottom of the msg and then +clearsig it. I'm thinking that chains of two or maybe three reliable machines should be used, since all it takes to break this is to change the clock on the machine you're signing with. With a few (>1) machines, it becomes very clear that the message was sent at a certain time. Perhaps this could be used in the future for "Registered Mail" type exchanges, or perhaps as part of a "Digital Notary" system? As for our media coverage, I'm happy with it so far. I'm willing to bet digicash that we'll see _television_ coverage re: clipper in the next few months. EFF, among others, should be working on that; we've already been able to get the word out via newspapers/magazines and radio. I wouldn't be at all suprised to see a blip on 20/20 or maybe a 15-second spot by Tom Jennings & co. before July. And projects! I'm currently in the middle of finals, but I'm looking forward to getting back to work on the things that _really_ matter. I was wondering what people were thinking about putting together a page for WWW? Would it be useful? Would people browsing around look at it and would it be a medium to disseminate info? Maybe divide it up... RSA, DES, IDEA, 3-DES, etc. Clipper, Capstone, Skipjack, Tessera PGP, stego programs available, RIPEM, etc. EFF, CPSR, Cypherpunks---- |media coverage |remailers |stego |voice pgp |clipper projects-FOIAs, bigbro inside, etc. other sources of info: sci.crypt, alt.pgp, alt.whistleblowers, alt. privacy, alt.security. Ideas and suggestions appreciated. mt Matt Thomlinson Say no to the Wiretap Chip! University of Washington, Seattle, Washington. Internet: phantom(a)u.washington.edu phone: (206) 548-9804 PGP 2.2 key available via email or finger phantom(a)hardy.u.washington.edu

6 5

error correction
by Black Unicorn 17 Dec '03

17 Dec '03

That's Sen. Leahy, not Leahey... (Sigh)

1 0

Another vulnerability
by Dave Emery 17 Dec '03

17 Dec '03

With Intel, Hackers Check In When Bugs Check Out By Alexander Wolfe SANTA CLARA, Calif. -- Intel's BIOS Update technology to quickly fix bugs that crop up in its microprocessors without having to recall the chips may contain a Trojan horse -- a hole that could potentially enable hackers to wreak havoc on the company's CPUs -- said a BIOS expert familiar with the technology.However, other industry experts said they believe Intel is staking out a pace-setting position with its bug-busting technology. They give the semiconductor giant kudos for using BIOS Update to reduce the impact of bugs in the face of a verification crisis that makes it increasingly difficult to ensure that microprocessors with tens of millions of transistors are validated and free of flaws. BIOS Update is a hidden feature that can fix bugs in Pentium Pro and Pentium II CPUs by patching the microcode inside the microprocessor. When the processor boots up, the BIOS loads the patches, which are contained in a 2,048-byte-long BIOS Update data block that is supplied by Intel. "The problem is, the BIOS cannot verify whether the BIOS Update data block contains real microcode or not," claimed one BIOS expert, who requested anonymity. "As long as the header and the checksum are okay, the BIOS will load that microcode into the microprocessor. Some hacker could actually wipe out microcode in the CPU. There is nothing that can prevent this." Intel doesn't see such a scenario as a realistic threat, pointing to the fact that the BIOS Update data block is encrypted. "We've spent quite a lot of time thinking about such scenarios to make sure we had sufficient mechanisms in place so you couldn't introduce your own flavor of BIOS Update into the processor," said Ajay Malhortra, a technical marketing manager based here at Intel's microprocessor group. "Not only is the data block containing the microcode patch encrypted, but once the processor examines the header of the BIOS update, there are two levels of encryption in the processor that must occur before it will successfully load the update." But Intel's biggest security feature may lie in keeping the technical details behind its BIOS Update technology a closely guarded secret. "There is no documentation," said Frank Binns, an architect in Intel's microprocessor group. "It's not as if you can get an Intel 'Red Book' with this stuff written down. It's actually in the heads of less than 10 people in the whole of Intel." However, some experts remain unconvinced. "This is just like any other technology -- if you want to reverse-engineer it, you can," said Ed Curry, president of Lone Star Evaluation Laboratories, a Georgetown, Texas microprocessor benchmarking and testing company. "You can do it by brute force, or a hacker could obtain information from someone inside the company or someone who had access to the documentation." Indeed, Curry, who said he's made presentations on computer-security issues to the U.S. Defense Department, said he believes microprocessor hardware in general is much more vulnerable to hacking than is commonly believed. "This is the big hole in our government security programs," he said. "They don't look at hardware as well as they should; they only look at software. This goes beyond desktop computers. You have to remember that microprocessors are now embedded in our weapons systems." Nevertheless, it's widely believed that it would be tough for a hacker to fake a complete microcode patch, in no small measure because it's also very difficult to obtain documentation that details the internal representation -- word widths and usage of all the bits -- of Pentium Pro microcode. In the era of the 8086 and 8088, microcode documentation was readily available. But such information is provided to selected developers only under tight nondisclosure restrictions. "It's a tightly held secret," Intel's Binns said. New-Tech Jitters However, it is seen as more feasible for a hacker to successfully fake the header and checksum portion of the BIOS Update data block -- something that could still cause the microprocessor to crash or lock up. According to another BIOS expert, talk of potential Trojan horses might be nothing more than jitters about new technology. "This is a new thing in the market," said the expert, who likened it to the early days of flash BIOS. "There was a great fear factor when the industry started using flash BIOSes," he said, "where concerns were raised that somebody could go in and destroy a system by flashing in a new BIOS containing an errant piece of code. I think today there's a fear that someone will play around with this BIOS Update feature and try to cause havoc with Intel's CPUs." As an added security precaution, some BIOS manufacturers limit access to their software. "As a matter of policy, we don't make our BIOS code available to anyone other than a system vendor or motherboard manufacturer," said Thomas Benoit, corporate marketing manager at BIOS vendor Phoenix Technologies, Natick, Mass. "We don't believe anyone should be twiddling the bits in our BIOS code." Irrespective of Trojan horse scenarios, many experts see Intel's bug-busting technology as a boon. "This feature benefits everyone -- it shouldn't be viewed as a liability, but as an asset," said Mark Huffman, marketing manager at American Megatrends, in Norcross, Ga. "It allows you to be able to update your processor without pulling it out of the system. Obviously, you can flash in a new BIOS a lot quicker than you can pop the case, pop the CPU and wait for a replacement." Indeed, BIOS Update has already been successfully used in the field to fix glitches in Pentium Pro-class CPUs, according to an Intel spokesman and to sources at several major BIOS vendors. "Yes, it is used," said an engineer at one vendor. "I personally know of five different things in the Pentium Pro related to multiprocessing, system management interrupt and other areas." "I think it'll be very useful," Phoenix Technology's Benoit said. "It's really to Intel's benefit that BIOS vendors are implementing this feature." "It's a very good feature," said Laurent Gharda, vice president of marketing at BIOS vendor Award Software International, in Mountain View, Calif. "The downside is going to be lower performance, perhaps. But the upside is avoiding a chip recall, as took place a few years ago." Intel's Pentium was recalled in January 1995 following the revelation of a bug in the processor's floating-point divide operations. Moreover, some say BIOS Update may signal the start of an industrywide trend. "These new Pentium-class clone CPUs that have recently been announced -- like the Centaur microprocessor -- they're going to do the same type of process," said Huffman at American Megatrends. Centaur -- officially the IDT-C6 -- is made by Centaur Technology, an Austin, Texas-based subsidiary of Integrated Device Technology. It was introduced in May and delivered to beta customers in Taiwan last month. At Centaur, a spokesman said, "The current silicon we are sampling has that capability, but in the production version of the chip we are dropping the feature, because it necessitates an increased die size." As a result, any bugs that crop up will have to be fixed via a mask revision -- a path the spokesman described as preferable. "Ideally, you want to do fixes by mask changes," he said. "That way, you'll have clean silicon moving forward. Otherwise, you have lots of different versions of BIOS floating around." But Centaur can easily add the feature back into future versions, if it wishes. For its part, Advanced Micro Devices of Sunnyvale, Calif., does not have the feature in its K5 and K6 microprocessors, according to a company spokesman. "There are some errata that can't be fixed by a BIOS update -- specifically, a hardwired instruction can't be changed." He added that AMD has the ability to add the feature into future designs, if it deems it necessary. Still, Huffman of American Megatrends thinks the BIOS Update feature has legs. "I think you'll see a trend toward CPU manufacturers incorporating this capability so they can perform microcode updates in the field," he said. "It gives them more flexibility in their manufacturing process -- they can keep their fab lines running and don't have to stop them to make a mask change and switch to a new stepping every time there's an erratum. More important, they don't have to recall the stepping that has the bug. They can just issue a BIOS update." Intel doesn't tell the BIOS vendors what bugs are being fixed in any given BIOS Update. However, there appears to be a way to figure that out. "It's true you can't see what's happening from a binary standpoint," the BIOS expert who requested anonymity said. "But Intel does release errata along with the update, which gives an explanation of what the update is for. To that extent, you know what they're fixing, though you don't know the exact binary details of what's occurring." Although the BIOS Update feature is firmly in place in the Pentium Pro and Pentium II families, Intel declined to comment on whether it is being used in Pentiums with the MMX multimedia extensions. Looking ahead, deciding whether to implement the technology in future CPU families will involve architectural considerations that extend far beyond a desire to bust bugs. "We're just learning the power this technology really has," Intel's Malhortra said. "In concert with that, we're also becoming more aware of some of its limitations. For example, the trade-off between die size that's used for microcode-patchable space [i.e., for the BIOS Update feature] vs. die size that can be devoted to performance enhancements or to additional micro-architectural features is a tough one." Validation Boost "One could make the argument that, with improved validation processes, you won't need to expand silicon real estate devoted to the microcode-patch feature, because early validation would catch the bulk of problems," Malhortra added. Nevertheless, there's a growing concern that microprocessor bugs could become a bigger problem as 64-bit CPU architectures -- which will be orders of magnitude more difficult to validate than current designs -- are introduced toward the end of the decade. "It's becoming abundantly clear that the ability to manufacture in high volume and to provide a reliable product through validation are somewhat mutually exclusive," Intel's Binns said. "It takes a fairly large amount of time to wring all the errata out of a processor. Fixing errata by making changes to silicon is OK, if you can make those changes quickly. Unfortunately, with the complexity of the processors we've got today, that's not acceptable. The smarter we can get with features like this, the less errata we bring to market. And if we do see errata after we ship, we can correct them in situ." ----- End of forwarded message from Richard Crisp -----

1 0

Re: CLIPPER COMPROMIZED?
by Peter Wayner 17 Dec '03

17 Dec '03

Is the story that Ames sent the secret of the Clipper Chips to Moscow unlikely? Well, yes. There are no escrow agents because there aren't any keys yet. Plus, it is unlikely that the specific design got to him. But Dorothy characterizes the entire rumor as absurd and I don't think that this is the case. It seems entirely plausible to me that someone in Ames position could severely compromise the Clipper system. Why? Someone in Ames position would presumably need access to Clipper encrypted calls to conduct counter-intelligence operations. Remember some of the first customers will be the DOJ, a good place to put a mole. So if someone in Ames wanted a Clipper key, he could probably ask the escrow agents for it and get it, no questions asked. Dorothy uses arguments like Ames wouldn't have a "Need to Know." This really isn't a strong point. Ames is accused of being a spy. Spies, by definition, circumvent "need to know" requirements. I believe that they found some documents in Ames possession that he was not authorized to hold. The specific rumor is probably false, but I think that the Ames case is a perfect proof of what will almost certainly go wrong with the Clipper system. Someone will rat. History has shown time and time again that three can keep a secret if two are dead. Me and the two Clipper Agencies make three.

1 0