December 2003 - cypherpunks-legacy

Niacin warning (was Surveillance cameras)
by Hal 17 Dec '03

17 Dec '03

From: rarachel(a)prism.poly.edu (Arsen Ray Arachelian) > you can also just pop a 400mg Niacin capsule... Niacin will > quickly dialate all your capilaries bringing lots of blood > to your face and making you look like a lobster. > > That should mess up any scan... so if you're a wanted > crook in an airport that uses ir-face biometrics, just > pop niacins like them were pop-corn. :-) I just want to warn anyone who is thinking of trying this that 400 mg is not the place to start with niacin. The flushing will be extremely intense at that level and you will probably either think you are dying or wish you were. Try 50 or 100 mg to start with. You do build up a tolerance to this effect of niacin pretty fast so experienced users will need higher doses to get the flushing. But for a non-user lower doses are adequate. Hal

2 1

No Subject
by qjones＠infi.net 17 Dec '03

17 Dec '03

Why not beam a time-delayed virus into one of NSA's arrays, destruct code armed and ready to go?? wayne -- **************************************************************************** * Qjones(a)infi.net So I'm a dog...what else is new? * * Qjones(a)larry.wyvern.com Quote from life and times of a man * ****************************************************************************

4 3

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