Cryptography-Digest Digest #939
Cryptography-Digest Digest #939, Volume #12 Mon, 16 Oct 00 22:13:00 EDT Contents: Actually I want FBI and INS deport me from the U.S.A. to Europe so that I can have more fun (Markku J. Saarelainen) Algorithm Performance ([EMAIL PROTECTED]) Re: Basic skills and equipment... (Tom St Denis) Re: Algorithm Performance (Tom St Denis) Re: Book, "Battle of Wits" ? (John Savard) Re: Is it trivial for NSA to crack these ciphers? (John Savard) Re: gender vs. sex [was Rijndael implementations] (John Savard) Re: Is it trivial for NSA to crack these ciphers? (John Savard) Re: byte != octet [was: Re: Rijndael implementations ] (John Savard) From: Markku J. Saarelainen [EMAIL PROTECTED] Crossposted-To: comp.security Subject: Actually I want FBI and INS deport me from the U.S.A. to Europe so that I can have more fun Date: Mon, 16 Oct 2000 23:15:51 GMT I talked with one person today and expressed my opinions. A person said maybe they do not want your type of people here in the U.S.A. This person was also an immigrant (recently moved from Canada to the U.S.A.) I responded: "Yes, after the years of U.S. spying and U.S. government intelligence (economic etc.) activities against you, you change - against the innocent person, me, without any cause - ... etc. and when your wife is stolen away from you as the first step your deportation one must conclude that the U.S.A. is not worthy place for living." - I am not afraid of death and dying. Indeed I concluded already many years ago that I do not want to live in the U.S.A. (well already in 1996), but four years after I am still here. I indeed want the FBI, INS and other U.S. government agencies to deport me. After all I was 21 when I first time came here in total peace and what I found was the misery. Indeed, the FBI and U.S. government has to get to the U.S.A. more people like Capt. Fernandez who is currently living in Miami and actively participated murders and killings of close to 100 political prisoners (throats of some of these people were brutally cut). One of the happiest days of my life shall be when I leave this country .. and I prefer the deportation, because the U.S. government does not want me here ... so take me back to Finland - I love this greatly. But I shall promise to you I shall remember all events and experiences that I have gone through since 1989 here in the U.S.A. and act accordingly in Finland. I love you! When you have watched to the eye of death, one is not afraid of dying. Sent via Deja.com http://www.deja.com/ Before you buy. -- From: [EMAIL PROTECTED] Subject: Algorithm Performance Date: Tue, 17 Oct 2000 00:00:30 GMT I was curious if anyone had a quick and easy application to measure the speed of crypto algorithms. That way if I wanted to test Seal and RC4, or perhaps an rsa signature vs. a DSA signature. I would greatly appreciate any help. -Jeff Sent via Deja.com http://www.deja.com/ Before you buy. -- From: Tom St Denis [EMAIL PROTECTED] Subject: Re: Basic skills and equipment... Date: Tue, 17 Oct 2000 00:21:44 GMT In article [EMAIL PROTECTED], John Myre [EMAIL PROTECTED] wrote: Tom St Denis wrote: snip You are STILL EVADING the question that was ASKED. The poster asked a very specific question. He didn't ask "how can I get an elementary intro to crypto?" He did ask "what math background is required?" Then you should have told the poster to use sci.math or alt.math instead. His post is irrevelant and off topic. snip Tom, are you trolling or are you really as stupid as that sounds? Hold on, is this sci.crypt? What the heck does "number theory studies" have todo with sci.crypt that it can't belong to sci.math? Honestly... you wanna talk crypto related math stick with sci.crypt. You want to talk pure-hard-core math goto another group. Tom Sent via Deja.com http://www.deja.com/ Before you buy. -- From: Tom St Denis [EMAIL PROTECTED] Subject: Re: Algorithm Performance Date: Tue, 17 Oct 2000 00:20:11 GMT In article 8sg4qr$djd$[EMAIL PROTECTED], [EMAIL PROTECTED] wrote: I was curious if anyone had a quick and easy application to measure the speed of crypto algorithms. A very not-so-super-accurate method is to run it for a few million itterations and count the clock ticks. If for example you output a million bytes from RC4 in five seconds... well you know you're going at about 200,000 bytes a second. If you want to get very technical (often a big waste of time) you could get out the "good 'ol processor manual" and count cycles... but often "30 cycles" on a i586 is "10 cycles" on a K6-2 or "12 cycles" on a MII 300, or ... This means that cycle counts are often taken out of context. (very often in fact). So
Cryptography-Digest Digest #939
Cryptography-Digest Digest #939, Volume #9 Mon, 26 Jul 99 16:13:04 EDT Contents: Re: RSA public key (DJohn37050) Re: hush mail (Anton Stiglic) Re: The Gnu Privacy Guard ? (SCOTT19U.ZIP_GUY) Re: RSA public key (DJohn37050) Re: I wonder why he wrote it that way. (Jacques Guy) Re: RSA public key (Patrick Juola) Re: Advances in Cryptology 1981--1997 (Francois Grieu) XOR now explained on web site! (John Savard) Re: RSA public key (DJohn37050) Re: OTP export controlled? (Jim Gillogly) Re: another news article on Kryptos (Jim Gillogly) sorry :) ([EMAIL PROTECTED]) Re: What I think is B.S. about the X.509 . Please encrypt the certificate! (Matthias Bruestle) Re: What I think is B.S. about the X.509 . Please encrypt the certificate! ([EMAIL PROTECTED]) Re: message digest problem? (John Savard) From: [EMAIL PROTECTED] (DJohn37050) Subject: Re: RSA public key Date: 26 Jul 1999 14:16:03 GMT This is the "chilling" flaw in a random number generator. With RSA, there is a grey area where it is hard to detect such an error. For example, FIPS 140-1 specifies some RNG tests. It is possible to pass those tests, but generate RSA keys that are insecure as they share a prime. Don Johnson -- From: Anton Stiglic [EMAIL PROTECTED] Crossposted-To: alt.security.pgp,alt.privacy,alt.security.keydist Subject: Re: hush mail Date: Mon, 26 Jul 1999 10:59:53 -0400 fungus wrote: Anton Stiglic wrote: 128 bit is equivalent to 16 ASCII caracters, it's a bit better then an 8 ASCII caracter password on UNIX, but still In what way a "bit better"??? I'd say that squaring the attack time is more than "a bit better". Yes, you are correct, brute force attack on the passwords would be most likely impossible for the time beeing (sorry for any confusion, always happy to see how posters jump on someone if say something wrong ;).But brute force attack on the passwords is not the solution here, the initial secret is a passphrase, wich is transformed into a password, wich is hashed to something we will call h.Finaly, a _part_ of h is taken for validation. The hash function used is SHA, wich produces a 160 bit message digest. I don't know how big a part of that they take, depending on the size they take, brute force on that could (or could not) be directly applied. There may also exist other loop holes, using this technic, wich can be broken with something more intelligent than brute force. Anton -- From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) Subject: Re: The Gnu Privacy Guard ? Date: Mon, 26 Jul 1999 16:07:19 GMT In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: --9736BD3942835C87E94A0987 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hey all... What do you all think of the Gnu Privacy Guard, also known as GPG ? It is intended to be a freeware version of pgp sponsored by the Free Software Foundation as part of the GNU system. You can check out this web page for more information. Any input regarding the quality of this would be very appreciative. http://www.gnupg.org Well Spike I took a very quick look at it. I like the concept of a GNU group working on a public key encryption. But if I am not mistaken it still uses CFB mode encryption and still in the first few blocks incorparates a method so users can tell imediately that they have the wrong session key. Those features seem to be fixed as they where in the early PGP. I can't say about later PGP since it is no longer DOS. But I feel these two features may make the task of the NSA types several orders of magnitude easier. Again I am talking about the actual encryption that gets used on the data. There really are not many options for the public key part. I guess we just have to hope there is no easy break in them. However I for one would like to see more chaining modes. I would even like to see the possiblity of a wrapped PCBC type of chaining and would like to see an option to drop the quick session key check which can only weaken the over all system. Thanks for sharing the news about GPG. David A. Scott -- SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE http://www.jim.com/jamesd/Kong/scott19u.zip http://members.xoom.com/ecil/index.htm NOTE EMAIL address is for SPAMERS -- From: [EMAIL PROTECTED] (DJohn37050) Subject: Re: RSA public key Date: 26 Jul 1999 16:07:23 GMT The point is that an RNG can pass FIPS 140-1 tests and generate RSA keys that can be broken. Testing RNG is hard. With crypto, one wants assurance that things are going right, not just that one cannot see anything wrong. An RNG might be "chilled" due to a spec of dirt on a mask, for example, in manufacturing. If it outright fails,
Cryptography-Digest Digest #939
Cryptography-Digest Digest #939, Volume #8 Wed, 20 Jan 99 23:13:03 EST Contents: Random numbers for C: End, at last? (George Marsaglia) Re: Metaphysics Of Randomness (R. Knauer) Re: General (but detailed enough) description of RC4... (Doug Stell) Re: Pentium III... (Brad Aisa) Re: Java speed vs 'C' (was Re: New Twofish Source Code Available) ([EMAIL PROTECTED]) Crossposted-To: sci.stat.math,sci.math,sci.math.num-analysis,sci.physics.research,comp.os.msdos.djgpp From: George Marsaglia [EMAIL PROTECTED] Subject: Random numbers for C: End, at last? Date: Thu, 21 Jan 1999 03:08:52 GMT My offer of RNG's for C was an invitation to dance; I did not expect the Tarantella. I hope this post will stop the music, or at least slow it to a stately dance for language chauvinists and software police---under a different heading. In response to a number of requests for good RNG's in C, and mindful of the desirability of having a variety of methods readily available, I offered several. They were implemented as in-line functions using the #define feature of C. Numerous responses have led to improvements; the result is the listing below, with comments describing the generators. I thank all the experts who contributed suggestions, either directly to me or as part of the numerous threads. It seems necessary to use a (circular) table in order to get extremely long periods for some RNG's. Each new number is some combination of the previous r numbers, kept in the circular table. The circular table has to keep at least the last r, but possible more than r, numbers. For speed, an 8-bit index seems best for accessing members of the table---at least for Fortran, where an 8-bit integer is readily available via integer*1, and arithmetic on the index is automatically mod 256 (least-absolute-residue). Having little experience with C, I got out my little (but BIG) Kernighan and Ritchie book to see if there were an 8-bit integer type. I found none, but I did find char and unsigned char: one byte. Furthemore, KR said arithmetic on characters was ok. That, and a study of the #define examples, led me to propose #define's for in-line generators LFIB4 and SWB, with monster periods. But it turned out that char arithmetic jumps "out of character", other than for simple cases such as c++ or c+=1. So, for safety, the index arithmetic below is kept in character by the UC definition. Another improvement on the original version takes advantage of the comma operator, which, to my chagrin, I had not seen in KR. It is there, but only with an example of (expression,expression). From the advice of contributors, I found that the comma operator allows (expression,...,expression,expression) with the last expression determining the value. That makes it much easier to create in-line functions via #define (see SHR3, LFIB4, SWB and FIB below). The improved #define's are listed below, with a function to initialize the table and a main program that calls each of the in-line functions one million times and then compares the result to what I got with a DOS version of gcc. That main program can serve as a test to see if your system produces the same results as mine. _ |If you run the program below, your output| | should be seven lines, each a 0 (zero).| - Some readers of the threads are not much interested in the philosophical aspects of computer languages, but want to know: what is the use of this stuff? Here are simple examples of the use of the in-line functions: Include the #define's in your program, with the accompanying static variable declarations, and a procedure, such as the example, for initializing the static variable (seeds) and the table. Then any one of those in-line functions, inserted in a C expression, will provide a random 32-bit integer, or a random float if UNI or VNI is used. For example, KISS255; would provide a random byte, while 5.+2.*UNI; would provide a random real (float) from 5 to 7. Or 1+MWC%10; would provide the proverbial "take a number from 1 to 10", (but with not quite, but virtually, equal probabilities). More generally, something such as 1+KISS%n; would provide a practical uniform random choice from 1 to n, if n is not too big. A key point is: a wide variety of very fast, high- quality, easy-to-use RNG's are available by means of the nine in-line functions below, used individually or in combination. The comments after the main test program describe the generators. These descriptions are much as in the first post, for those who missed them. Some of the generators (KISS, MWC, LFIB4) seem to pass all tests of randomness, particularly the DIEHARD battery of tests, and combining virtually any two or more of them should provide fast, reliable, long period generators. (CONG or FIB alone and CONG+FIB ar
