Cryptography-Digest Digest #466, Volume #9 Mon, 26 Apr 99 10:13:05 EDT
Contents:
Re: Prime Numbers Generator (David Kuestler)
Re: WHy would ibm sniff?? ("Douglas A. Gwyn")
Re: Prime Numbers Generator ("Douglas A. Gwyn")
Re: 128 bit DES (Gurripato (x=nospam))
Re: 128 bit DES (Gurripato (x=nospam))
scramdisk for AMAN ("m. bell")
Re: 128 bit DES (Reuben Sumner)
Re: True Randomness & The Law Of Large Numbers (Mok-Kong Shen)
Re: How good is /dev/random... (Mok-Kong Shen)
Re: RSA-Myth (Piso Mojado)
Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO (Mok-Kong Shen)
Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO (Mok-Kong Shen)
Re: RSA-Myth ("Trevor Jackson, III")
Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: David Kuestler <[EMAIL PROTECTED]>
Subject: Re: Prime Numbers Generator
Date: Mon, 26 Apr 1999 06:35:16 +0000
"Douglas A. Gwyn" wrote:
> David Kuestler wrote:
> > Paul Rubin wrote:
> > > Why not just store a bit map of where the primes are?
> > > 2^32 possible primes = 2^32 bits = 2^29 bytes = 512 MB.
> > Good idea ( 2^31 if you only work with the odds = 269MB ).
>
> And even better, omit the multiples of 3, 5, 7, 11, etc.
> :-)
I wonder where in the series the calculation/search efficiency would
cross over the straight search efficiency, my guess is somewhere in the
first 1000 primes ( CPU dependant/IO dependant/algorithm dependant/ oh
gosh- everything depentant ;-) ).
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: WHy would ibm sniff??
Date: Mon, 19 Apr 1999 22:04:16 GMT
John L Singleton wrote:
> I have seen many assertions that IBM 3COM and others have siffers.
> one question. WHY?
I assume you mean, packet sniffers.
If you want to keep an eye out for hacker traffic on your network,
they could be useful.
Anyway, they're easy to devise and are even shipped with some OSes.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Prime Numbers Generator
Date: Mon, 26 Apr 1999 06:04:12 GMT
David Kuestler wrote:
> Paul Rubin wrote:
> > Why not just store a bit map of where the primes are?
> > 2^32 possible primes = 2^32 bits = 2^29 bytes = 512 MB.
> Good idea ( 2^31 if you only work with the odds = 269MB ).
And even better, omit the multiples of 3, 5, 7, 11, etc.
:-)
------------------------------
From: [EMAIL PROTECTED] (Gurripato (x=nospam))
Subject: Re: 128 bit DES
Date: Mon, 26 Apr 1999 07:25:16 GMT
On Fri, 23 Apr 1999 23:07:10 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:
>[EMAIL PROTECTED] wrote:
>> DES only has a 56 bit key, so double des is 112. 3DES or triple
>> des is considered secure but there are better ciphers check out ...
>
>"Better" how?
Meaning perpahs that they are faster or more resistant to
cryptanalysis.
------------------------------
From: [EMAIL PROTECTED] (Gurripato (x=nospam))
Subject: Re: 128 bit DES
Date: Mon, 26 Apr 1999 07:22:47 GMT
On Sun, 25 Apr 1999 13:04:27 +0000, David Kuestler
<[EMAIL PROTECTED]> wrote:
>"Gurripato (x=nospam)" wrote:
>
>> DES is really 56 bits (the other 8 are just for parity
>> checking). You could combine 2 DES keys, but there´s the chance of a
>> man-in-the-middle attack. 3 DES has a combined key length of 56*3=168
>
> ^^^^^^^^^^^^^^^^
> meet-in-the middle
Correction taken. Thanx
------------------------------
From: "m. bell" <[EMAIL PROTECTED]>
Subject: scramdisk for AMAN
Date: Sat, 24 Apr 1999 21:14:59 -0500
looked at the program and docs and very interested. however, i noticed in
the documentation that problems can occur when the program is installed and
one runs a defrag. has this been resolved with the newest version, occur on
all machines, occur every time one tries to defrag, any work around for the
problem, etc?
thanks mike
------------------------------
From: [EMAIL PROTECTED] (Reuben Sumner)
Subject: Re: 128 bit DES
Date: 26 Apr 1999 07:50:32 GMT
Reply-To: [EMAIL PROTECTED]
On 22 Apr 1999 13:49:00 GMT, dino <[EMAIL PROTECTED]> wrote:
>Hi again
>I need some help. My customer ask a crypto application using 128 bit DES. I
>implemented a double DES with two 64 bit keys. Is that equivalent?
>If the answer is negative, is a triple DES with two 64 bit keys equivalent
>to a single 128 bit DES?
>I apologize for my poor english but i hope someone understand my question
DES is a 64 bit block cipher with a 56 bit secret key. You might want
a larger block size (all AES candidates have a 128 bit block size) or a
longer key. One possibility that addresses both of these issues is a
cipher called DEAL (an AES candidate). Essentially DEAL is a mode of
operation for triple DES which provides a longer block size. References
for DEAL can be found from the AES web pages.
Reuben
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Mon, 26 Apr 1999 12:15:28 +0200
R. Knauer wrote:
>
> On Fri, 23 Apr 1999 22:34:08 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
> wrote:
>
> >In this instance I'll support R. Knauer:
>
> Omigod! What has the world come to? I'm afraid to ask. :-)
>
> Must be more of that damnable quantum randomness at work.
If you yourself don't understand a paragraph of an author, here
the following you posted on Apr. 21:
> "Refined models [of coin-tossing and its relation to stochastic
> processes] take into account that the changes and their probabilities
> vary from trial to trial, but even the simple coin-tossing model
> leads to surprising, indeed shocking, results. They are of practical
> importance because they show that, contrary to accepted views, the
> laws governing a prolonged series of individual observations will show
> patterns and averages far removed from those derived for a whole
> population. In other words, currently popular psychological tests
> would lead one to say that in a population of "normal" coins most
> individual coins are "maladjusted".
> --Feller, p. 71.
why did you cite him??? I thought you have diligently read that
book and wanted to use what Feller wrote to aid your argumentation.
Hence I asked you to tell me what Feller meant there so that I
could continue the discussion with you and posted the following:
Could you tell what Feller means here? Does he mean that a 'normal'
coin does not exist in reality (which I certainly agree) or what?
Does he want to say some psychologists are wrong or what? I simply
can't understand.
Or did you simply want to show that you have read very much, are a
learned person?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: How good is /dev/random...
Date: Mon, 26 Apr 1999 12:23:18 +0200
Stephen Robert Norris wrote:
>
> Has anyone done any analysis on how "good" the randomness from /dev/random
> is in Linux?
I happen to have just obtained elsewhere an URL concerning /dev/random:
http://www.openpgp.net/random/index.html
M. K. Shen
------------------------------
From: Piso Mojado <[EMAIL PROTECTED]>
Subject: Re: RSA-Myth
Date: Mon, 26 Apr 1999 03:23:44 -1000
Anonymous wrote:
>
> > But think need break idea bad. When NSA random send then cannot tell when
> >
> break finished for to send when can then send can send cannot! How many
> > times send that generator with random? Zero! You emphatically will never
> > and I repeat never, with out code which is the best. Even after RSA send
> > PGP send PGP not received spall chalker when Turing failure mode address
> > not sent as expected after.
>
> PGP are such that generator with source code and send that the public
> will never with out code and an RSA PGP. Think.
>
> But this is RSA approach? How many times send that the public primes
> it is RSA approach? At baud, even the weaknesses that generator with
> a probability, that the Spooks may have to think just because the same
> algorithms is RSA PGP cannot!
>
> > Soon, crashing disk spalls without chalker wet net lib _DIS_ do not dis
> > me for to be dissed is broken to dismiss hard driven cable modem. At
> > 28.8k baud, even the slackest disser spalls reams without broken PGP.
>
> Let us think need break in the Spooks may have to stupid to need break
> idea bad. Soon, crashing disk spalls without chalker when break
> finished for generating of time the public key. Let us think just
> because the weaknesses that the Spooks may have to stupid to stupid to
> stupid to create good keys on there is RSA via PGP approach? At baud,
> even the same algorithms is the best.
>
> All come with random send PGP not the Public will never, with a
> mathematical break idea bad: put in the NSA can take the whole same
> algorithms is weak; either because the low whole same algorithms is not
> the whole same order of the low is RSA send cannot!
Look, I cannot disagree less half-heartedly than the least significant
bits of pseudo-random musings. RSA random sent by in Miller-Rabin context
when conversely juxstaposed with jugernaughtical looping. Recursiveness
of random or EVEN _TRUE_ random sources are less stringent if applied
recursively. When the parity is dis, the least significant
public key can be used can be you can see that using it cannot be safe
not when. Not every tested random number is prime so prone to errors
Miller-Rabins is not PGP usable. Loop until done, then repeat. Spall
reduction through winneying and marrowing , ala Mr. R , is proposed,
shoot it down or loop, forever for all I care! Good Night!
If parity of the lesat significant bliss is dis, cis, or trans, the
lattice basis of non-orthonormal. If orthonormality is dis, trnaslate it
using Schmitt-Gram. If not, spall without minnowing and Yarraowing. I
presonally do not do care if/if not ever again. Any thoughts?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO
Date: Mon, 26 Apr 1999 12:45:57 +0200
SCOTT19U.ZIP_GUY wrote:
> Sir we had very long private communications about scott16u at one
> time. You claimed you where going to do a write up on it. But then
> you stopped. If you can't understand what I am saying I think this
> thread should end until you program an example. I can tell from your
> arguments you have never written an adaptive huffman compression on
> your own.
You seem to repond quite out of context. First, your scott16u did
not have anything to do with compression. Compression is what
you recently attempted to combine with your method. Second,
you don't have to tell from my arguments ....... I wrote on 21 April
the following:
I like but haven't yet tried to code any compression algorithms.
> If you think the method should envovle information such that the
> one to one feature is not allowed fine. But if you think your doing
> the one to one thing and your approach is correct then show code
> for it as I have.
I don't understand what you mean by 'the one to one thing' and
what you mean by my 'approach'. I was suggesting that it might be
useful to have an end-of-file symbol to facilitate programming.
That, if anything at all, is a very tiny point and does not deserve
to be called an 'approach'.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO
Date: Mon, 26 Apr 1999 13:02:34 +0200
SCOTT19U.ZIP_GUY wrote:
>
> If you are suggesting that the extra bits at end are ignored then
> what is placed in those bits. If it is random then I guess that
> would be excepttable. But you still have the problem that if one
> uncompresses a guess file by using a wrong key. It is highly unlikely
> that the last symbol before the file ends will be the EOF file symbol
> as a result of the compression. And then the enemy could imediately
> rule it out as nonvalid.
One should certainly do a random fill. But how can these few random
bits aid the analyst? Anyway, it is not clear why the use of EOF or not
here matters. If one does not use EOF, it is also likely that
the Hufmann tranformation does not end on a byte boundary and one
has to fill in that situation too (if the file to be sent is to be
byte-oriented). As said, the EOF occurs once only; the analyst
can't identify from the ending bits of the ciphertext which bits
constitute the EOF and which bits are the random bits to make
a byte boundary. With an EOF you can even add an arbitrary number
of bytes of random bits with the very purpose to confuse the analyst,
I think.
M. K. Shen
------------------------------
Date: Mon, 26 Apr 1999 21:50:37 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: RSA-Myth
I suspect these are synthesized by a grammar-based mechanism, using a
vocabulary distilled from the history of the news group, or some other
similar source.
Piso Mojado wrote:
>
> Anonymous wrote:
> >
> > > But think need break idea bad. When NSA random send then cannot tell when
> > >
> > break finished for to send when can then send can send cannot! How many
> > > times send that generator with random? Zero! You emphatically will never
> > > and I repeat never, with out code which is the best. Even after RSA send
> > > PGP send PGP not received spall chalker when Turing failure mode address
> > > not sent as expected after.
> >
> > PGP are such that generator with source code and send that the public
> > will never with out code and an RSA PGP. Think.
> >
> > But this is RSA approach? How many times send that the public primes
> > it is RSA approach? At baud, even the weaknesses that generator with
> > a probability, that the Spooks may have to think just because the same
> > algorithms is RSA PGP cannot!
> >
> > > Soon, crashing disk spalls without chalker wet net lib _DIS_ do not dis
> > > me for to be dissed is broken to dismiss hard driven cable modem. At
> > > 28.8k baud, even the slackest disser spalls reams without broken PGP.
> >
> > Let us think need break in the Spooks may have to stupid to need break
> > idea bad. Soon, crashing disk spalls without chalker when break
> > finished for generating of time the public key. Let us think just
> > because the weaknesses that the Spooks may have to stupid to stupid to
> > stupid to create good keys on there is RSA via PGP approach? At baud,
> > even the same algorithms is the best.
> >
> > All come with random send PGP not the Public will never, with a
> > mathematical break idea bad: put in the NSA can take the whole same
> > algorithms is weak; either because the low whole same algorithms is not
> > the whole same order of the low is RSA send cannot!
>
> Look, I cannot disagree less half-heartedly than the least significant
> bits of pseudo-random musings. RSA random sent by in Miller-Rabin context
> when conversely juxstaposed with jugernaughtical looping. Recursiveness
> of random or EVEN _TRUE_ random sources are less stringent if applied
> recursively. When the parity is dis, the least significant
> public key can be used can be you can see that using it cannot be safe
> not when. Not every tested random number is prime so prone to errors
> Miller-Rabins is not PGP usable. Loop until done, then repeat. Spall
> reduction through winneying and marrowing , ala Mr. R , is proposed,
> shoot it down or loop, forever for all I care! Good Night!
>
> If parity of the lesat significant bliss is dis, cis, or trans, the
> lattice basis of non-orthonormal. If orthonormality is dis, trnaslate it
> using Schmitt-Gram. If not, spall without minnowing and Yarraowing. I
> presonally do not do care if/if not ever again. Any thoughts?
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO
Date: Mon, 26 Apr 1999 12:51:01 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> One should certainly do a random fill. But how can these few random
> bits aid the analyst? Anyway, it is not clear why the use of EOF or not
> here matters. If one does not use EOF, it is also likely that
> the Hufmann tranformation does not end on a byte boundary and one
> has to fill in that situation too (if the file to be sent is to be
This is like stating one should stop beating his wife. Yet the person
may never have been married or may have beem married and never
had beat his wife.
Only when one uses a limited form of thinking does one come
to the conclusion that a random fill is necessiary.
True a random fill in and by itself leads nothing to aid and
analyst. But it is a total waste of time and is not needed in
the compression.
Again I state look at my code and examples. You do not need random fill
If you could stop your narrow train of focus and stop back a little.
Do a thought experiment if that is not to hard. I have anwsered this
many times. But if you compress with a special symbol and random file.
you get the file you want to encrypt.
Know the enemy gets this file. And tries a key. He gets a file that
may or may not be your compressed file. But the trick is he can try
to uncompress the file. If he can't uncompress this for example the
EOF symbol is never found of though as this tree cahnges you have a
token for it that may change it never occurs in this guess file.
The enemy know nows that he had the wrong kill.
Is the above logic over your head.
THE THING ONE SEEKS IN A COMPRESSION METHOD BEFORE ENCRYPTION
IS A METHOD THAT ALLOWS ANY FILE TO BE A COMPRESSED FILE.
IN SHORT ENEMY GUESS FILE "A" IT MAY BE JUNK. BUT ENEMY RUNS
DECOMPRESSION GETS FILE "B" ENEMY RUNS COMPRESSION GET FILE "A"
in the above case enemy has no clue from compression method
about wether file "A" was the actua; compressed file that you
encrypted. Think a little please.
> byte-oriented). As said, the EOF occurs once only; the analyst
> can't identify from the ending bits of the ciphertext which bits
> constitute the EOF and which bits are the random bits to make
> a byte boundary. With an EOF you can even add an arbitrary number
> of bytes of random bits with the very purpose to confuse the analyst,
> I think.
>
Adding a random number of bits is a function of encryption not
compression. ANd your are right an analyst looking at only the
ending of a file can not tell what the EOF is. If he is looking at
the ending of the file you compressed. But if he had the whole
file. He could tell if it was a "REAL COMPRESSED" file. Also
if a random number of bits added that information has to be in
the file itself for the receiving person to use. Remeber the game
is enemy has same code. IF this random number is passed secrectly
then again it is like part of a key and is in the realm of encryption
not compression.
David Scott
--
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
to email me use address on WEB PAGE
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
** 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
******************************
