December 2003 - cypherpunks-legacy

Info about Linux
by jya＠pipeline.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Responding to msg by crawford(a)scruznet.com (Michael D. Crawford) on Sat, 3 Dec 1:4 AM Thanks for this Linux info. FWIW, PC Mag's John Dvorak plugs Linux and Yggdrasil in the December 20 issue. He says, "there's no excuse not to have Linux as a primary or alternative operating system ... highly recommended, bargain of the year." - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLuCI6SoZzwIn1bdtAQGzsAF/bDaj0dXzETyOkhL+qN+EfJYumWR6Oocj m4drVaoXQBnuEmQMM4UfOwcTt6tqsr/a =saEy -----END PGP SIGNATURE-----

1 0

Re: First Virtual?
by Andrew Lowenstern 17 Dec '03

17 Dec '03

Mark Terka writes: > Ok, so what are our options, given that this company seems to think > of security in terms of a plastic padlock. From corresponding posts > on the list, the only other alternative, Digicash, doesn't seem to > be too responsive to anyone's participation right now. It seems to me that DigiCash mistakenly 'jumped the gun' and announced before they were truly ready to test. This is such a common ocurrance in the computer industry that I'm suprised people are making noise over it. However, it indicates their reluctance to ship something before it's ready, which is good considering the technical and political challenges of the task they are undertaking. How can you really compare the proposed DigiCash systems versus FirstVirtual? One is a 'toy' system for moving credit card numbers around without actually broadcasting them in the clear, the other is a cryptographically secure digital cash type system. It's not suprising that FirstVirtual is ready sooner than DigiCash. However, assuming each system was ready and working as advertised, which would you trust for your financial transactions? With the possibility of millions and billions of dollars of commerce ocurring on the net in the near future, which do you think most people will want to use? While FirstVirtual may have it's place in the world of online payment systems, it is IMHO no replacement for a real digital cash system. The fact that most of the people who have even heard of these new payment systems are unaware of the not so subtle differences should alarm most cypherpunks. Digital cash isn't going to happen overnight (although most of us would like it to), and the last thing we want is for systems like FirstVirtual to become the de facto standard for online payment... andrew

3 2

Re: Brands excluded from digicash beta
by Paul Dinnissen 17 Dec '03

17 Dec '03

Hi, We're sorry to hear any complaints about the handling of any requests for information regarding ecash. As you can understand, we are certaintly not planning to create unsatisied ecash users at the very start of the ecash endeavour. So at least we are happy to hear from you so we can act appropriately. DigiCash has the ambitious goal to make the ecash client software available on virtually every OS platform and/or system. Alas, our programmers crew is not that extensive that we're able to release everything at once, we has to resort to a phased release approach. For some insight in the release history of the sundry ecash versions, we refer to our WEB server pages. With this background we answer your questions and remarks, at the hand of some of quote orginating form your mail to DigiCash. > Hal said: > > I just figured that I didn't have enough clout for them to bother to > > respond to me, but today on the www-buyinfo list, Stefan Brands, who > > many think has the best ecash technology available today, posted that he > > had had the same experience! Brands himself has still not been given > > an opportunity to join the beta test. He did not sound very happy about > > this. As announced, the ecash-trial starts in phases. Currently we are completing most versions of ecash. We receive quite a lot of good feedback from the first releases. Therefore we decided to change the user-interface to get better software that is easier to use, before confronting the user of the next releases with problems already solved! We decided to first to select tester from our own timezone to facilitate easy voice communication in case extensive support issues. Contrary to our expectations we encountered relatively few problems, so we can soon release also the beta-test to tester in the remaining time zones. So as you can see our release policy is not that staight forward and involves a lot of considerations like usability and acceptance. This is one of the main reasons why Mr. S. Brands HAS received his beta-test version friday the 11th of November, together with all his collegues at the CWI. They all run Silicon Graphics International OS and before that date this version wasn't finished. > I was in the same boat-- I sent in several requests, all of which were > ignored. After Digicash issued a call for prototype shops, I signed > up. WHAM. I immediately started getting mail asking when I'd have my > shop ready-- sometimes two or three messages a day. > > Once I got everything up and running, I didn't hear further from them. Sometimes we can react very fast, but alas this is only the case for standard procedures which we did automate. More specific questions and requests *have* to be handled by humans. We think the people who are willing to invest quite some effort in setting up a shop for the beta test, are very important participants in the beta test trail. Therefore it seems *very* unlike to us that we didn't respond to *any* mail or request from you. Not trusting our own memory ( we do receive more than 100 (yes, hundred) mails on ecash *each* day, even Sundays) we dove right in to it and found a trail of DigiCash answers to your mail with the subject: 'Concerns about ecash'. > Since then, an accident on my WWW server has rendered the e-shop > inoperable. I've asked Digicash, in the form of Paul Diniessen, for > help reconstructing the bank records. No go. Sorry we *did* sent you a respons within an hour from your request by my colleague Branko. He is responsible for our bank in the trial. His respons was: -The dbm library used by Linux and FreeBSD are different, so the ecash -databases are also incompatible. If you have a password for getting an -initial balance, you can also use this password for reopening your -account (and keeping your old balance). For the server(a)fairgate.com -account you can use the password ******** (pw made invisible PD) for this. - -Branko > > Of course, it may well be a matter of incompetence rather than insult, > > but the net result is the same. The more I see of digicash's lack of > > consideration towards their potential customers and important figures like > > Brands the more I question whether they have the potential to succeed. > > The more I deal with Digicash, the better First Virtual looks. My > technical preference is for using Brands or Chaum cash; at present, > though, there aren't any shipping Brands servers, and the Digicash > folks don't seem to be able to get all their socks in one bag. We feel somewhat troubled by these comments. We strongly feel that the alleged 'lack of consideration' as unjustified. First we would like to split up your comment in to two different issues, first regarding our potential customers and secondly the issue of Mr. S. Brands. As we mentioned before we deem *all* our users, in the past, now, and in the future, as important whether it concerns "shops" or mere "customers" they all contribute to a successful new payment medium. We like you to consider this phase in the existence of ecash as a genuin beta trail. In beta test not only software is being trailed but the supporting services too! However, it should be noted that we did respond to your mail and requests. On the issue on Mr. S. Brands. As we explained before no way we even considered to exclude Mr. Brands for the beta test. As of the technical appreciation of the Chaum system as opposed to the Brands system and the alleged scalability issues , we propose you contact Mr. S. Brands and Mr. D. Chaum for details. We will give a call today to check if received this mail. We hope to resolve the problems mentioned above and to continue our co-operation. Kindest regards, Paul Dinnissen DigiCash bv.

8 12

Voice over data
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

Eric Hughes wrote: > the great voice-over-data protocols and products introduced by > Intel, Rockwell, ZyXEL and others at Comdex which will make > Voice-PGP so much easier > > As I understand these voice-over-data products, the voice goes over > analog, added to the modem signal. The modem signal is interpreted, > and then reconstructed and subtracted from the incoming signal, > leaving voice. Very clever, but insufficient for secure phones. I don't think that's how they do it. As far as I know, most methods multiplex digitized audio with the data. One system used by some people in India provides a dynamic combination of fax, (digitized) voice and data, depending on the throughput - eg vox/9.6 data if 14.4kbps, fax as well if 19.2, etc. While Intel and others are proposing standards, ZyXEL does it with software along with a voice card or possibly RJ11 input. A friend of mine saw a demo of it at Comdex, on an old 1496E (16.8 kbps zyxel to zyxel). The new v.34 does 28.8k - lots of room for clear digitized voice and high speed data. This is exactly why I thought it would make secure voice easier, if not secure phones (who wants to lug a modem and PC around as a 'handset'?). I'll be testing some Onetics Rad VFAST modems this week, which apparently do digitized voice over v.34 as well. ----------------------------------------------------------------------------- Rishab Aiyer Ghosh "Clean the air! clean the sky! wash the wind! rishab(a)dxm.ernet.in take stone from stone and wash them..." rishab(a)arbornet.org Voice/Fax/Data +91 11 6853410 Voicemail +91 11 3760335 H 34C Saket, New Delhi 110017, INDIA

2 1

PGP on a VAX
by Mark Rogaski 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I was wondering what the status of getting PGP compiled on a VAX was. The academic machine here is a VAX 6540 running VMS 5.5-1. Of course I avoid it, but I want to spread the good word amongst the IUP student users. Any place I can get documentation? - ----- Doc "I used to think that my brain was the rogaski(a)phobos.lib.iup.edu best part of my body ... but then I http://www.lib.iup.edu/~rogaski/ remembered who was telling me this." 100,000 lemmings can't be wrong! - Emo Phillips finger fllevta(a)oak.grove.iup.edu for PGP Public Key -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLt/FJR0c4/pqJauBAQExfQP/Z1EhLyYw449tTTjYrNNlLRdLA9sA2V+o rpYUgKc0o8yGfEVkERhMH5F40IawXfXkcmVp9Zk+AV8Z7GP2YYpIT8pbFuGSYAYZ HuZXUmYgfmGkzM9uyxV82TyTjh9hQ4Hv7ijwWIPOeROV552WJZYzamJqeBfdi/80 xR13UjkjZs4= =CA+0 -----END PGP SIGNATURE-----

3 2

E-money Good or Bad?
by KDAGUIO＠aba.com 17 Dec '03

17 Dec '03

<Forwarded (from: LIBERTY) by Terry Liberty-Parker using timEd. <Originally from Libernet (Michael Beasley) (1:204/9.0) to All. <Original dated: Nov 26 '94, 20:51 <From: MWBEASLEY(a)delphi.com (Michael Beasley) <To: Libernet(a)Dartmouth.EDU <Date: Sat, 26 Nov 1994 22:56:04 -0500 (EST) <Suggested Reading: E-Money article in December issue of "Wired" <magazine <The article is about the future of electronic money. Electronic <money is coming, with small scale tests in progress now with <more scheduled for next year. There are competing systems out <there - whose ultimate intent is to someday replace entirely <that green paper in your wallet. <The really big question is how much individual privacy will be <retained: < "Can digital cash become anonymous, as real-world money is? < And if so, should it be?" <As you can guess there are two opposing camps on this one: <U.S. Government Agencies AAA .. ZZZ DigiCash Corporation <The American Bankers Association - vs - assorted cypherpunks <Microsoft Corporation assorted privacy advocates <The Borg at least one Libertarian ******************************* Whoa! Much of content of the discussions I had with Mr. Levy concerned the importance of protecting privacy and security for everyone. None of those comments made the cut. Yes, I have concerns about fully anonymous digital cash, but while I am not a full on crypto-anarchist, neither am I a crypto-facist. Let me ask you a question. If people can communicate over the net anonymously, tranmit unreadable messages, and transfer unlimited amounts of fully anonymous money, haven't you, in addition to protecting some of the interests of minorities, also perfected a mechanism by which people with evil intent can engage in criminal activities completely unobserved and with no fear of prosecution? How safe would you feel as an average private citizen, a famous/wealthy citizen, a mail order retailer, a bank, or a leader of a democracy? I have always believed that people won't come outside to play with you unless they feel safe. We want electronic commerce to work everywhere in the world. The following is not flamebait!!! If anyone can adequately address the concerns of all of the above entities I can guarantee you that they will become wealthy fast, if you don't address them all there is a significant risk that you will fail. If you have the answer (and I haven't seen an adequate proposal yet) please let me know and I will spread the word and clear the way. Thanks for listening!...kawika... ****Speaking only for myself and not the ABA.

3 2

Callback phones
by Ben 17 Dec '03

17 Dec '03

I picked this up on the alt.2600 newsgroup. Seems like it could be used for things like privacy enhancement if it was coupled with a credit card/cashier's check that wasn't in your name along with perhaps a call back loop. Ben. Begin Forwarded Article: __________

1 0

Big Brother database
by Brad Dolan 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I'm watching a congressional hearing on C-SPAN about the "Computer Criminal Tracking System." Jim Martin of the National Consortium for Justice Information and Statistics is testifying, describing an FBI database under development. As an example of its intended use, he gave the following example: A hitchhiker could be stopped by police and required to submit fingerprints. These fingerprints could transmitted digitally to obtain instant identification and "criminal history" information about the hitchhiker. Criminal history information would include information from federal, state, and local authorities. Mr. Martin also observed that, while existing Justice Information databases are now used only for law-enforcement, firearms licensing, and "national security purposes," he envisions that the new database could be expanded in its uses to include "non-criminal justice" applications. Why should I have to provide fingerprint identification on demand to cops? What are the "national security" applications of existing databases? Imagine all the potential "non-criminal justice" applications for the new database. What happens when this database gets linked up to the "citizen tracking and employment eligibility" database under construction? Do we then have a de facto (cardless) national ID? I think so. -----BEGIN PGP SIGNATURE----- Version: 2.9.i iAMtyPingInAfakeKeYBecaUSeSomePeoPleOnACErtaINMailiNGLIStarereQU IRinGtheUseoFDiGiTaLSiGNAturES.DoESTHIsMaKEaNYSenSEtoyOU?ItDoESN 'TTOMEsOIAMdoINgTHisInsTEAdblAHBLahbLAHbLahBlAHBlahBlahbLAHBlahb blAHBlahbLAh blAHb -----END PGP SIGNATURE-----

1 0

Re: Big Brother database
by merriman＠metronet.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- The above line is a recycled pgp signature header. Save those bits! > >Mr. Martin also observed that, while existing Justice Information >databases are now used only for law-enforcement, firearms licensing, >and "national security purposes," he envisions that the new >database could be expanded in its uses to include "non-criminal justice" >applications. Oh, hot diggety. >Why should I have to provide fingerprint identification on demand to >cops? 'cause they'll shoot you or toss you in jail if you don't? > >What are the "national security" applications of existing databases? Finding out which spys in the CIA have been deducting payments on their new Jaguars. > >Imagine all the potential "non-criminal justice" applications for the >new database. Child support, vagrancy, alimony, using cash instead of plastic, parking tickets, income taxes, state taxes, municipal taxes, tax taxes, environmental terrorism (remember that tree in your yard you cut down?), jaywalking, having a hole in your sneakers, picking your nose, Un-American activities (ie, disagreeing with the Kongress), Tax Fraud (ie, trying not to give any more your money than you have to to the Tax Gestapo), reading books on the Prohibited Publications List, Violation of National Health Policy (ie, eating junk food, or otherwise placing an 'undue burden' on the National Health Kare System), and any other kind of mopery and dopery they can think up. If you can think of it or do it, they'll make it illegal, immoral, or Socially Irresponsible. > >What happens when this database gets linked up to the "citizen >tracking and employment eligibility" database under construction? grab your ankles. >Do we then have a de facto (cardless) national ID? I think so. You got it, Bunky. -----BEGIN PGP SIGNATURE----- Version: 3.141592654 ThIsIsAfAkEsIgNaTuReBlOcKsOtHaTtHeSiLlYcYpHeRpUnKsReMaIlErAtToAd DoEsNoTtHrOwUp,IfYoUCaNrEaDtHiS,ThEnYoUnEeDtOgOoUtAnDbUyYoUrSeLf SoMeViSiNeToMaKeYoUrEyEsFeElBeTtEr-PlEaSeAcCePtMyApOlOgIeSfOrThE rIdIcUlOuSnAtUrEoFtHiSuSeLeSsBiToFcRyPtO- FlUfF -----END PGP SIGNATURE----- - - - - - - - - - - - - - - - - - - - - - - - - - - Finger merriman(a)fohnix.metronet.com for PGP public key and fingerprint. PGP encrypted Email welcome, encouraged, and preferred. "Those who make peaceful revolution impossible will make violent revolution inevitable." John F. Kennedy

2 1

The Sapphire Stream Cipher
by Michael Paul Johnson 17 Dec '03

17 Dec '03

THE SAPPHIRE STREAM CIPHER The Sapphire Stream Cipher is designed to have the following properties: * Be useful for generation of cryptographic check values as well as protecting message privacy. * Accept a variable length key. * Strong enough to justify _at least_ a 64 bit key for balanced security. * Small enough to be built into other applications with several keys active at once. * Key setup fast enough to support frequent key change operations but slow enough to discourage brute force attack on the key. * Fast enough to not significantly impact file read & write operations on most current platforms. * Portable among common computers and efficient in C, C++, and Pascal. * Byte oriented. * Include both ciphertext and plain text feedback (for both optimal data hiding and value in creation of cryptographic check values). * Acceptable performance as a pure pseudorandom number generator without providing a data stream for encryption or decryption. * Design in a little extra strength where there is doubt about what attacks might be a threat. HISTORY AND RELATED CIPHERS The Sapphire Stream Cipher is very similar to a cipher I started work on in November 1993. It is also similar in some respects to the alledged RC-4 that was posted to sci.crypt recently. Both operate on the principle of a mutating permutation vector. Alledged RC-4 doesn't include any feedback of ciphertext or plain text, however. This makes it more vulnerable to a known plain text attack, and useless for creation of cryptographic check values. On the other hand, alledged RC-4 is faster. The Sapphire Stream Cipher is used in the shareware product Quicrypt, which is available at ftp://ftp.csn.net/mpj/qcrypt10.zip and on the Colorado Catacombs BBS (303-772-1062). There are two versions of Quicrypt: the exportable version (with a session key limited to 32 bits but with strong user keys allowed) and the commercial North American version (with a session key of 128 bits). A variant of the Sapphire Stream Cipher is also used in the shareware program Atbash, which has no weakened exportable version. I don't recall ever reading anything about using a stream cipher like this for the generation of cryptographic check values, but it seems like it should be a fast technique compared to some existing hash functions. OVERVIEW The Sapphire Stream Cipher is based on a state machine. The state consists of 5 index values and a permutation vector. The permutation vector is simply an array containing a permutation of the numbers from 0 through 255. Five of the bytes in the permutation vector are moved to new locations (which may be the same as the old location) for every byte output. The output byte is a nonlinear function of all 5 of the index values and 7 of the bytes in the permutation vector, thus frustrating attempts to solve for the state variables based on past output. On initialization, the index variables are set (somewhat arbitrarily) to 1, 3, 5, 7, and 11. The permutation vector (called the cards array in the source code below) is shuffled based on the user key. This shuffling is done in a way that is designed to minimize the bias in the destinations of the bytes in the array. The biggest advantage in this method is not in the elimination of the bias, per se, but in slowing down the process slightly to make brute force attack more expensive. Eliminating the bias (relative to that exhibited by RC-4) is nice, but this advantage is probably of minimal cryptographic value. KEY SETUP Key setup (illustrated by the function initialize(), below) consists of three parts: 1. Initialize the index variables. 2. Set the permutation vector to a known state (a simple counting sequence). 3. Starting at the end of the vector, swap each element of the permutation vector with an element indexed somewhere from 0 to the current index (chosen by the function keyrand()). The keyrand() function returns a value between 0 and some maximum number based on the user's key, the current state of the permutation vector, and an index running sum called rsum. Note that the length of the key is used in keyrand(), too, so that a key like "abcd" will not result in the same permutation as a key like "abcdabcd". ENCRYPTION Each encryption involves updating the index values, moving (up to) 5 bytes around in the permutation vector, selecting an output byte, and adding the output byte bitwise modulo-2 (exclusive-or) to the plain text byte to produce the cipher text byte. The index values are incremented by different rules. The index called rotor just increases by one (modulo 256) each time. Ratchet increases by the value in the permutation vector pointed to by rotor. Avalanche increases by the value in the permutation vector pointed to by another byte in the permutation vector pointed to by the last cipher text byte. The last plain text and the last cipher text bytes are also kept as index variables. See the function called encrypt(), below for details. PSUEDORANDOM BYTE GENERATION If you want to generate random numbers without encrypting any particular ciphertext, simply encrypt 0. There is still plenty of complexity left in the system to ensure unpredictability (if the key is not known) of the output stream when this simplification is made. DECRYPTION Decryption is the same as encryption, except for the obvious swapping of the assignments to last_plain and last_cipher and the return value. See the function decrypt(), below. C++ SOURCE CODE FRAGMENT The original implimentation of this cipher was in Object Oriented Pascal, but C++ is available for more platforms. /* sapphire.h -- Interface for the Saphire stream cipher. Dedicated to the Public Domain the author and inventor (Michael Paul Johnson). This code comes with no warranty. Use it at your own risk. Ported from the Pascal implementation of the Sapphire Stream Cipher 9 December 1994. unsigned char is assumed to be 8 bits. If it is not, the results of assignments need to be reduced to 8 bits with & 0xFF or % 0x100, whichever is faster. */ class sapphire { // These variables comprise the state of the state machine. unsigned char cards[256]; // A permutation of 0-255. unsigned char rotor, // Index that rotates smoothly ratchet, // Index that moves erratically avalanche, // Index heavily data dependent last_plain, // Last plain text byte last_cipher; // Last cipher text byte // This function is used by initialize(), which is called by the // constructor. unsigned char keyrand(int limit, unsigned char *user_key, unsigned char keysize, unsigned char *rsum, unsigned *keypos); public: sapphire(unsigned char *key = NULL, // Calls initialize if a real unsigned char keysize=0); // key is provided. If none // is provided, call initialize // before encrypt or decrypt. ~sapphire(); // Destroy cipher state information. void initialize(unsigned char *key, // User key is used to set unsigned char keysize); // up state information. unsigned char encrypt(unsigned char b = 0); // Encrypt byte // or get a random byte. unsigned char decrypt(unsigned char b); // Decrypt byte. void burn(void); // Destroy cipher state information. }; /* sapphire.cpp -- the Saphire stream cipher class. Dedicated to the Public Domain the author and inventor: (Michael Paul Johnson). This code comes with no warranty. Use it at your own risk. Ported from the Pascal implementation of the Sapphire Stream Cipher 9 December 1994. */ #include <mem.h> #include "sapphire.h" unsigned char sapphire::keyrand(int limit, unsigned char *user_key, unsigned char keysize, unsigned char *rsum, unsigned *keypos) { unsigned u, // Value from 0 to limit to return. retry_limiter, // No infinite loops allowed. mask; // Select just enough bits. retry_limiter = 0; mask = 1; // Fill mask with enough bits to cover while (mask < limit) // the desired range. mask = (mask << 1) + 1; do { *rsum = cards[*rsum] + user_key[(*keypos)++]; if (*keypos >= keysize) { *keypos = 0; // Recycle the user key. *rsum += keysize; // key "aaaa" != key "aaaaaaaa" } u = mask & *rsum; if (++retry_limiter > 11) u %= limit; // Prevent very rare long loops. } while (u > limit); return u; } void sapphire::initialize(unsigned char *key, unsigned char keysize) { // Key size may be up to 256 bytes. // Pass phrases may be used directly, with longer length // compensating for the low entropy expected in such keys. // Alternatively, shorter keys hashed from a pass phrase or // generated randomly may be used. For random keys, lengths // of from 4 to 16 bytes are recommended, depending on how // secure you want this to be. int i; unsigned char toswap, swaptemp, rsum; unsigned keypos; // Initialize the indices and data dependencies. // Indices are set to different values instead of all 0 // to reduce what is known about the state of the cards // when the first byte is emitted. rotor = 1; ratchet = 3; avalanche = 5; last_plain = 7; last_cipher = 11; // Start with cards all in order, one of each. for (i=0;i<256;i++) cards[i] = i; // Swap the card at each position with some other card. toswap = 0; keypos = 0; // Start with first byte of user key. rsum = 0; for (i=255;i>=0;i--) { toswap = keyrand(i, key, keysize, &rsum, &keypos); swaptemp = cards[i]; cards[i] = cards[toswap]; cards[toswap] = swaptemp; } toswap = swaptemp = rsum = 0; keypos = 0; } sapphire::sapphire(unsigned char *key, unsigned char keysize) { if (key && keysize) initialize(key, keysize); } void sapphire::burn(void) { // Destroy the key and state information in RAM. memset(cards, 0, 256); rotor = ratchet = avalanche = last_plain = last_cipher = 0; } sapphire::~sapphire() { burn(); } unsigned char sapphire::encrypt(unsigned char b) { // Picture a single enigma rotor with 256 positions, rewired // on the fly by card-shuffling. // This cipher is a variant of one invented and written // by Michael Paul Johnson in November, 1993. unsigned char swaptemp; // Shuffle the deck a little more. ratchet += cards[rotor++]; swaptemp = cards[last_cipher]; cards[last_cipher] = cards[ratchet]; cards[ratchet] = cards[last_plain]; cards[last_plain] = cards[rotor]; cards[rotor] = swaptemp; avalanche += cards[swaptemp]; // Output one byte from the state in such a way as to make it // very hard to figure out which one you are looking at. last_cipher = b^cards[cards[(cards[ratchet] + cards[rotor] + cards[last_plain] + cards[last_cipher] + cards[avalanche])&0xFF]]; last_plain = b; return last_cipher; } unsigned char sapphire::decrypt(unsigned char b) { unsigned char swaptemp; // Shuffle the deck a little more. ratchet += cards[rotor++]; swaptemp = cards[last_cipher]; cards[last_cipher] = cards[ratchet]; cards[ratchet] = cards[last_plain]; cards[last_plain] = cards[rotor]; cards[rotor] = swaptemp; avalanche += cards[swaptemp]; // Output one byte from the state in such a way as to make it // very hard to figure out which one you are looking at. last_plain = b^cards[cards[(cards[ratchet] + cards[rotor] + cards[last_plain] + cards[last_cipher] + cards[avalanche])&0xFF]]; last_cipher = b; return last_plain; } GENERATION OF CRYPTOGRAPHIC CHECK VALUES (HASH VALUES) For a fast way to generate a cryptographic check value (also called a hash or message integrity check value) of a message of arbitrary length, simply generate a set of 20 bytes (160 bits) by encrypting zeroes. The output so generated is the cryptographic check value. To generate a cryptographic check value when message integrity is desired but encryption is not (for example, as part of a digital signature process), either use a "standard" key (like four bytes of zero) or simply bypass the "card shuffling" part of the key setup (for even more speed). The plain text is still fed to the encrypt function, but the ciphertext is discarded until the check value is generated. SECURITY ANALYSIS There are several security issues to be considered. Some are easier to analyze than others. The following includes more "hand waving" than mathematical proofs, and looks more like it was written by an engineer than a mathematician. The reader is invited to improve upon or refute the following, as appropriate. KEY LENGTH There are really two kinds of user keys to consider: (1) random binary keys, and (2) pass phrases. Analysis of random binary keys is fairly straight forward. Pass phrases tend to have much less entropy per byte, but the analysis made for random binary keys applies to the entropy in the pass phrase. The length limit of the key (255 bytes) is adequate to allow a pass phrase with enough entropy to be considered strong. To be real generous to a cryptanalyst, assume dedicated Sapphire Stream Cipher cracking hardware. The constant portion of the key scheduling can be done in one cycle. That leaves at least 256 cycles to do the swapping (probably more, because of the intricacies of keyrand(), but we'll ignore that, too, for now). Assume a machine clock of about 256 MegaHertz (fairly generous). That comes to about one key tried per microsecond. On average, you only have to try half of the keys. Also assume that trying the key to see if it works can be pipelined, so that it doesn't add time to the estimate. Based on these assumptions (reasonable for major governments), and rounding to two significant digits, the following key length versus cracking time estimates result: Key length, bits Time to crack ---------------- ------------- 32 35 minutes (exportable in qcrypt) 33 1.2 hours (not exportable in qcrypt) 40 6.4 days 56 1,100 years (kind of like DES's key) 64 290,000 years (good enough for most things) 80 19 billion years (kind of like Skipjack's key) 128 5.4E24 years (good enough for the clinically paranoid) Naturally, the above estimates can vary by several orders of magnitude based on what you assume for attacker's hardware, budget, and motivation. In the range listed above, the probability of spare keys (two keys resulting in the same initial permutation vector) is small enough to ignore. The proof is left to the reader. INTERNAL STATE SPACE For a stream cipher, internal state space should be at least as big as the number of possible keys to be considered strong. The state associated with the permutation vector alone (256!) constitutes overkill. PREDICTABILITY OF THE STATE If you have a history of stream output from initialization (or equivalently, previous known plaintext and ciphertext), then rotor, last_plain, and last_cipher are known to an attacker. The other two index values, flipper and avalanche, cannot be solved for without knowing the contents of parts of the permutation vector that change with each byte encrypted. Solving for the contents of the permutation vector by keeping track of the possible positions of the index variables and possible contents of the permutation vector at each byte position is not possible, since more variables than known values are generated at each iteration. Indeed, fewer index variables and swaps could be used to achieve security, here, if it were not for the hash requirements. CRYPTOGRAPHIC CHECK VALUE The relatively large portion of the state altered with each byte encrypted (relative to alledged RC-4) contributes to a rapid avalanche of generated check values -- probably more than is needed. A single bit change in a message causes a radical change in the check value generated (about half of the bits change). This is one good feature of a cryptographic check value. Another good property of a cryptographic check value is that it is too hard to compute a message that results in a certain check value. In this case, we assume the attacker knows the key and the contents of a message that has the desired check value, and wants to compute a bogus message having the same check value. There are two obvious ways to do this attack. One is to solve for a sequence that will restore the state of the permutation vector and indices back to what it was before the alteration. The other one is the so-called "birthday" attack that is to cryptographic hash functions what brute force is to key search. To generate a sequence that restores the state of the cipher to what it was before the alteration probably requires at least 256 bytes, since the index "rotor" marches steadily on its cycle, one by one. The values to do this cannot easily be computed, due to the nonlinearity of the feedback, so there would probably have to be lots of trial and error involve. In practical applications, this would leave a gaping block of binary garbage in the middle of a document, and would be quite obvious, so this is not a practical attack, even if you could figure out how to do it (and I haven't). If anyone has a method to solve for such a block of data, though, I would be most interested in finding out what it is. Please email me at m.p.johnson(a)ieee.org if you find one. The "birthday" attack just uses the birthday paradox to find a message that has the same check value. With a 20 byte check value, you would have to find at least 80 bits to change in the text such that they wouldn't be noticed (a plausible situation), then try the combinations until one matches. 2 to the 80th power is a big number, so this isn't practical either. If this number isn't big enough, you are free to generate a longer check value with this algorithm. Someone who likes 16 byte keys might prefer 32 byte check values for similar stringth. OTHER HOLES Are there any? Take you best shot and let me know if you see any. I offer no challenge text with this algorithm, but you are free to use it without royalties to me if it is any good. LEGAL STUFF The intention of this document is to share some research results on an informal basis. You may freely use the algorithm and code listed above as far as I'm concerned, as long as you don't sue me for anything, but there may be other restrictions that I am not aware of to your using it. The C++ code fragment above is just intended to illustrate the algorithm being discussed, and is not a complete application. I understand this document to be Constitutionally protected publication, and not a munition, but don't blame me if it explodes or has toxic side effects. ___________________________________________________________ | | |\ /| | | Michael Paul Johnson Colorado Catacombs BBS 303-772-1062 | | \/ |o| | PO Box 1151, Longmont CO 80502-1151 USA Jesus is alive! | | | | / _ | mpj(a)csn.org aka mpj(a)netcom.com m.p.johnson(a)ieee.org | | |||/ /_\ | ftp://ftp.csn.net/mpj/README.MPJ CIS: 71331,2332 | | |||\ ( | ftp://ftp.netcom.com/pub/mp/mpj/README -. --- ----- .... | | ||| \ \_/ | PGPprint=F2 5E A1 C1 A6 CF EF 71 12 1F 91 92 6A ED AE A9 | |___________________________________________________________|

1 0