- cypherpunks-legacy - lists.cpunks.org

Re: (fwd) Going to a Computer Conference? Don't use your real name!
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

[Excerpted from MicroTimes April 18, 1994 Issue #122] I could forgive the crosspost but the story is over four months old! Sheesh, comp.risks must have really gone downhill a lot. You'd expect the editor of something like that to try to keep up to date. CuD is just the same. G

1 0

Re: Windows for Workgroups 3.11
by Mike Markley 17 Dec '03

17 Dec '03

---------- | From: Derek Atkins <warlord(a)MIT.EDU> | To: Andrzej Bursztynski <psee(a)sam.nask.com.pl> | Cc: <cypherpunks(a)toad.com> | Subject: Re: Windows for Workgroups 3.11 | Date: Wednesday, July 06, 1994 7:19AM | | > Just wonder if anyone had a closer look at the "Advanced security" option | > built in the Microsoft Windows for Workgroups 3.11. You can use a soft | > of a public/private key when sending a mail via fax (Class 1) driver | > Micrsoft Fax at Work. The key seems to be quite short and I wonder if that's | > a real secure solution comparing eg. to PGP? | | If it really is public key, and if the keys really are quite short, | then its probably really *not* secure. Remember than a 129-digit | (~425 bit) RSA key was broken in 8 months! A 384-bit RSA key is | therefore not secure! | | -derek | The 129 digit key was broken in 8 calendar months and not 8 CPU months, correct? If so then for most purposes a 129 digit key is more than adequate. If you are faxing a contract to someone then if the deal isn't signed in 8 months the odds are that information about it will leak from a different source than your fax. If I had information that I wanted to be secure for several years than I would consider using many more digits than 129. As to Windows for Workgroups 3.11, I don't know anything about the security features that are included. Mike. ===================================================== Mike Markley <mmarkley(a)microsoft.com> I'm not a Microsoft spokesperson. All opinions expressed here are mine. =====================================================

2 1

Re: (fwd) Re: BSD random() - any good (source included)?
by jamiel＠sybase.com 17 Dec '03

17 Dec '03

At 3:20 PM 07/07/94 -0500, Jim choate wrote 69K of forwards (so far) that I would much rather look at in sci.math or sci.stat.math than in my mailbox, unrequested. Didn't we have a little forwarding talk recently enough for your avarage televangelist viewer to remember it? Kindly cut it out. -j -- "Blah Blah Blah" ___________________________________________________________________ Jamie Lawrence <jamiel(a)sybase.com>

2 1

stream ciphers and realtime communications?
by Jonathan Rochkind 17 Dec '03

17 Dec '03

Well, I finally did my duty and picked up a copy of Applied Cryptography. :) I've only given it a cursory browing so far, but I have a question. When I first saw reference to stream ciphers in the book, I imagined that they would be ideal for realtime encrypted communications, like voice (in cellular phones, perhaps). But after reading further, it appears that stream ciphers aren't being used much in this manner, or much at all. Is this correct? I know that there are plenty of encryption protocols and methods for realtime communications (clipper chip, for one), but do they just use block ciphers with relatively small blocks? (Is the security of such things as RSA and IDEA effected by size of block? There's got to be a minimum block that works; you can't do IDEA on a single byte, or can you?) Can anyone outline what kinds of methods are used for voice encryption and other realtime methods, as contrasted with email and delayed transfer methods?

2 1

No Subject
by trollins＠debbie.telos.com 17 Dec '03

17 Dec '03

On Wed, 6 Jul 1994, Mike Markley wrote: > can't be broken in a reasonable amount of time. I'm interested in what > most of the people on this list would consider a reasonable amount of > time though. NEVER is what I consider a reasonable amount of time. I don't want my secure thoughts broken for public display in my lifetime. Or any of my children's lifetime. Or there children's lifetime. .......... -tom

1 0

Re: MAIL: chained remailing strategy
by an104090＠anon.penet.fi 17 Dec '03

17 Dec '03

I was curious about the pros and cons of anonymous remailers holding and randomly sending outgoing mail. It seems to me that the risk of a third party determining the original sender of an anonymous piece of mail through the use of timestamps is less pressing than the risk presented by the physical storage of that mail on someone's machine for extended periods of time. Of course, with chained remailing, these risks dramatically decrease, but would I rather have the first remailer in a chain storing my mail until midnight or immediately bouncing it to another anonymous remailer? Gedeon Edwards ------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin(a)anon.penet.fi.

1 0

real live Detweiler messages- anyone?
by jamiel＠sybase.com 17 Dec '03

17 Dec '03

I have a writing assignment coming up (nothing to do with much that is talked about on this list), and some example posts by Detweiler could be really handy as references. I have one from a long time ago, but could use some others- anybody save any for posterity? If so, could you forward me a couple of juicy ones? thanks- -j -- "Blah Blah Blah" ___________________________________________________________________ Jamie Lawrence <jamiel(a)sybase.com>

1 0

Tempest: It'll Receed
by kentborg＠world.std.com 17 Dec '03

17 Dec '03

The trends are in our favor. Micros are getting more complicated OS's (a Tempest attack on world.std.com is going to be a mess, I guess) making for more complicated emissions, wimpy batteries and Energy Star stickers will slowly drive down all emissions (why waste the power?), and so many appliances are now emitting from their embedded CPUs--which is another thing that will drive emissions, the FCC. But let's not get cocky: mostly we are sitting ducks for anyone who wants to build a fancy radio, it is only the trend which good. -kb -- Kent Borg +1 (617) 776-6899 kentborg(a)world.std.com kentborg(a)aol.com Proud to claim 31:15 hours of TV viewing so far in 1994!

1 0

No Subject
by eternal!jgostin＠bts.com 17 Dec '03

17 Dec '03

for cypherpunks(a)toad.com From: Jeff Gostin<jgostin(a)eternal.pha.pa.us> Reply-To: jgostin(a)eternal.pha.pa.us Subject:Re: How long is reasonable? To: cypherpunks(a)toad.com Message-ID: <940706151140E9Djgostin(a)eternal.pha.pa.us> Date: Wed, 6 Jul 1994 15:11:40 EST X-Original-Article-From: Mike Markley <mmarkley(a)microsoft.com> X-Mailer: winn v1.00a Mike Markley <mmarkley(a)microsoft.com> writes: > can't be broken in a reasonable amount of time. I'm interested in what > most of the people on this list would consider a reasonable amount of > time though. For me, "reasonable amount of time" translates into "the minimum amount of time neccessary to elapse before the information gained loses its sensitive or critical value." In other words, if I encrypted some rather embarrassing letters that I wanted to keep, but also wanted to keep safe, the "reasonable amount of time" would be as long as it takes for me to die, plus one day. If it's a "state secret", it might be 100 years. --Jeff -- ====== ====== +----------------jgostin(a)eternal.pha.pa.us----------------+ == == | The new, improved, environmentally safe, bigger, better,| == == -= | faster, hypo-allergenic, AND politically correct .sig. | ==== ====== | Now with a new fresh lemon scent! | PGP Key Available +---------------------------------------------------------+

1 0

Re: Please post your article
by schneier＠chinet.chinet.com 17 Dec '03

17 Dec '03

Bruce Schneier 730 Fair Oaks Ave Oak Park, IL 60302 (708) 524-9461 750 words IDEA - THE INTERNATIONAL DATA ENCRYPTION ALGORITHM For the past fifteen years, most of us have relied on the Data Encryption Standard, or DES, for encryption. It's a good algorithm, and very secure against the mid-1970s technology is was designed for. Advances in computing power and new discoveries in cryptanalysis have made the algorithm vulnerable. DES is no longer secure against the world's most powerful adversaries. Cryptographers are looking for alternatives to serve their needs well into the 21st century. IDEA may be the current best choice. IDEA is the International Data Encryption Algorithm, and it was invented in 1991 by James Massey and Xuejia Lai of ETH Zurich in Switzerland. An earlier variant of the algorithm was called PES: Proposed Encryption Standard. After strengthening the algorithm against differential cryptanalysis, they changed its name to IPES, for Improved Proposed Encryption Standard, and then to IDEA. The algorithm is structured along the same general lines of DES. It is an iterated block cipher, with a 64-bit block size and a 128-bit key size. "Iterated" means that the algorithm uses a simple encryption function multiple times. "Block cipher" means that the algorithm encrypts data in blocks: 64 bits of plaintext go in one end, and 64 bits of ciphertext come out the other. And the algorithm accepts a 128-bit key. This means that IDEA can be a plug-in replacement for DES, only with a longer key length. IDEA can be used in all the different modes of operation--electronic codebook, cipher block chaining, output feedback, and cipher feedback-- specified for DES in FIPS PUB 81 or ANSI X3.106. The design philosophy behind IDEA is one of "mixing operations from different algebraic groups." The operations are XOR, modular addition, and modular multiplication. All operations are based on 16-bit words, and hence are efficiently implemented in software. (DES has numerous bit twiddling operations, making it very inefficient in software.) IDEA only has eight iterations, compared with DES's 16, but each IDEA iteration can be thought of as a double DES iteration. IDEA is also faster than DES when implemented in software. IDEA's 128-bit key length over twice that of DES; its key length is even longer than triple-DES. And it is much faster than triple-DES. A brute-force attack against IDEA would have to try 2^128, or 3*10^38, possible keys. Michael Wiener's brute-force DES-cracking machine, which could find a DES key in an average of 3.5 hours would require 10^18 years to break IDEA. A machine a million times faster would still require 10^12, or one trillion, years to break IDEA. Does this mean that IDEA is secure? Is there a more efficient way to break IDEA than brute force? No one knows. IDEA is a very new algorithm. Remember that it took cryptographers fifteen years of studying DES to invent differential cryptanalysis, something that the NSA knew about all along. Who knows what tricks the NSA knows about now that allows them to break IDEA. Maybe they know none. Maybe they know something that we will discover for ourselves around the year 2006. There are no assurances in the cryptography business. Several academic groups have tried to cryptanalyze IDEA with no success. Yet. Several military intelligence agencies have tried to cryptanalyze IDEA; they're not talking about what they found. IDEA is a good-looking algorithm, but it is also a new algorithm. Ten years from now we will all consider it an amazing feat of security or an impressive failure. I would bet on the former, but recognize that it is a bet. The most widespread product that uses IDEA is PGP: Pretty Good Privacy. PGP uses IDEA in cipher feedback mode for data encryption. Several other security companies offer the algorithm as an optional alternative to DES. It is available both in software and as a custom ASIC. Details of the algorithm (with source code) can be found in: X. Lai, J. Massey, and S. Murphy, "Markov Ciphers and Differential Cryptanalysis," Advances in Cryptology-- EUROCRYPT '91 Proceedings, Berlin: Springer-Verlag, 1991, pp. 17-38. B. Schneier, "The IDEA Encryption Algorithm." Dr. Dobbs Journal, Dec 93, pp. 50-56. B. Schneier, Applied Cryptography, New York: John Wiley & Sons, 1994. IDEA is patented in the United States (J.L. Massey and X. Lai, "Device for the Conversion of a Digital Block and the Use of Same," U.S. Patent #5,214,703, 25 May 1993) and in Europe. The patents are held by Ascom-Tech AG. There is no license fee required for noncommercial use. Commercial users interested in licensing the algorithm should contact: Dr. Peter Profos, Ascom Tech AG, Solothurn Lab, Postfach 151, 4502 Solothurn, Switzerland; telephone +41 65 242 885; facsimile +41 65 235 761.

1 0