Cryptography-Digest Digest #15, Volume #12 Tue, 13 Jun 00 04:13:01 EDT
Contents:
Re: Multiple encryptions (zapzing)
Re: SBOX finder client (tomstd)
Re: Finding prime numbers (S. T. L.)
Re: Finding prime numbers (Jerry Coffin)
Re: Cryptographic voting (Greg)
Re: Finding prime numbers ("Joseph Ashwood")
randomness tests - more specific ([EMAIL PROTECTED])
Re: Is Gretchen down? (Tommy the Terrorist)
Re: a couple of qutions on 3DES (dexMilano)
Re: Session key transmission (Mok-Kong Shen)
Re: Large S-Boxes (Mok-Kong Shen)
Re: Multiple encryptions (Mok-Kong Shen)
Re: SBOX finder client (Runu Knips)
Re: And the search is on! (Runu Knips)
Re: Interesting Magazine Article (Mike, Copperhead) (Mok-Kong Shen)
Re: My lastest paper on Block Ciphers (Runu Knips)
Re: SBOX finder client (Runu Knips)
Re: Is Gretchen down? (Stray Cat)
----------------------------------------------------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Multiple encryptions
Date: Tue, 13 Jun 2000 04:44:38 GMT
In article <8hp1vd$ja4$[EMAIL PROTECTED]>,
AllanW <[EMAIL PROTECTED]> wrote:
> We have some encryption program E, and we use it whenever
> we send messages to each other. E is meant to take any
> plaintext (even non-printable data) and encrypt it, to
> transmit it safely to other sites. E identifies the
> encrypted data with a brief cleartext message at the
> start of it's output, to allow the decryption engine to
> avoid trying to decrypt data that never was encrypted.
> Therefore, anyone that can intercept our messages already
> knows we use encryption program E.
>
> Secretly, we also have another encryption program D. It
> isn't public knowledge, but what we really do is take our
> data files and encrypt them with D. Then we take the D
> output and feed that into E. Programs D and E know
> nothing of each other; each is meant to be used as a
> stand-alone encryption engine. D also appends some
> cleartext at the beginning of it's output, but of course
> E encrypts that so our use of D is *mostly* a secret.
(snip)
I hope the cleartest you append to D's output is not
a standardized header. That *could* make your
scheme weaker by making a brute force attack on
E possible with just two ciphertexts (or even one,
if the standardized header is known or easily
guessed).
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: SBOX finder client
From: tomstd <[EMAIL PROTECTED]>
Date: Mon, 12 Jun 2000 21:50:04 -0700
In article <[EMAIL PROTECTED]>, tomstd
<[EMAIL PROTECTED]> wrote:
>You can get a rudimentary copy of the sbox finder GUI client
>thingy at
>
>http://tomstdenis.com/sf.html
>
>It doesn't use TCP/IP to send the packets (since there will be
>barely any at all if any). It will dump the data to
>your "C:\windows\desktop" directory (if windows is not in that
>directory please make both directories).
>
>Sorry there is no other ports at this time (I know somebody is
>gonna comment). However the FULL source code is given and it's
>a very dirty hack of SBOXGEN anyways..
>
>Please give it a try, and if you decide to run the program on
>your machine let me know. I will document all the people
>running it on my webpage.
>
>If you have problems using it let me know.
>
>Tom
Some more info. It takes about 256kb of ram (mainly stack
space) and runs at THREAD_PRIORITY_IDLE so it doesn't get in the
way.
With a few apps open (including Winamp) I get about 10500
sboxes/sec (tested) which is up from the original source which
ran at 5000/sec.
For some reason it doesn't work on Win2k...
Tom
* 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: [EMAIL PROTECTED] (S. T. L.)
Subject: Re: Finding prime numbers
Date: 13 Jun 2000 05:41:42 GMT
<<Suppose I had an algorithm so that, given a prime number P(n),
I could find the next prime number P(n+1) extremely quickly.
Let's say it was as quick as four or five integer additions.
(I don't actually have such an algorithm, but let's say I did.)>>
Finding prime numbers is not a bottleneck in factoring. Nor is it really
useful in modern factoring methods, if I remember correctly.
-*---*-------
S.T.L. My Quotations Page at *** http://quote.cjb.net *** is being
REORGANIZED. Comments are welcome. *392* quotations and growing!
Now playing: Half-Life Now learning: C programming (Hello, World!)
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Finding prime numbers
Date: Mon, 12 Jun 2000 23:43:11 -0600
In article <8i3v16$uo4$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> Suppose I had an algorithm so that, given a prime number P(n),
> I could find the next prime number P(n+1) extremely quickly.
> Let's say it was as quick as four or five integer additions.
> (I don't actually have such an algorithm, but let's say I did.)
I can't think of a way in which it would make any real difference at
all. Using Miller-Rabin, one could walk through the numbers and
fairly quickly find those that are almost certainly prime. Even if
this could be done as a single operation, it wouldn't make any real
difference though: in the range used for RSA, there are just too many
possible numbers for any approach based on anything like trial
division to be useful. Reducing the amount of time to find the
individual primes, and eliminating that (tiny) number of
possibilities Miller-Rabin might say are prime but aren't won't make
any real difference to this at all.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Cryptographic voting
Date: Tue, 13 Jun 2000 05:54:10 GMT
> > Tyranny is kept at bay by guns and will. Our government
> > knows we have the guns, but they don't know if we have
> > the will. Nor do we.
> > The only lawful gun law on the books- the second amendment.
>
> Personally I think cryptography works better than
> guns. for a gun to work you first must know
> *who* to shoot. Then you have to be there with
> your gun, get him before he gets you ...
> All very messy.
But the tyrant with a gun can stop you from using your PC.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Finding prime numbers
Date: Mon, 12 Jun 2000 23:08:23 -0700
Well it would speed up some methods, but I don't think it
would provide an increase over the current best. Assuming a
1024-bit key with factors known to be 512-bits each, there
should be ~10^150 primes of value less than 2^513, subtract
the ones that are smaller than 2^512, we can estimate the
number of primes at still around 10^150, the actual value
being 255*2^512/261632. So even if the time was reduced to 1
clock for the prime finding, trial division would take
approximately 2^200+ attempts, that would still be 10^43
years on a 1 GHz computer. I'm sorry but it's still not
enough alone. A much more important goal would be to reduce
the necessary number of primes, or simply find a better way
than primes.
Joe
"AllanW" <[EMAIL PROTECTED]> wrote in message
news:8i3v16$uo4$[EMAIL PROTECTED]...
> Suppose I had an algorithm so that, given a prime number
P(n),
> I could find the next prime number P(n+1) extremely
quickly.
> Let's say it was as quick as four or five integer
additions.
> (I don't actually have such an algorithm, but let's say I
did.)
>
> I'm guessing that an algorithm like this would make
brute-force
> attacks on private keys easier. Given a public key it
would be
> possible to derive the private key in a practical amount
of
> time, unless people started using much bigger keys than
they
> normally do now. And of course once the attacker had the
> private key they could use it any way they wished.
>
> Is that right?
>
> --
> [EMAIL PROTECTED] is a "Spam Magnet," never read.
> Please reply in newsgroups only, sorry.
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: randomness tests - more specific
Date: Tue, 13 Jun 2000 06:52:55 GMT
>
> Diehard and ent are completely useless. Why? Because the only
> usefull test is specific to *what* you want to use the prng for.
>
> If you want to pick five cards randomly for poker, then test to
> make sure your prng has a good random dsitribution of cards. If
> you want to pick 0/1 answers make sure it's not serially
> correlated or biased...
>
> But performing DNA/OPSQ/Sphere/Etc.. tests are meaningless if
> you can't interpret their results in a manner related to your
> use of the prng.
>
> Tom
>
that's just the point i was thinking ...
so let me tell the situation more precisely :
say that i have a entropy collector function, getting entropy from the
system and forming a pool.
And i want to generate 1024 bit - 2048 bit random data to generate
my keys ...
i do check the entropy of it, but what are the other possible tests
which i must perform to test the output (from hash function or from a
PRNG)?
thanks ....
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tommy the Terrorist <[EMAIL PROTECTED]>
Crossposted-To:
alt.security.pgp,comp.security.firewalls,alt.privacy.anon-server,alt.privacy
Subject: Re: Is Gretchen down?
Date: Tue, 13 Jun 2000 01:48:56 -0500
In article <[EMAIL PROTECTED]>,
Stray Cat <[EMAIL PROTECTED]> wrote:
> >is it?
> No, but it is slow today.
Do these time delayed remailers have any defense against the following
tactic:
a) ECHELON spots a PGP-encrypted message from someone they're
suspicious of going through a remailer chain
b) they simply stop all the e-mail going to the remailer for 24 hours,
except for some precoded messages of their own which they know where
they're going
c) they let through the curious message
d) when an e-mail other than one of theirs comes out the remailer, they
watch where it goes, and restore the e-mail stream
The users each think their mail is simply time delayed - "maybe" past
the 24 hour limit of randomization
The E-mail goes to the next remailer in the chain, where it gets the
same treatment.
The spies eventually mark down that so-and-so is such-and-such, then
pick the next "suspicious person" to go after, and do it all over
again.
------------------------------
From: dexMilano <[EMAIL PROTECTED]>
Subject: Re: a couple of qutions on 3DES
Date: Tue, 13 Jun 2000 07:19:49 GMT
thx to all,
I know that DES is slow but this a project constrains (I proposed
something different but...).
Albert, could you send me a reference to documento on weakness for DES?
dex
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> On Mon, 12 Jun 2000 16:17:49 GMT, dexMilano <[EMAIL PROTECTED]>
> wrote:
>
> >Do you know if there are some constrains among 3 keys for use them
into
> >3des?
> >
>
> If you are using EDE you should ensure that the middle 8 bytes are not
> identical to either (or especially both) of the first 8 bytes or the
> last 8 bytes.
>
> We also check to see if any of these single-DES keys is one of the 4
> weak keys or 12 semi-weak keys specified in FIPS Pub 74.
>
> This slightly reduces the size of the keyspace (by a trivial amount)
> but is useful in catching some kinds of spiking.
>
> Albert P. BELLE ISLE
> Cerberus Systems, Inc.
> ================================================
> ENCRYPTION SOFTWARE with
> Forensic Software Countermeasures
> http://www.CerberusSystems.com
> ================================================
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Session key transmission
Date: Tue, 13 Jun 2000 09:47:06 +0200
Mok-Kong Shen wrote:
> Certainly, if the communication partners have no way of
> obtaining a shared secret key, then using public key is
> a necessity. Suppose, however, they have a secret key. Then
> they can use that as a master key to create the session key
> when it is needed through encrypting a random number with
> an algorithm (the same as used to encrypt the message proper
> or a different one) and prefix the random number to the
> ciphertext (obtained with the session key). The receiver first
> uses the random number to get the session key and then
> decrypts the ciphertext. In that way, the risk of the master
> key being compromised would be the same as that for the
> private key, I suppose. (On the other hand, I can see an
[snip]
Perhaps I may ask an additional question: Is the method of
session key transmission I described secure or are there
vulnerabilities in comparison to the public key scheme of
doing that? Many thanks in advance.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Large S-Boxes
Date: Tue, 13 Jun 2000 09:47:17 +0200
tomstd wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> >For saving time of getting books from the library, question:
> which of
> >the literatures you gave contain stuffs of BP and DP? Thanks.
>
> If you honestly want to make sboxes, you should read them all,
> but the papers I listed hardly constitutions comprehensive
> reading... I just don't have access to all the euro/asia/crypt
> books from 1980 to now (if I did I would be one very happy kid).
I am not that ambitious. My problem is that often books sought are
not available at my local library and I have to wait quite long or even
don't get them. Since you have implemented codes for BP and DP,
I am quite certain that you have looked at some papers before doing
that. It doesn't matter for me whether these are in-depth. I just want
to obtain one or two pointers for learning a little bit about BP and DP.
So it would be very nice if you could attempt to answer my question
once again.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Multiple encryptions
Date: Tue, 13 Jun 2000 09:47:22 +0200
Bryan Olson wrote:
> AllanW wrote:
> > We have some encryption program E,
> [...]
> > what we really do is take our
> > data files and encrypt them with D. Then we take the D
> > output and feed that into E.
> [...]
> > I've heard that this hypothetical case is a bad idea, and
> > not just because of any false sense of security. Someone I
> > respect tells me that the result is actually LESS secure
> > than using either D or E alone.
>
> If the keys are independant, then against ciphertext-only or
> known plaintext, the composition must be at least as strong
> as the first cipher applied, but there's a theoretical
> possibility that the chain is not as strong as the second
> cipher. See:
> Ueli M. Maurer and James L. Massey. Cascade ciphers:
> The importance of being first. Journal of Cryptology,
> 6(1):55-61, 1993.
>
> Against chosen plaintext, (again assuming independent keys)
> the composition must be at least as strong as the stronger
> of the two.
>
Does the requirement 'the keys are independent' somehow
implicitly also involve the additional requirement 'the ciphers are
independent in design' (which is presumably difficult to ascertain
in the absolute sense)? For otherwise I am afraid that counter-
example could be constructed such that a combination of two
ciphers is weaker than a single one.
M. K. Shen
------------------------------
Date: Tue, 13 Jun 2000 09:44:38 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: SBOX finder client
tomstd wrote:
> You can get a rudimentary copy of the sbox finder GUI client
> thingy at
>
> http://tomstdenis.com/sf.html
>
> It doesn't use TCP/IP to send the packets (since there will be
> barely any at all if any). It will dump the data to
> your "C:\windows\desktop" directory (if windows is not in that
> directory please make both directories).
Hmpf.
#include <windows.h>
GetWindowsDirectory ()
> Sorry there is no other ports at this time (I know somebody is
> gonna comment). However the FULL source code is given and it's
> a very dirty hack of SBOXGEN anyways..
See www.wxwindows.org. LGPL GUI for Windows (16 and 32 bit) +
Unix (GTK+ and Motif/Lesstif), other systems in development
(early BETA for MacOS). Currently still in BETA (if you want to
use the 2.x version, which is far cooler than 1.x. 1.x is already
final, frozen, done, for Windows/OS2/Unix etc.), but fairly
useable.
At the moment, I've even stopped working at my cipher (whirl)
and started to write a little program with that lib. FASCINATING !
;-)))
> Please give it a try, and if you decide to run the program on
> your machine let me know. I will document all the people
> running it on my webpage.
>
> If you have problems using it let me know.
>
> Tom
------------------------------
Date: Tue, 13 Jun 2000 09:49:08 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: And the search is on!
tomstd wrote:
> Even more math. My computer can test about 2^13.5 sboxes per
> second or about 2^38.3 sboxes per *year*. This is hardly a
> super speed. Assuming I tried this alone it would take me about
> 2^1625 years to find one (on average).
>
> Even if I could bring my speed upto 2^20 per second it would
> take 2^1618 years to find an sbox (average).
>
> Hmm... lots of time ...
We have time, don't we ? ;-)
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Interesting Magazine Article (Mike, Copperhead)
Date: Tue, 13 Jun 2000 10:08:30 +0200
John Savard wrote:
> An "Invention and Technology" special by American Heritage magazine
> has an article on "Breaking Codes Without Computers", which talks
> about many of the special-purpose codebreaking machines used by the
> U.S. during World War II. The author has a book coming out this
> October.
I tend to consider 'special-purpose machines' to be 'computers'. What
we commonly call 'computers' are 'general-purpose computers', while
there are 'special-purpose computers', e.g. for solving some problems
in physics more efficiently. I guess it is certainly very interesting to
know
whether the said special-purpose codebreaking machines of the past
involved some yet not popularly known methods/tricks that could be
taken over for implementing on our general-purpose computers to aid
cracking modern ciphers.
M. K. Shen
------------------------------
Date: Tue, 13 Jun 2000 09:57:01 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: My lastest paper on Block Ciphers
tomstd wrote:
>
> There is a PS copy at
>
> http://tomstdenis.com/ffunctions.ps.gz
Works fine with linux, thanks. :)
------------------------------
Date: Tue, 13 Jun 2000 09:58:38 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: SBOX finder client
Runu Knips wrote:
> tomstd wrote:
> > Sorry there is no other ports at this time (I know somebody is
> > gonna comment). However the FULL source code is given and it's
> > a very dirty hack of SBOXGEN anyways..
>
> See www.wxwindows.org. LGPL GUI for Windows (16 and 32 bit) +
> Unix (GTK+ and Motif/Lesstif), other systems in development
> (early BETA for MacOS). Currently still in BETA (if you want to
> use the 2.x version, which is far cooler than 1.x. 1.x is already
> final, frozen, done, for Windows/OS2/Unix etc.), but fairly
> useable.
>
> At the moment, I've even stopped working at my cipher (whirl)
> and started to write a little program with that lib. FASCINATING !
> ;-)))
Ooops, forget it. Such kind of program doesn't need to be
graphic on systems other than Windows anyway...
------------------------------
From: Stray Cat <[EMAIL PROTECTED]>
Crossposted-To:
alt.security.pgp,comp.security.firewalls,alt.privacy.anon-server,alt.privacy
Subject: Re: Is Gretchen down?
Date: Tue, 13 Jun 2000 08:07:02 +0000
On Tue, 13 Jun 2000 01:48:56 -0500, Tommy the Terrorist
<[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Stray Cat <[EMAIL PROTECTED]> wrote:
>
>> >is it?
>
>> No, but it is slow today.
>
>Do these time delayed remailers have any defense against the following
>tactic:
>
>a) ECHELON spots a PGP-encrypted message from someone they're
>suspicious of going through a remailer chain
>
>b) they simply stop all the e-mail going to the remailer for 24 hours,
>except for some precoded messages of their own which they know where
>they're going
>
>c) they let through the curious message
>
>d) when an e-mail other than one of theirs comes out the remailer, they
>watch where it goes, and restore the e-mail stream
>
>The users each think their mail is simply time delayed - "maybe" past
>the 24 hour limit of randomization
>
>The E-mail goes to the next remailer in the chain, where it gets the
>same treatment.
>
>The spies eventually mark down that so-and-so is such-and-such, then
>pick the next "suspicious person" to go after, and do it all over
>again.
I believe that RePGPing and transparent Remixing between remailers
should take care of this, and this is why those capabilities exist.
The problem is knowing, that the remailers that are supposedly doing
it, are actually doing it, and haven't suspended those modes for some
reason.
--
You can contact me by posting to alt.anonymous.messages, ATTN: Stray Cat
New PGP Key. All others are obsolete.
PGP Key: 0x0CC6E051 finger: [EMAIL PROTECTED] for a copy.
Nym address is disabled. Don't send mail there.
DSS/Diffie-Hellman PGP Keys Will NOT Be Accepted.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
