Cryptography-Digest Digest #728
Cryptography-Digest Digest #728, Volume #11 Sun, 7 May 00 23:13:00 EDT Contents: Re: Is this random? (David Hopwood) Re: Questions about imaginary quadratic orders (David Hopwood) Re: Newbie question about primes (Remco Gerlich) distributed RSA? (Tom St Denis) Re: RC5 question (Scott Contini) Re: GPS encryption turned off (Matthew T. Russotto) Autokey (HerbertYardley) Re: Factoring RSA (Scott Contini) Re: SBOX program using ideas from CA and ST (CAST design) (Terry Ritter) Re: Autokey (Jim Gillogly) Date: Sun, 07 May 2000 05:01:18 +0100 From: David Hopwood <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Subject: Re: Is this random? =BEGIN PGP SIGNED MESSAGE= Benjamin Goldberg wrote: > I've come across a number generator written in java which claims to be > "truly random" number generator (not a PRNG)... Could someone tell me > how accurate (or inaccurate) this claim is? > > public class ThreadYieldGenerator > extends java.util.Random > implements Runnable { > > public static final java.util.Random TYG = > new ThreadYieldGenerator(); > > private Thread generator; > private long time = 1000; Even if you accept the basic idea of counting the number of yields in a specified time, 1000 ms is not long enough. > private int count; > > private ThreadYieldGenerator() { > generator = new Thread(this,"TYG-generator"); > generator.setDaemon(true); > generator.start(); > } > > public synchronized byte getByte() { > try { > generator.join(); > } catch(InterruptedException ie) { > generator.stop(); > } Yuch. This is not at all portable between different Java implementations. Also, Thread.stop() is deprecated, and may be removed from the Java spec in future for security reasons. > int count = this.count; > generator = new Thread(this,"TYG-generator"); > generator.setDaemon(true); > generator.start(); I don't like the way the generator thread is joined and restarted for each byte. Not only is it unnecessarily inefficient, the way this is done makes the quality of the randomness very dependent on the pattern of timing of calls to getByte. > return (byte)count; > } > > public void run() { > if( Thread.currentThread() != generator ) { > try { > Thread.sleep(time); > } catch(InterruptedException ie) { > } > return; > } Using the same class for two different thread types is a really inelegant kludge. > do { > count = 0; > Thread sleeper = new Thread(this,"TYG-sleeper"); > sleeper.setDaemon(true); > sleeper.start(); > while( sleeper.isAlive() ) { > Thread.yield(); > ++count; > } This is not a good way to do a spin counter. The resolution of the count will be severely limited because of the execution time of Thread.yield(). > time = ( time * 55000 / count ) | 1; > } while( count < 33000 ); > } > > private long bitsValue = 0; > private int bitsCount = 0; > public int getInt(int nbits) { > if( nbits > 32 || nbits < 0 ) > return 0; Rather poor handling of unexpected arguments. All in all, I'm not impressed. The default seeding method for java.security.SecureRandom in the standard API does something similar, but does a much better job of it. - -- David Hopwood <[EMAIL PROTECTED]> PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 =BEGIN PGP SIGNATURE= Version: 2.6.3i Charset: noconv iQEVAwUBORTqXTkCAxeYt5gVAQEWqAgAj9WpX75aFsdc/5M6wFqkDm+gy3H+C9Vm ejCfdvQH/3GqtsKRHPG3fJUnuVKN3L6M9sK6cnbSuPbEA6W6hMXlnQBPDw/Pv4lz ZHJFBLToWIWwHfszs2+JcY6Ix/zLcOcX5PPVR7Yeo1xZpzmRA65T5IeKXCGV1seu icNd09fnQHlZG0nhQATOiG6q1GMfn0F2jKBIQvVMWReGxVrknSG73nzaxSJf9g5/ b5spndOhogOmblCj+ETUHdZk4dg2tFaH4LGCE6BKhk9ndBsBYne8GOcydCydyHci 9wwxvYun6sfTyROmOfPgQBj8FwTaISNwLapfcIk1z3QMPng0udubPQ== =U/SG =END PGP SIGNATURE= -- Date: Mon, 08 May 2000 00:37:11 +0100 From: David Hopwood <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Crossposted-To: sci.math Subject: Re: Questions about imaginary quadratic orders =BEGIN PGP SIGNED MESSAGE= Jan-Christoph Puchta wrote: > David Hopwood wrote: > > > Let Delta be a negative integer such that abs(Delta) is prime, and > > Delta is congruent to 1 (mod 4), > > q be a prime integer, > > Delta_q = Delta.q^2, > > Cl(Delta) be the class group of the maximal imaginary quadratic order > > with discriminant Delta, > > Cl(Delta_q) be the class group of the non-maximal imaginary quadratic > > order with discriminant Delta_q.
Cryptography-Digest Digest #727
Cryptography-Digest Digest #727, Volume #11 Sun, 7 May 00 20:13:02 EDT Contents: Re: SBOX using boolean logic (Tom St Denis) RC5 question (Pred.) Re: Fresco transmits my name ("David J. Ruck") Re: An argument for multiple AES winners ("Simon Johnson") Re: Newbie question about primes (S. T. L.) Re: How does PGP passphrase produce the session key ? (Bill Unruh) Re: SSL? ("Simon Johnson") Is there a Commercially Available Tranposition Program (UBCHI2) Re: hardware sboxes (Tim Tyler) Re: RC5 question (Tom St Denis) Re: hardware sboxes (Tom St Denis) Re: How does PGP passphrase produce the session key ? (Clive Jones) Re: zeroknowledge.com and freedom.net - Snake oil? (Robert Guerra) Re: How does PGP passphrase produce the session key ? (Tom St Denis) Re: How does PGP passphrase produce the session key ? ([EMAIL PROTECTED]) Re: RC5 question (Pred.) Re: Fresco transmits my name (was: Spammed after just visiting a site) (Clive Jones) Re: Fresco transmits my name (was: Spammed after just visiting a site) (Clive Jones) sboxgen update (Tom St Denis) Re: RC5 question (Tom St Denis) Re: mod function? (Tom St Denis) Re: Fresco transmits my name (Tim Tyler) From: Tom St Denis <[EMAIL PROTECTED]> Subject: Re: SBOX using boolean logic Date: Sun, 07 May 2000 21:17:29 GMT Mok-Kong Shen wrote: > > Tom St Denis wrote: > > > It appears that my sboxes are not bijective. Now I have a question: Is > > it even possible to make a bijective sbox using just boolean > > expressions? I am pretty sure it is. If so, what conditions must I > > meet (i.e number of variables, etc..). > > I have the impression that you are doing the task in the unfavourable, > if not wrong, direction. You can prescrible the mapping between the > input and output with whatever properties you want. Then there is a > well-established technique called boolean optimization that the circuit > design engineer applies to determine the implementation that is > optimal for production purpose.I believe that, since hardware prices > now have diminished enormously compared to decades ago, it > wouldn't matter much even if the optimization is not carried to the > extreme. In short, you don't have to bother about the circuits. > Otherwise you would lose your attention to the properties you > want to give to your S-boxes. (Compare with the case where an > author of a book worries about how his book will get technically > printed at the printing house!) The purpose of my exercise was to try and make random boolean expressions and test for the properties I wanted... I know now I should have gone from table to expression. Tom -- From: Pred. <[EMAIL PROTECTED]> Subject: RC5 question Date: Sun, 07 May 2000 21:12:45 GMT Hi. I read a paper on RC5 and it states that the key expansion process has a certain degree of onewayness. What does this is mean? Is it or is it not possible to derive the key from the S-table by other means than brute force? The reason I ask is that the paper describes attacks in which the goal is to find the S-table. But the attack is not always good if it's very difficult to get from S to the secret key. This because it's not possible - I think - to figure out the key selection process if you only have the S-table. - Pred Sent via Deja.com http://www.deja.com/ Before you buy. -- Crossposted-To: comp.sys.acorn.misc From: "David J. Ruck" <[EMAIL PROTECTED]> Subject: Re: Fresco transmits my name Date: Sun, 7 May 2000 20:19:36 +0100 In article <[EMAIL PROTECTED]>, Tim Tyler mailto:[EMAIL PROTECTED]> wrote: > In sci.crypt David J. Ruck <[EMAIL PROTECTED]> wrote: > : At any time chip manufacturors can generally produce a very small yeild of > : CPU's running at double or more the normal clock rate [...] but this > : will have no impact what so-ever on key cracking. The sort of things > : the NSA have are hypercubes of 30,000 (possibly a lot more now) general > : processors for brute force cracking, and specialist super computers > : with ALU's optimised for certain algorithm's and mathematical functions > : such as factorisation. > > My understanding is that none of this is remotely likely to help > with a straightforwards search through a 2^128 keyspace. That makes > this particular possibility one of the most /unlikely/ ones, IMO. If you are truely dealing with a 2^128 keyspace, in most cases only 40 bits will be unknown (any US exported encryption software) and that can be broken in a matter of hours by such equipment. As Mark Wooding shows in his post *true* large keys are effectively impossible to break with the current level of technology. That why there are two approaches being tried on each side of the atlantic. The US with its 90% share of the worlds software market has opted for not providing true strong encryption, using a veriety of back do
Cryptography-Digest Digest #726
Cryptography-Digest Digest #726, Volume #11 Sun, 7 May 00 17:13:01 EDT Contents: Re: SBOX program using ideas from CA and ST (CAST design) (Terry Ritter) Re: quantum crypto breakthru? (Diet NSA) Re: How does PGP passphrase produce the session key ? ("Joseph Ashwood") Re: zeroknowledge.com and freedom.net - Snake oil? (David A. Wagner) Re: Increasing bit Entropy (Scott Nelson) Hardware RNG ("Joseph Ashwood") Re: SBOX using boolean logic (Tim Tyler) Compression as decryption (Pred.) Re: The Illusion of Security (Diet NSA) Re: SBOX using boolean logic (Mok-Kong Shen) Re: SBOX program using ideas from CA and ST (CAST design) (Tom St Denis) Re: Hardware RNG (Tom St Denis) Re: How does PGP passphrase produce the session key ? (Tom St Denis) Re: zeroknowledge.com and freedom.net - Snake oil? (Steve) From: [EMAIL PROTECTED] (Terry Ritter) Subject: Re: SBOX program using ideas from CA and ST (CAST design) Date: Sun, 07 May 2000 20:12:02 GMT On Sun, 07 May 2000 15:05:56 GMT, in <[EMAIL PROTECTED]>, in sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote: >Tim Tyler wrote: >> >> WT(F, alpha, beta) >> { >> sum = 0 >> for x = 0 to w >> sum = sum + (-1)^((alpha . x) * (beta . F[x])) >> return sum >> }'' >> >> This looks like no FWT I'm familiar with. > >It's the WT transform from Matsui's linear cryptanalysis. > >I would gladly switch to the FWT (I have seen it mentioned elsewhere) if >I could get some pseudo-code (Sorry Terry I don't have the time to >figure out your javascript program...) Let's see: You don't have time to analyze working and finished code, yet think that others should have time to analyze your non-working code which you will soon change. What is wrong with this picture? Here is the JavaScript for just the FWT taken directly from http://www.io.com/~ritter/JAVASCRP/NONLMEAS.HTM function BitARFWT() { // Hadamard Walsh from sequential data, in-place // transform bit array var block=pair=el1=el2=a=b=0; var stradwid = 1; // distance between pair of elements var blocks = bitARlast; // ASSUMED to be 2**n - 1 while (stradwid != 0) { el1 = 0; blocks >>>= 1; for (block=0; block <= blocks; block++) { el2 = el1 + stradwid; for (pair=0; pair < stradwid; pair++) { a = bitAR[ el1 ]; b = bitAR[ el2 ]; bitAR[ el1 ] = a + b; bitAR[ el2 ] = a - b; el1++; el2++; } el1 = el2; } stradwid = (stradwid + stradwid) & bitARlast; } } That looks fairly C-like to me, except ">>>" which is an unsigned 32-bit right shift of n bits (the parameter). (In JavaScript ">>" is a signed shift.) --- Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM -- Subject: Re: quantum crypto breakthru? From: Diet NSA <[EMAIL PROTECTED]> Date: Sun, 07 May 2000 13:22:32 -0700 In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote: >The basic quantum fact involved here is usually illustrated by >the "two-slit experiment"; [Incidentally, it was Thomas Young who did the first double slit experiment, and he was also the person to make the first breakthrough in deciphering Egyptian hieroglyphics.] For those who are interested, this experiment and an intro to quantum crypto (page 331) are described in Chapter 8 of Singh's "The Code Book" (but don't believe the unqualified or blanket claim that quantum crypto is "absolutely unbreakable"). "If we do not prevent highly classified secrets from being stolen, then how are we going to sell them to the Chinese?" - Madeleine Albright (addressing recent thefts) * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network * The fastest and easiest way to search and participate in Usenet - Free! -- From: "Joseph Ashwood" <[EMAIL PROTECTED]> Subject: Re: How does PGP passphrase produce the session key ? Date: Sun, 7 May 2000 13:15:35 -0700 Crossposted-To: alt.security.pgp,comp.security.pgp.tech Actually (assuming you are using it the "normal" way, instead of checking "conventional encryption"), PGP actually generates a hash of your passphrase, uses that to encrypt your public key, it then uses a rather good random number generator to generate your one time keys that will be transmitted encrypted over the internet. But I believe Tom is right about the padding for use of the hash, it's deterministically filled. Joe "Thierry FALISSARD" <[EMAIL PROTECTED]> wrote in message news:o_hR4.13146$[EMAIL PROTECTED]... > I know the passphrase is hashed to produce the session key > (I am interested here only in conventional encryption). > > If the passphrase is hashed by MD5, the size of th
Cryptography-Digest Digest #725
Cryptography-Digest Digest #725, Volume #11 Sun, 7 May 00 16:13:01 EDT Contents: How does PGP passphrase produce the session key ? ("Thierry FALISSARD") Re: zeroknowledge.com and freedom.net - Snake oil? (Roger) Factoring RSA ([EMAIL PROTECTED]) Re: Fresco transmits my name (was: Spammed after just visiting a site) (Mark Wooding) Re: How does PGP passphrase produce the session key ? (Tom St Denis) Newbie question about primes ("JoeC") Re: Newbie question about primes (Earl K. Nimoy) Re: Joystick as RNG (Sandy Harris) Re: Tempest Attacks with EMF Radiation (Diet NSA) Re: SBOX using boolean logic (Terry Ritter) Re: Fresco transmits my name (was: Spammed after just visiting a site) (James MacDonald) Re: Fresco transmits my name (was: Spammed after just visiting a site) (James MacDonald) Re: Fresco transmits my name (was: Spammed after just visiting a site) (Terry Blunt) Re: Newbie question about primes (Sandy Harris) From: "Thierry FALISSARD" <[EMAIL PROTECTED]> Crossposted-To: alt.security.pgp,comp.security.pgp.tech Subject: How does PGP passphrase produce the session key ? Date: Sun, 7 May 2000 19:48:23 +0200 I know the passphrase is hashed to produce the session key (I am interested here only in conventional encryption). If the passphrase is hashed by MD5, the size of the hash will be 128 bits. If the encryption algorithm is 3DES, 168 bits of key are required. How does PGP create the missing key bits ? -- From: Roger <[EMAIL PROTECTED]> Subject: Re: zeroknowledge.com and freedom.net - Snake oil? Date: Sun, 07 May 2000 10:50:05 -0700 "David A. Wagner" wrote: > In article <[EMAIL PROTECTED]>, Steve <[EMAIL PROTECTED]> wrote: > > And BTW, since the Freedom Network does not use latency or remix > > to muddy the digital trail, traffic analysis can determine who > > any user is, provided that someone with sufficient interest and > > funding cares. > > Care to elaborate? That was not my impression at all. > After all, I thought the whole architecture was based on mixing, > so I'm not sure where your comments are coming from, but I'd be > happy to be educated on what they're doing wrong. They can't do everything. If you are the only one using a particular server and someone monitors that server, then presumably traffic analysis will yield some info. Maybe not very much, but I think it is enough to keep Freedom Net from making absolute claims of anonymity. -- From: [EMAIL PROTECTED] Subject: Factoring RSA Date: Sun, 07 May 2000 17:54:33 GMT I would like to know, given a factoring time ot Ft for an n digit RSA, how to claculate the asymptotic time increment Ft' for n' (n'>n) for the following algorithms: CFRAC GNFS SNFS Thanks Sent via Deja.com http://www.deja.com/ Before you buy. -- From: [EMAIL PROTECTED] (Mark Wooding) Crossposted-To: comp.sys.acorn.misc Subject: Re: Fresco transmits my name (was: Spammed after just visiting a site) Date: 7 May 2000 17:52:32 GMT Rev. James Cort <[EMAIL PROTECTED]> wrote: > In article <[EMAIL PROTECTED]>, Mark Wooding > <[EMAIL PROTECTED]> writes > > > * The symmetric session keys are too short. A space of 2^{128} bits > >can be searched in less than a week given the sort of computing > >power available to the US government. > > IMHO, Most likely possibility. Intel admit to having some *much* faster > processors operating in their labs than anything generally available. > Why shouldn't the government have similar or greater levels of computing > power which *aren't* known about? 2^{128} is a big number. Let's assume, sort of for the sake of argument, that Intel have designed terahertz processors, and for some reason aren't selling them to anyone outside the US government. Let's assume that they can do one key schedule *and* encryption *every* cycle. To keep the numbers nice, let's say that that's 2^{40} encryptions every *second*. Now let's say that they have a million of these things. That's another 2^{20} factor. We're up to 2^{60} keys tested every second. (At this point, we can find 16 DES keys per second.) Hmm. We're still a factor of 2^{68} off where we want to be. Breaking a 128-bit cipher, by brute force, with the computational resources described above (not corrected for Moore's law) will take 2^{68} seconds. That's unfortunate, because 2^{68} seconds is a little over 9 billion years. Which is more than a week, I believe. Let's correct for Moore's law. Let t be the time, in seconds, where 0 is now. Let Y be the number of seconds in a year: Y = 31,557,600. I'll take Moore's law as `speed doubles every 18 months'. If the number of keys-per-second at time t is E(t), then the number of keys-per-second at time t + 3Y/2 is E(t + 3Y/2) = 2 E(t). A little bit of maths shows that E(t) = E(0) k^t works well as a model, where k = 2^
Cryptography-Digest Digest #724
Cryptography-Digest Digest #724, Volume #11 Sun, 7 May 00 13:13:00 EDT Contents: Re: SBOX program using ideas from CA and ST (CAST design) (Tim Tyler) Re: Fresco transmits my name (was: Spammed after just visiting a site) ("David J. Ruck") RSA data (Ragnarok) Re: Increasing bit Entropy (Tim Tyler) Re: Why no civilian GPS anti-spoofing? / proposal (Tony L. Svanstrom) Re: RSA data (Tom St Denis) Re: SBOX program using ideas from CA and ST (CAST design) (Tom St Denis) Re: Fresco transmits my name (Tim Tyler) Re: The Illusion of Security (Tim Tyler) Re: The Illusion of Security (Tim Tyler) hardware sboxes (Tom St Denis) Re: SBOX program using ideas from CA and ST (CAST design) (Tim Tyler) Re: Is this random? ([EMAIL PROTECTED]) Re: SV: cryptographically secure (Gisle Sælensminde) Re: Why no civilian GPS anti-spoofing? / proposal ([EMAIL PROTECTED]) Re: Increasing bit Entropy (Jim Reeds) Re: new Echelon article (Diet NSA) Re: zeroknowledge.com and freedom.net - Snake oil? (David A. Wagner) Re: zeroknowledge.com and freedom.net - Snake oil? (David A. Wagner) Re: zeroknowledge.com and freedom.net - Snake oil? (David A. Wagner) From: Tim Tyler <[EMAIL PROTECTED]> Subject: Re: SBOX program using ideas from CA and ST (CAST design) Reply-To: [EMAIL PROTECTED] Date: Sun, 7 May 2000 14:26:39 GMT Terry Ritter <[EMAIL PROTECTED]> wrote: : sci.crypt Tim Tyler <[EMAIL PROTECTED]> wrote: :>Tom St Denis <[EMAIL PROTECTED]> wrote: [...] :>: In my sboxgen.c (http://www.tomstdenis.com/sboxgen.c) I use a bunch of :>: tables to speed up the WT code. :> :>Be aware that there's the Fast Walsh Transform - which is a bit like a FFT. :> :>Ritter describes this clearly [...] : If he's not using FWT, then apparently I have not made myself very : clear [...] I got this impression some time ago, when it was written: ''[...] my WT is coded like so: WT(F, alpha, beta) { sum = 0 for x = 0 to w sum = sum + (-1)^((alpha . x) * (beta . F[x])) return sum }'' This looks like no FWT I'm familiar with. :> there's a description and algorithm in a book called "Topics in :> Advanced Scientific Computation", by Richard E. Crandall. : The Crandall exposition is just a few pages (pp.167-170) and doesn't : do much for me, but I never know how others take these things. This got cited because it was the only other FWT code I had managed to lay my hands on - rather than because of any great technical merit ;-| -- __ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED] |im |yler The Mandala Centre http://mandala.co.uk/ UART what UEAT. -- Crossposted-To: comp.sys.acorn.misc From: "David J. Ruck" <[EMAIL PROTECTED]> Subject: Re: Fresco transmits my name (was: Spammed after just visiting a site) Date: Sun, 7 May 2000 15:25:13 +0100 In article <[EMAIL PROTECTED]>, Rev. James Cort mailto:[EMAIL PROTECTED]> wrote: > In article <[EMAIL PROTECTED]>, Mark Wooding > > * The symmetric session keys are too short. A space of 2^{128} bits > >can be searched in less than a week given the sort of computing > >power available to the US government. > > IMHO, Most likely possibility. Intel admit to having some *much* faster > processors operating in their labs than anything generally available. > Why shouldn't the government have similar or greater levels of computing > power which *aren't* known about? At any time chip manufacturors can generally produce a very small yeild of CPU's running at double or more the normal clock rate. So in the labs they have 1.5GHz Pentium III's, but this will have no impact what so-ever on key cracking. The sort of things the NSA have are hypercubes of 30,000 (possibly a lot more now) general processors for brute force cracking, and specialist super computers with ALU's optimised for certain algorithm's and mathematical functions such as factorisation. ---druck -- From: Ragnarok <[EMAIL PROTECTED]> Subject: RSA data Date: Sun, 07 May 2000 14:50:20 GMT I understand that any data to be RSA-encrypted/decrypted must be an integer smaller than the RSA modulus chosen. In general, however, one wants to encrypt/decrypt arbitrary strings of bits. Is there a standardized way to do the mapping from arbitrary strings of bits to integers, and back? Or is it perhaps up to each implementor to come up with one that suits their particular architecture best? -- Crossposted-To: sci.crypt.random-numbers From: Tim Tyler <[EMAIL PROTECTED]> Subject: Re: Increasing bit Entropy Reply-To: [EMAIL PROTECTED] Date: Sun, 7 May 2000 14:44:14 GMT In sci.crypt.random-numbers Scott Nelson <[EMAIL PROTECTED]> wrote: : On Sat, 06 May 2000 RavingCow <[EMAIL PROTECTED]> wrote: :>If I have two streams of bits with a entropy of 0.5 bits / bit, how can :>I combine these to increase randomness? : [.
Cryptography-Digest Digest #723
Cryptography-Digest Digest #723, Volume #11 Sun, 7 May 00 09:13:01 EDT Contents: Re: SBOX using boolean logic (Tom St Denis) Re: Why no civilian GPS anti-spoofing? / proposal (R J Carpenter) Re: SBOX using boolean logic (Tim Tyler) Re: SBOX using boolean logic (Tom St Denis) Re: Is this random? (Tim Tyler) Re: SBOX using boolean logic (Tom St Denis) Virtual Unlimited announces secure B2B platform and open source crypto ("Arie Draaijer") Re: Is this random? (Tim Tyler) Re: SBOX using boolean logic (Tim Tyler) Re: Fresco transmits my name (was: Spammed after just visiting a site) ("Rev. James Cort") Re: SBOX using boolean logic (Tom St Denis) Re: Some pencil and paper cyphers ("Mr. Tines") Re: Sunday Times 30/4/2000: "MI5 builds new centre to read e-mails on the net" ("Garry Anderson") From: Tom St Denis <[EMAIL PROTECTED]> Subject: Re: SBOX using boolean logic Date: Sun, 07 May 2000 11:14:36 GMT It appears that my sboxes are not bijective. Now I have a question: Is it even possible to make a bijective sbox using just boolean expressions? I am pretty sure it is. If so, what conditions must I meet (i.e number of variables, etc..). I updated the source code [1] to include the inverse boolean operators as well (just to spice things up). [1] http://www.tomstdenis.com/func.c Tom -- From: R J Carpenter <[EMAIL PROTECTED]> Crossposted-To: sci.geo.satellite-nav Subject: Re: Why no civilian GPS anti-spoofing? / proposal Date: Sun, 07 May 2000 06:16:33 -0700 Reply-To: [EMAIL PROTECTED] Mxsmanic wrote: > > "Paul Rubin" <[EMAIL PROTECTED]> wrote in message > news:8f35o6$o7i$[EMAIL PROTECTED]... > > > I'd like to propose that civilian signals on > > the new carriers have public-key digital signatures, > > signed by the satellites. > > Just what part would you sign, exactly? Public-key encryption is not > appropriate for every application. > > Since mission-critical navigation applications would supplement the > satellite signals with a ground-based signal, spoofing of both would be > no more likely than spoofing of VOR or ILS signals today, even without > encryption. In fact, I don't remember terrorists ever spoofing any kind > of navigation signal at all--have I missed something? And wouldn't spoofing likely affect two planes the same way, and not cause a collision? IIRC, terrorists in Puerto Rico did destroy a VOR some years ago. -- From: Tim Tyler <[EMAIL PROTECTED]> Subject: Re: SBOX using boolean logic Reply-To: [EMAIL PROTECTED] Date: Sun, 7 May 2000 11:23:17 GMT Tom St Denis <[EMAIL PROTECTED]> wrote: : Is it even possible to make a bijective sbox using just boolean : expressions? I am pretty sure it is. Yes - consider what would happen if you only used XOR and NOT as your operators. The result would be disgustingly linear - but it would hard to /avoid/ getting a bijection. -- __ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED] |im |yler The Mandala Centre http://mandala.co.uk/ This tagline no verb. -- From: Tom St Denis <[EMAIL PROTECTED]> Subject: Re: SBOX using boolean logic Date: Sun, 07 May 2000 11:38:10 GMT Tim Tyler wrote: > > Tom St Denis <[EMAIL PROTECTED]> wrote: > > : Is it even possible to make a bijective sbox using just boolean > : expressions? I am pretty sure it is. > > Yes - consider what would happen if you only used XOR and NOT as your > operators. The result would be disgustingly linear - but it would hard > to /avoid/ getting a bijection. So is it just a huge search to find a bijective function then? The way I see it with 4 variables, 4 terms and 6 operators there are e = 4 * 2 * 4! * 6^4 e = 192 * 1296 e = 248832 possible combinations of four functions. So I should expect to find a non-linear bijective one in there somewhere? 1. Should I increase the number of terms to increase the chance of finding one? 2. The number of times an input occurs in the equation should be equal for all inputs right? 3. Has anyone done this before? Tom -- From: Tim Tyler <[EMAIL PROTECTED]> Subject: Re: Is this random? Reply-To: [EMAIL PROTECTED] Date: Sun, 7 May 2000 11:33:18 GMT [EMAIL PROTECTED] wrote: : I'm also curious why the author felt that (int)count returns a random : byte, yet the same integer value requires all that extra mashing : before returning it as a random integer. That's not extra mashing - that looks to me like an attempt to write the next(int nbits) method in java.util.Random - but then giving up and renaming the result getInt(int nbits). Unfortunately this doesn't override what it should do - and clashes with the base class's getInt(int upper_bound) method in JDK >= 1.2 :-( -- __ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED] |im |yler The Mandala Centre http://
Cryptography-Digest Digest #722
Cryptography-Digest Digest #722, Volume #11 Sun, 7 May 00 07:13:00 EDT Contents: Re: Increasing bit Entropy (William Rowden) Re: Unbreakable Superencipherment Rounds ("Joseph Ashwood") Why no civilian GPS anti-spoofing? / proposal (Paul Rubin) Re: KRYPTOS Something new ? ("Douglas A. Gwyn") Re: quantum crypto breakthru? ("Douglas A. Gwyn") Re: The Illusion of Security ("Douglas A. Gwyn") Re: Two basic questions ("Douglas A. Gwyn") Re: Newbie question about generating primes ("Douglas A. Gwyn") Re: Why no civilian GPS anti-spoofing? / proposal ("Mxsmanic") Re: Why no civilian GPS anti-spoofing? / proposal ("Douglas A. Gwyn") Re: Unbreakable Superencipherment Rounds (Mok-Kong Shen) An argument for multiple AES winners (Mok-Kong Shen) Re: Fresco transmits my name (was: Spammed after just visiting a site) (Mark Wooding) Re: AEES Advanced (Paul Schlyter) Re: Increasing bit Entropy ("Mr. Tines") Re: Fresco transmits my name (was: Spammed after just visiting a site) ("Mr. Tines") Re: Is this random? ("Mr. Tines") Re: SV: cryptographically secure ("Mr. Tines") Re: Two basic questions ("Mr. Tines") Re: Sunday Times 30/4/2000: "MI5 builds new centre to read e-mails on the net" ("Neon Bunny") Re: Javascript Private Email (Tom St Denis) From: William Rowden <[EMAIL PROTECTED]> Crossposted-To: sci.crypt.random-numbers Subject: Re: Increasing bit Entropy Date: Sun, 07 May 2000 07:04:09 GMT In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > On Sat, 06 May 2000 RavingCow <[EMAIL PROTECTED]> wrote: [snip] > >Would the entropy go up to > >0.75, or would it be less? > > > In the general case, XOR will work well and produce > a stream of approximately .71 bits/bit, but it might > be more or less if the streams aren't independent and/or > cross-dependant. What is the basis for the estimate of .71 bits/bit? -- -William SPAM filtered; damages claimed for UCE according to RCW19.86 PGP key: http://www.eskimo.com/~rowdenw/pgp/rowdenw.asc until 2000-08-01 Fingerprint: FB4B E2CD 25AF 95E5 ADBB DA28 379D 47DB 599E 0B1A Sent via Deja.com http://www.deja.com/ Before you buy. -- From: "Joseph Ashwood" <[EMAIL PROTECTED]> Subject: Re: Unbreakable Superencipherment Rounds Date: Sat, 6 May 2000 22:46:49 -0700 The problem I see is that there has been little analysis of them in that combination. Since it's not clear what you mean by "1 round" (in some of them, a round can mean either what has become known as a round, or what is commonly called a half round), I can't really go into too many details. But I don't see where it would add a significant amount of security over 3DES applied the same number of times (provided you mean one of the standard definitions of round, see above). It is very possible that with such a concept applied with such small granularity, that one sub-round could undo some security offered by a prior sub-round. The basic security lies in the strength of 3DES. The key schedule would also be exceedingly difficult. Joe "UBCHI2" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]... > There is a way to encrypt communications that make them impregnable to > cryptanalysts theoretically. Can the following sequence be implemented? > > 1) 1 round RC6 > 2) 1 round TwoFish > 3) 1 round Serpent > 4) 1 round Mars > 5) 1 round Rijndael > > Then top off the rounds with a final pass with 3DES. Then I do it again by > randomizing the number of rounds of each and the order of the > superencipherments using SIGABA irregular movement of the algorithms. > > Anyone want to try to get through that? Obviously the speed would be slow, but > for top secret materials, is the security too much? > > > > -- From: [EMAIL PROTECTED] (Paul Rubin) Crossposted-To: sci.geo.satellite-nav Subject: Why no civilian GPS anti-spoofing? / proposal Date: 7 May 2000 07:24:54 GMT The PPS signal has what's called an anti-spoofing system, which actually encrypts the signal. It means that military receivers with the decryption keys can tell whether the signal is being spoofed; it also means that unclassified receivers, without the secret keys, can't receive the PPS signal at all. The civilian signal on the other hand is unencrypted and has no anti-spoofing. This actually scares me, now that a multi-carrier civilian system (L5 etc.) has been announced, and airliner navigation will depend on it. One can imagine a terrorist action sending slightly spoofed GPS signals that cause two planes to crash into each other. It could be done by an unmanned transmitter near an airport. If it was only active for a few minutes and then permanently shut down, chances are that nobody would ever figure out what had happened. I'd like to propose that civilian signals on the new carriers have public-key digital signatures, signed by the s
Cryptography-Digest Digest #721
Cryptography-Digest Digest #721, Volume #11 Sun, 7 May 00 03:13:02 EDT Contents: Re: Two basic questions (Guy Macon) Re: GPS encryption turned off (Paul Rubin) Re: Increasing bit Entropy (Scott Nelson) Re: SBOX program using ideas from CA and ST (CAST design) (Tom St Denis) ECC question ("Haris Domazet") Re: Newbie question about generating primes ("Haris Domazet") zeroknowledge.com and freedom.net - Snake oil? (Guy Macon) Re: ECC question (DJohn37050) SBOX using boolean logic (Tom St Denis) Re: zeroknowledge.com and freedom.net - Snake oil? (Paul Rubin) Re: Crypto Export (Bill Unruh) Re: Wanting to learn cryptography (Sandy Harris) Re: Crypto Export (Bill Unruh) Re: Javascript Private Email (Tom St Denis) Re: AEES Advanced ("Joseph Ashwood") Re: Crypto Export (wtshaw) Re: zeroknowledge.com and freedom.net - Snake oil? (David A Molnar) Re: Javascript Private Email ([EMAIL PROTECTED]) Re: zeroknowledge.com and freedom.net - Snake oil? (Steve) my free music for you (Bruno Furlano) From: [EMAIL PROTECTED] (Guy Macon) Subject: Re: Two basic questions Date: 06 May 2000 21:10:08 EDT In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Mario Kenly) wrote: > >kidwalden <[EMAIL PROTECTED]> wrote: > >>Forgive me, I'm just starting to learn about crypto to keep from >>becoming bored stiff at school. I have two basic questions: >> >>Why don't people just use bad spelling and/or grammer before encrypting >>messages? If my plain text reads "We-uns gonna tack purl harber >>toonite" and I take reasonable trouble to not be consistent in my >>misspellings, it seems like even a simple substitution cipher would >>throw off most machines for a long time. > >You're not the first to think of this strategy. An eminent cryptographer >named David Scott, who sometimes frequents this newsgroup, is an expert in >composing just the sort of cryptanalysis-resistive text you describe. Where such techniques shine is not in making cyphertext harder to decode, but in making it harder to search large amounts of decoded cyphertext for keywords. -- From: [EMAIL PROTECTED] (Paul Rubin) Subject: Re: GPS encryption turned off Date: 7 May 2000 01:58:59 GMT In article <[EMAIL PROTECTED]>, Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote: >Paul Schlyter wrote: > >> >> Also: many GPS receivers (including my own Garmin 12XL) seem to try >> to solve for longitude and latitude more accurately than for altitude. > >I suspect this is because most of us live in the flat parts of the >world. If the receivers had been designed in Nepal, where every >morning the 10-year-old girl climbs down 3000 feet of mountain, fills >a bucket of water, and brings it back for breakfast, the receivers >would concentrate on altitude ;-) GPS altitude is less accurate than longitude/latitude because of the simple geometry of the GPS system. The horizontal position reading is quite accurate because you generally can get signals from satellites in all directions (e.g. in front of you and behind you). However, the vertical reading is less certain, because you can only receive satellite signals from above you, not below you, for obvious reasons. -- From: [EMAIL PROTECTED] (Scott Nelson) Crossposted-To: sci.crypt.random-numbers Subject: Re: Increasing bit Entropy Reply-To: [EMAIL PROTECTED] Date: Sun, 07 May 2000 02:05:04 GMT On Sat, 06 May 2000 RavingCow <[EMAIL PROTECTED]> wrote: >If I have two streams of bits with a entropy of 0.5 bits / bit, how can >I combine these to increase randomness? It depends somewhat on the streams, but the same methods which are used to distill randomness from one stream can be used on two. Probably the best would be to use a large hash. For example, use SHA1 on the concatenation of 160 bits of the first stream and 160 bits of the second. Unless the streams are extremely bizarre, this will produce very close to 1 bit of entropy per bit. >Obviously, XOR would not be a >good choice, but would addition mod. 2 work? Since XOR is identical to addition mod 2, they will have a tendency to work about the same. >Would the entropy go up to >0.75, or would it be less? > In the general case, XOR will work well and produce a stream of approximately .71 bits/bit, but it might be more or less if the streams aren't independent and/or cross-dependant. For example, if the both stream were 0's alternating with an unbiased independent bit, then the XOR of the streams might be 0.5 or 1.0 depending on the phase. Scott Nelson <[EMAIL PROTECTED]> -- From: Tom St Denis <[EMAIL PROTECTED]> Subject: Re: SBOX program using ideas from CA and ST (CAST design) Date: Sun, 07 May 2000 02:12:14 GMT Terry Ritter wrote: > > On Sat, 6 May 2000 21:57:31 GMT, in <[EMAIL PROTECTED]>, in > sci.crypt Tim Tyler <[EMAIL PROTECTED]> wrote: > > >Tom St Denis