Cryptography-Digest Digest #488, Volume #9 Sun, 2 May 99 01:13:03 EDT
Contents:
Re: Encrypted Phones (Paul Rubin)
Re: True Randomness & The Law Of Large Numbers (Piso Mojado)
Re: True Randomness & The Law Of Large Numbers ("Trevor Jackson, III")
Re: Obvious flaws in cipher design (Jaime Suarez)
Re: Extreme lossy text compression (D. J. Bernstein)
Commercial PGP for Linux? (Bernie Cosell)
Re: Weakness Found in Alternative Signature Format (Lloyd Miller)
Re: Obvious flaws in cipher design (SCOTT19U.ZIP_GUY)
Re: True Randomness & The Law Of Large Numbers (R. Knauer)
Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO (SCOTT19U.ZIP_GUY)
Re: Deadly threats (Anonymous)
Fast random number generator ([EMAIL PROTECTED])
Re: Factoring breakthrough? (Nathan Kennedy)
Stream Ciphers and Quantum Computer Resistance
Re: is it true that Irish teen found crypto alg faster that RSA ("Caliban")
Re: Common Passowrds (Nathan Kennedy)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Encrypted Phones
Date: Sat, 1 May 1999 18:39:52 GMT
In article <7gf4b1$k42$[EMAIL PROTECTED]>, PJ <[EMAIL PROTECTED]> wrote:
>Motorola makes several consumer-available models of secure telephones. At
>least one of their cordless models has triple DES encryption between handset
>and base.
What model is that, and what makes you think it uses 3des?
>All of their secure telephones operate with 3DES between
>telephones, AFAIK. I've seen them sold overseas for as little as $250 US.
Same question.
------------------------------
From: Piso Mojado <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Sat, 01 May 1999 10:28:25 -1000
R. Knauer wrote:
>
> On Fri, 30 Apr 1999 19:08:06 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
> wrote:
> >There are
> >no philosophic difficulties whatsoever in this matter, and it
> >has nothing to do with ensemble averages.
>
> More pontification. <yawn>
>
> You continue to insist on committing the cardinal sin that Feller
> warns against, namely attempting to infer the ensemble average of a
> sequence generation process from the time average of one sequence.
>
> And you are giving every evidence that you are totally beyond
> redemption in your heresy.
>
> Bob Knauer
What a fucking asshole. Hey, Knauer you really made a fool of
yourself. Please take your arrogant non-sense into the commercial
sector, where you can be quickly fired.
------------------------------
Date: Sat, 01 May 1999 16:01:55 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
R. Knauer wrote:
>
> If you got one more bit of bias than the Monobit Test allows, you
> would declare the TRNG to be malfunctioning, at least for that error
> level. Yet if you got one bit of bias fewer than that, you would
> declare that the TRNG is healthy, at least for that error level.
>
> So, the health of the TRNG in the context of the Monobit Test at that
> level of error is crucially dependent on one bit either way. That's
> simply too much to accept as a real world diagnostic.
You have simply got to tell us where you get what you are smoking!
In this context I'd like you to describe the utility of a multi-bit
criteria. I.e., one that determines sucess and failure as more than one
bit apart. I also need a description of the intermediate state in which
there are not enough bits set to declare succes, and not enough bits
clear to declare failure. What is the result -- absence of a quorum?
>
> >There are
> >no philosophic difficulties whatsoever in this matter, and it
> >has nothing to do with ensemble averages.
>
> More pontification. <yawn>
>
> You continue to insist on committing the cardinal sin that Feller
> warns against, namely attempting to infer the ensemble average of a
> sequence generation process from the time average of one sequence.
>
> And you are giving every evidence that you are totally beyond
> redemption in your heresy.
>
> Bob Knauer
>
> Guns don't cause violence - violence causes violence. Gratuitous violence
> in the media/entertainment industry causes violence. Government sponsored
> violence like the Waco Massacre causes violence. Quit blaming law abiding
> citizens for the violence in America, and blame the real sources of violence:
> the federal government and the media/entertainment industry.
------------------------------
From: [EMAIL PROTECTED] (Jaime Suarez)
Subject: Re: Obvious flaws in cipher design
Date: Sat, 1 May 1999 12:32:36 +0200
On Wed, 28 Apr 1999 00:12:41
GMT, SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>
>> Any password or passphrase used should have adequate
>> size, should not be stored or transmitted unencrypted, and
>> should be hashed before use.
>>
>
> Actually Hashing is a bad idea since it usually reduces
>the size of the effective key.
>
Could you explain this more? If users passwords are a few characters long and
I hash them to 128 or 160 bits, why am I reducing the size of the effective
key?
--
Jaime Suarez <[EMAIL PROTECTED]> Linux user #114.688
PGP Key id 0x6E90E61B RedHat 5.2 on i686 Linux machine #50.573
http://come.to/MundoCripto *Remove 'QUITAESTO' to reply
=====================================================================
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Subject: Re: Extreme lossy text compression
Date: 1 May 1999 21:22:44 GMT
John A. Limpert <[EMAIL PROTECTED]> wrote:
> The limiting factor appeared to be main memory bandwidth, not CPU speed.
hash127 handles input straight from DRAM at over 200 million bits/second
on my old Pentium-133. Anything slower than that is clearly not limited
by memory bandwidth.
---Dan
------------------------------
From: [EMAIL PROTECTED] (Bernie Cosell)
Crossposted-To: comp.security.unix
Subject: Commercial PGP for Linux?
Date: Thu, 29 Apr 1999 19:37:03 GMT
I am trying to locate PGP for Linux that I can use for a commercial
application. The 2.6 sources claim to be for noncommercial/personal use
only, so I followed the threads to viacrypt->NetworkAssociates->McAfee
but all I can find are Windows and Mac packages. Did I miss something? If
not, anyone know where I -can- find a commercial-OK PGP package for Linux?
Thanks!!
/Bernie\
--
Bernie Cosell Fantasy Farm Fibers
[EMAIL PROTECTED] Pearisburg, VA
--> Too many people, too few sheep <--
------------------------------
From: [EMAIL PROTECTED] (Lloyd Miller)
Subject: Re: Weakness Found in Alternative Signature Format
Crossposted-To: alt.security.pgp,comp.security.misc,comp.security.pgp.discuss
Date: Sat, 01 May 1999 02:09:30 GMT
Jim Gillogly ([EMAIL PROTECTED]) wrote:
: I wrote:
: > Sal quoted Crowell, DD of NSA from 1997:
: > > ... 12 million times the age of the universe, on average,
: > > to break a single [PGP] message.
: > Close enough. Assuming the universe is 13 billion years old, I
: > make it about 3 million times the age of the universe on average,
: > figuring 500,000 keys/sec (from today's distributed.net RC5 project
: > cores). A factor of four difference corresponds well enough to the
: > Moore's Law increase between then and now.
: Now that I think about it, invoking Moore's Law to help out raises
: another issue. The SKIPJACK report assumed Moore's Law would continue
: indefinitely, which is why they estimated about a 30-year lifetime
: before its 80-bit keyspace would be brute-forceable with reasonable
: effort.
: If we also assume Moore's Law will hold, we can go another bit deeper
: every eighteen months based solely on increased CPU horsepower, or two
: bits in three years. Since 56-bit encryption is crackable in about
: two days on average for $0.25M, a similar expenditure would buy a
: 128-bit crack in about a century. Naturally we can't assume it will
: hold up past where we see physical laws kicking in, but it's held up
: a lot longer than it seemed like it would a decade ago.
I love this! <g> It disposes of all the pie in the sky millions and
billions of years which make people's eyes glaze over. Saying that if
computers continue to develop at their current rate it will take about
a century to break a 128 bit key by brute force is a lot easier to
understand. Most people will also understand the unlikelyhood of
computers continuing to develop at this rate. Now, how can we take
into account theoretical advances! <g>
--
Lloyd Miller, Calgary
[EMAIL PROTECTED]
Terminal Insomniac
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: Re: Obvious flaws in cipher design
Date: Sun, 02 May 1999 00:42:01 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Jaime Suarez) wrote:
> On Wed, 28 Apr 1999 00:12:41
> GMT, SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
> >
> >> Any password or passphrase used should have adequate
> >> size, should not be stored or transmitted unencrypted, and
> >> should be hashed before use.
> >>
> >
> > Actually Hashing is a bad idea since it usually reduces
> >the size of the effective key.
> >
>
> Could you explain this more? If users passwords are a few characters long and
> I hash them to 128 or 160 bits, why am I reducing the size of the effective
> key?
>
If the user password is only a few characters in lenght then one
needs only to search a small character space to test for a break in
the code. Also if the string of characters is much longer than 128 bits
such that it has an entropy of larger than that if a random 128 bit
string even perfect hashing would allow for more than one ascii string
to map to the same key. If the ascii string is exactly 128 bits. All
hashing could do is increase the chance of a common mapping to a certain
key and hashing should not be done at all. One needs to hash only if
the password is longer than the key.
David A. Scott
> --
> Jaime Suarez <[EMAIL PROTECTED]> Linux user #114.688
> PGP Key id 0x6E90E61B RedHat 5.2 on i686 Linux machine #50.573
> http://come.to/MundoCripto *Remove 'QUITAESTO' to reply
> ---------------------------------------------------------------------
>
--
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
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Wed, 28 Apr 1999 17:26:19 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 28 Apr 1999 09:34:15 -0500, Jim Felling
<[EMAIL PROTECTED]> wrote:
>All the tests in FIPS-140 are designed to detect 1 in a million(under normal
>conditions with a working generator) events.
Yes, that is what they allegedly do, but I challenge their efficacy in
accomplishing that, at least in the case of the Monobit Test.
The objection comes from the single sample of small size. I would
expect a large number of large samples collected at different times
and under different conditions to be reflective of the internal
operation of the generator, because such tests are more like an
ensemble average.
Once again, I am convinced of Feller's dictum that one cannot infer
the ensemble average from the time average of one sequence.
>I agree with his assertion. No statistical test can DETERMINE if a sequence is
>(non)random, but many can provide indications ( some of them very, very strong)
>as to its (non)randomness.
And I agree that some statistical tests are better than others as
diagnostic aids. For example, the Long Run test appears suitable as a
diagnostic warning.
But I refuse to take for granted that a simplistic small sample test
like the Monobit Test has any validity even as a diagnostic test.
There is no a priori justification for its validity.
The Monobit Test is to me a clear example of attempting to infer an
ensemble average from a time average of one sequence.
Bob Knauer
Guns don't cause violence - violence causes violence. Gratuitous violence
in the media/entertainment industry causes violence. Government sponsored
violence like the Waco Massacre causes violence. Quit blaming law abiding
citizens for the violence in America, and blame the real sources of violence:
the federal government and the media/entertainment industry.
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO
Date: Mon, 26 Apr 1999 13:22:15 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> 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.
>
The point is you rattle on and on. Like when you falsely claimed
you where interested in scott16u the encryption program. But you
never got past first base with it. You stated you would write up the
method which was a lie.
My point is that you are arguing again and again you learn nothing
but this time it is about compression. You say you are interested
and want to learn. But instead of thinking and writting test cases
you make meaningless arguments with out doing any testing of the
code. You are to lazy to look at what I did. Instead you try to
attack it with means that show you haven't bothered to look at code
my god man I can't hold your hand all the time. Stand on your
own 2 feet.
> > 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'.
>
>
Only a small mind would think it is a minor point. I give up explaining
this part to you because it is obvious you don't want to understanf
why it is a "MAJOR POINT". Maybe someone else can explain why.
The so called one to one I have stated over and over. Lets try
one more time. I doubt if you have the ability to understand but
if you do I doubt you have the honesty to say you understand.
"one to one" in this context.
1)Take a random file of 1 to N bytes called "A". N being very large.
2)"Decompress" the file "A" to a file "B".
3)"Compress" the file "B" to a file "C".
4) file "A" is "IDENTICAL" to "C"
on the other side if coinn:
5)Take a random file of 1 to N bytes called "D". N being very large.
6)"Compress" the file "D" to file "E".
6)"Decompree" the file "E" to a file "F"
8) file "D" is "IDENTICAL" to "F"
If this is to hard for you I see nothing gained by further
talking since we are not on the same playing field. But
I think the average brain should tell you that compression
which is ONE TO ONE is a compression method that leaves
no hooks for the NSA types to use when breaking code.
My interest is in other "ONE to ONE" compression methods
that have this useful property if you or any reader knows of
such I would be interested.
Thank You
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
------------------------------
Date: Sun, 2 May 1999 05:43:54 +0200 (CEST)
From: Anonymous <[EMAIL PROTECTED]>
Subject: Re: Deadly threats
hapticz wrote:
> if I continue to send deadly physical threats to high government officials
> in encrypted form without the keys, am i liable to be prosecuted?
0000000 302 135 335 270 135 221 156 331 336 111 271 200 366 332 266 257
0000010 166 374 342 035 351 376 064 144 362 166 366 103 231 033 016 101
0000020 177 017 054 335 243 042 116 236 120 277 250 146 142 222 242 041
0000030 332 366 321 067 043 133 064 117 324 141 206 012 366 146 062 355
0000040 212 143 164 332 303 006 236 320 026 271 132 330 043 241 117 272
0000050 340 211 166 164 175 164 020 370 230 372 270 252 276 050 247 277
0000060 140 310 021 057 323 117 303 332 131 326 116 101 347 333 200 305
0000070 246 176 141 327 315 243 305 334 222 262 050 010 106 126 127 340
0000080 351 232 121 026 125 001 266 064 370 161 377 152 000 224 202 304
0000090 112 022 114 176 312 113 154 327 112 332 025 211 222 021 337 266
00000a0 106 274 050 357 154 134 142 365 377 143 107 316 320 117 210 063
00000b0 333 027 244 042 317 060 322 267 367 377 343 377 162 270 064 307
00000c0 066 102 365 226 347 242 106 372 022 023 316 241 033 237 275 351
00000d0 163 062 022 305 271 373 005 140 153 134 144 064 013 044 222 366
------------------------------
From: [EMAIL PROTECTED]
Subject: Fast random number generator
Date: Sun, 02 May 1999 03:48:03 GMT
I have played with RC4 and it's 8-bit output is good, but the shuffle is not
so super. I also have looked at Wake, and it looks nice.
Are there any good generalized RNG (outside of LFSRs) that can produce n bit
outputs?
Also given a deck of m n-bit words does anyone know a good shuffle algorithm?
Also a key-init shuffle like RC4?
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Nathan Kennedy <[EMAIL PROTECTED]>
Subject: Re: Factoring breakthrough?
Date: Sun, 02 May 1999 12:08:05 +0800
"Tony T. Warnock" wrote:
>
> JCA wrote:
>
> Bob Silverman wrote:
>
> > > Don't speculate. Wait until Tuesday and you will know.
> > >
> > > And your guess is grossly wrong. The result is NOT a new algorithm.
> > >
> > Damn I hate this uncertainty! Can't you give us a hint?
>
> Shamir did the work. Let him announce it as he wishes. (With trumpets and
> drums if wanted.)
I just hope he doesn't PATENT it...
Nate
--
bogosort(int *l,int n){int i,a,b;do{a=random()%n;b=random()%n;i=l[a];
l[a]=l[b];l[b]=i;i=1;while(i<n&&l[i-1]<=l[i])i++;}while(i<n);}
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Stream Ciphers and Quantum Computer Resistance
Date: 2 May 99 03:33:30 GMT
Having noted that at least *one* view of quantum computers envisages them
also incorporating reversible computation, in order that they can avoid
catastrophic heat buildup while isolated,
it occurs to me that one can certainly design a cipher so that it causes
headaches for a reversible computer.
A long sequence of irreversible operations - operations that can be done
reversibly, but which use up blank storage - would help.
Of course, in some cases, one can reverse a calculation after copying its
result, so this is still oversimplified. But if one keeps needing new
results, and therefore the only way everything could be cleaned up is if
everything is kept around till the end, there is still a problem:
doubtless, quantum computer experts already know how to state the precise
limitation here.
Blowfish performs quite a bit of calculation in its setup. XOR and
addition are reversible, but if one were to use a non-linear operation of
the kind one finds in 3-Way, that could be fixed. However, with a few
extra qubits, one could just try to find the subkeys directly, and ignore
the key setup step.
RC4 performs a lot of key setup before starting. However, that key setup
consists of moving around the elements of an array that always contains
the numbers 0 through 255, albeit in some jumbled order. This suggests
that something that keeps introducing new elements into the list, more
like MacLaren-Marsaglia, would be appropriate.
As it happens, one stream cipher I've encountered does seem to fill the
bill nicely, as it involves calculating new entries, in a complicated
fashion, for a shift register, and it spends several cycles setting up:
Panama.
I'm already thinking of how to modify my "Large-Key Brainstorm", which at
present is too reversible, to make it difficult to deal with by such
attacks. But we already have one good example of the way to go.
John Savard
------------------------------
From: "Caliban" <[EMAIL PROTECTED]>
Subject: Re: is it true that Irish teen found crypto alg faster that RSA
Date: Sun, 2 May 1999 00:56:51 -0400
Yes. I agree.
--=20
"America's Senior Executives ... At Your Fingertips!"
http://www.demandresearch.com
Thirteen wrote in message <[EMAIL PROTECTED]>...
>Nelson G. Rich wrote:
>>=20
>> Please excuse me for this if by now it's old hat, but is it true that =
a 16
>> year old Irish gal has found an algorithm that's faster than RSA?
>> Can anyone point me to accurate source?
>>=20
>> Thanks.
>
>That is only a rumor. There are many algorithms faster than RSA
>that are not rumors, they are well documented. The rumor you speak
>of was in the press a few months ago, but they never described
>the algorithms in detail. What is interesting is the age and=20
>gender of the possible inventor. If an 8 year old girl flies
>an airplane across a continent that is big news, even if she
>has an older pilot making all the take-offs, landings, and doing
>the navigation. If her plane crashes, blame it on her father.
------------------------------
From: Nathan Kennedy <[EMAIL PROTECTED]>
Subject: Re: Common Passowrds
Date: Sun, 02 May 1999 12:51:33 +0800
Nathan Christiansen wrote:
>
> Nathan Kennedy wrote:
> >
> > Nathan Christiansen wrote:
> > >
> > > Where do you get a copy of the RC4 encryption algorithm?
> >
> > You look for it.
>
> Thanks for the sarcasm, what I was looking for was help.
>
> > For one thing, it's defined in an RFC, referred to as ARCFOUR.
>
> I searched various different sites including the RFC search engine at
> http://www.pasteur.fr/other/computer/RFC/ and there is only one RFC that was indexed
>with a
> reference to ARCFOUR, and that is RFC #2470 which states changes to the document
>included
> changing couple of references from ARCFOUR to RC4. (i.e. not a description of the
>algorithm.)
>
No offense intended. I didn't think that finding it should be too hard,
but sometimes it can be annoying, especially proprietary standards like
RC4. Actually, I guess it wasn't in an RFC after all, it was an expired
Internet draft standard. Anyway, a search for ARCFOUR on at www.google.com
turned it up. You can get the document at
http://cag-www.lcs.mit.edu/pub/dm/papers/draft-kaukonen-cipher-arcfour-01.txt
or you can examine my own attached implementation.
> One of the other documents found through another RFC site described RC4 with a
>40-bit key as
> a proprietary very weak encryption algorithm, however, it did not say that it was
>"broken".
No severe, exploitable (published) weaknesses in RC4 have been found.
Obviously if you only use 40-bit keys, you are very vulnerable to
keysearch. There is a class of weak keys, and they are some (extremely
slight) statistical anomalies in RC4's outputs that show themselves after
massive amounts of output.
Here's my simplistic implementation. l is the length of the key K, S is a
256 element array of uchar.
#define uchar unsigned char
void
rc4setup(uchar l,uchar *K, uchar *S)
{
uchar S2[256];
int i,j=0;
uchar t;
for (i=0;i<256;i++)
S[i]=i;
for (i=0;i<256;i++)
S2[i]=K[i%l];
for (i=0;i<256;i++)
{
j = (j+S[i]+S2[i])%256;
t=S[i];
S[i]=S[j];
S[j]=t;
}
}
void
rc4crypt(uchar *S)
{
int i=0,j=0;
uchar t,q;
q=getchar();
while (!feof(stdin))
{
i=(i+1)%256;
j=(j+S[i])%256;
t=S[i];
S[i]=S[j];
S[j]=t;
t=(S[i]+S[j])%256;
putchar(S[t]^q);
q=getchar();
}
}
------------------------------
** 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
******************************
