Cryptography-Digest Digest #498, Volume #9 Tue, 4 May 99 12:13:03 EDT
Contents:
Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO (mok-kong shen)
Re: Thought question: why do public ciphers use only simple ops like shift and XOR?
(Jim Gillogly)
Re: Predicting calculator pseudo-random numbers (Nathan Kennedy)
Re: Thought question: why do public ciphers use only simple ops like shift and XOR?
(Terry Ritter)
Obvious flaws in cipher design (Jaime Suarez)
Smart card protocols... (Volker Hetzer)
Re: Smart card protocols... (Volker Hetzer)
Re: Factoring breakthrough? ("Tony T. Warnock")
Re: Deadly threats (SCOTT19U.ZIP_GUY)
Search for Certificate Servers ("Alberty Pascal")
Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO (SCOTT19U.ZIP_GUY)
Re: Fast random number generator (mok-kong shen)
Embarrassing question about Blowfish (Chris Yearsley)
----------------------------------------------------------------------------
From: mok-kong shen <[EMAIL PROTECTED]>
Subject: Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO
Date: Tue, 04 May 1999 09:17:50 +0200
SCOTT19U.ZIP_GUY wrote:
>
>
> AGAIN IT IS DUMB TO HAVE AN EOF FOR COMPRESSION since the attacker
> can rule out many keys since only the one that lead to your EOF would
> be the correct ones. IS THIS TO HARD FOR YOU TO GRASP? YES OR NO?
I can't understand why do you have so much against using one more
symbol. If I write only in the alphabet of 26, it can happen that
I have to use 'z'. But maybe I could use some roundabout way to avoid
the use of 'z' and agree with my partner that 'z' ends my message
and everything that follows is rubish just to fool the analyst.
Do you have something against my using 'z' as EOF this way?
M. K. Shen
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Thought question: why do public ciphers use only simple ops like shift
and XOR?
Date: Mon, 03 May 1999 23:49:20 -0700
Terry Ritter wrote:
>
> [EMAIL PROTECTED] wrote:
>
> >As shown above, PMRC moves us from a small chance of exposing
> >all the traffic to almost assuredly exposing a small portion of
> >the traffic.
>
> This false conclusion is a consequence of using an inappropriate model
> for cipher weakness. When we realize that limited resources require
> attackers to apportion effort among used ciphers, we see that
> increasing the number of ciphers decreases the effort available for
> any one. The alternative, of course, is for all effort to be aimed at
> one cipher.
This summary shows clearly where your difference comes with others here.
You assume that by putting in place a large number of ciphers, including
weak ones, the attackers will not be able to determine which ones
are weak because there are so many possible ciphers, both potentially
strong and certainly weak. This appears wrong to me: some weak ciphers
make it obvious that they are weak, and the analyst can focus on those
that fail obvious tests. Once some of them are broken, the analyst
gets a window into that part of the traffic, which may well be the
whole ball game.
I feel it's naive to assume that a cipher that hasn't been attacked
can be used as safely as one that has been attacked unsuccessfully.
Neither has a guarantee that it will stand up to the next attacker,
but I'd trust a cipher that analysts have tried and failed to break
more than one that has been produced from a random cipher generation
process. Knuth's dictum that pseudo-random number generators should
not be chosen at random applies even more strongly to cryptosystems.
--
Jim Gillogly
Sterday, 13 Thrimidge S.R. 1999, 06:33
12.19.6.2.18, 1 Edznab 6 Uo, Fourth Lord of Night
------------------------------
From: Nathan Kennedy <[EMAIL PROTECTED]>
Subject: Re: Predicting calculator pseudo-random numbers
Date: Tue, 04 May 1999 16:24:41 +0800
Franzen wrote:
>
> Nathan Kennedy <[EMAIL PROTECTED]> wrote Thu, April 29, 1999 at 4:08 AM:
>
> Geoff Lane wrote:
>
> >>This is a curious question but I suspect the experts are here rather than
> >>in any maths newsgroups.
> >>
> >>Suppose you have a pocket calculator with a "random" button. From a
> limited,
> >>sequential list of generated numbers is it possible to determine the
> >>algorithm used and hence predict the sequence from any given point?
> >>
> >>I suspect that most calculators either use very poor "folk" algorithms or
> >>standard algorithms described by Knuth or Numerical Recipes so the search
> >>space may be quite limited.
>
> I cannot find an fx-120 Casio. The Casio web site does not list that model.
> Maybe it is out of production. I finally got an CFX-9850G out of curiosity.
Sorry. I meant, fx-270solar. Very Handy.
Nate
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Thought question: why do public ciphers use only simple ops like shift
and XOR?
Date: Tue, 04 May 1999 09:37:49 GMT
On Mon, 03 May 1999 23:49:20 -0700, in <[EMAIL PROTECTED]>, in
sci.crypt Jim Gillogly <[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>>
>> [EMAIL PROTECTED] wrote:
>>
>> >As shown above, PMRC moves us from a small chance of exposing
>> >all the traffic to almost assuredly exposing a small portion of
>> >the traffic.
>>
>> This false conclusion is a consequence of using an inappropriate model
>> for cipher weakness. When we realize that limited resources require
>> attackers to apportion effort among used ciphers, we see that
>> increasing the number of ciphers decreases the effort available for
>> any one. The alternative, of course, is for all effort to be aimed at
>> one cipher.
>
>This summary shows clearly where your difference comes with others here.
Which others would those be, exactly? Do you claim to speak for those
"others"? How do you know what they think? Exactly *how* do you know
this *is* "the" "difference"?
>You assume that by putting in place a large number of ciphers, including
>weak ones, the attackers will not be able to determine which ones
>are weak because there are so many possible ciphers, both potentially
>strong and certainly weak.
It is *you* who are assuming that having a large number of ciphers
means we have "weak" ones. In any collection of anything we will have
some sort of distribution of values, but these are "values" we cannot
measure, so we do not know that distribution, and in a very strong
sense *cannot* know that distribution. We would not propose, and
users should not use, ciphers which appear weak. There is no reason
to assume that we have weak ones, only that we have strong*er* and
weak*er* ones. But of course people would be free to choose whatever
they think might be better. Some will be right.
>This appears wrong to me: some weak ciphers
>make it obvious that they are weak, and the analyst can focus on those
>that fail obvious tests.
Fine, don't use those.
>Once some of them are broken, the analyst
>gets a window into that part of the traffic, which may well be the
>whole ball game.
Well, on the one hand, we can *assume* that by breaking a few
different ciphers (!), each of which produces about one (1) message
each, the analyst can extrapolate the world from that.
Or we could alternately *assume* that by breaking the one (1) cipher
in the one cipher system, the analyst gets *all* the data there is and
need perform no extrapolation at all. This is indeed "the whole ball
game."
Which approach would the attackers prefer? Little snippets, or
everything from the past on into the future? When the one cipher is
broken, it stays broken, and people keep using it.
Your argument rests on an unstated assumption: That a the reviewed
cipher in a one-cipher system is stronger than a non-reviewed cipher.
But we cannot know this. Worst case, it may be that the one cipher we
use is *already* breakable using existing previously-developed secret
techniques. And if the worst does happen, things certainly will not
get any better unless we change ciphers. And if we only have a few
ciphers, we will soon enough use the broken one again.
>I feel it's naive to assume that a cipher that hasn't been attacked
>can be used as safely as one that has been attacked unsuccessfully.
That is not naive, that is reality. Being "attacked unsuccessfully"
means having had some unknown amount of effort put into attacks
presumably by people you personally trust. But academics generally do
not report on a lack of attack results. Yet it is just this sort of
non-result which constitutes having been attacked unsuccessfully. The
evidence you want is not what academics normally provide.
Further, what is really naive is to imagine that the attackers working
in secret are limited to what academics know. In fact, we expect the
secret attackers to always know more, and probably have more
experience, time, and more of every sort of resource. We simply
cannot compare academic capabilities to those of our secret attackers,
and it is a logical error to extrapolate academic non-results to the
strength that we want. Even an "unsuccessfully attacked" cipher may
be already broken. Surely we can't get weaker than that. Any cipher
can fail at any time.
>Neither has a guarantee that it will stand up to the next attacker,
>but I'd trust a cipher that analysts have tried and failed to break
>more than one that has been produced from a random cipher generation
>process.
If that is what you would trust, you could simply force that cipher to
be part of your cipher stack, which otherwise consists of other
ciphers each of which you also approve. So where is the problem?
>Knuth's dictum that pseudo-random number generators should
>not be chosen at random applies even more strongly to cryptosystems.
Unless, of course, there is a compensating advantage to be obtained
thereby. That advantage, of course, is the ability to limit the
extent of any break to the few messages which use that particular
ciphering configuration. In contrast, if we don't change ciphers, we
had better *hope* our cipher is secure, because we sure don't have a
protocol in place to terminate a break if one should very
unfortunately occur.
In my opinion, good cryptography is not about wishing and hoping that
our cipher is strong because "our" guys could not break it with the
effort they applied. Good cryptography is about accepting the
possibility of weakness, and establishing protocols which minimize the
effects of that possibility. Once a cipher is broken, it remains
broken, and if we don't change ciphers, our entire cryptographic
system and all the effort we put into it is waste and delusion. Good
cryptography should not foster delusions of security where there may
be none, even if no academic in the world can break the cipher.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Jaime Suarez)
Subject: Obvious flaws in cipher design
Date: Mon, 26 Apr 1999 19:23:00 +0200
Let's say that I am an amateur cryptographer and have written -just for the
fun of it- an algorithm. I would like the group to explain me their 'top ten'
reasons to see that it has obvious flaws. For example looking only at the
output it shouldn't compress very much, right? or maybe change some bits of
the input and see how the output comes out? And what should I avoid in the
algorithm itself?
I am not talking about 'high' cryptanalysis here, just plain things.
Thank you and sorry for my English.
--
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: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Smart card protocols...
Date: Tue, 04 May 1999 13:40:03 +0200
Hi!
How do smart cards communicate with their respective host devices?
Is there some standard like ssl or do they use proprietary protocols?
What would be a good place to start to get information?
Greetings!
Volker
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: Smart card protocols...
Date: Tue, 04 May 1999 14:46:17 +0200
Mok-Kong Shen wrote:
>
> http://www.geocities.com/ResearchTriangle/Lab/1578/smart.htm
Looks perfect. Thanx a lot!
Volker
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Factoring breakthrough?
Date: Tue, 04 May 1999 08:01:03 -0600
Reply-To: [EMAIL PROTECTED]
lcs Mixmaster Remailer wrote:
> Paul Rubin <[EMAIL PROTECTED]> wrote:
> > Oh what the heck. I've heard it is based on work that Prof. Shamir
> > presented at the Crypto 97 rump session, where you'd stack up 1000's
> > of sheets of photographic film and see where the dots lined up. Kind
> > of reminiscent of Zygalski's perforated sheets used for breaking
> > Enigma ;-). I don't remember details from the Crypto talk though.
>
> Here are my notes from that talk:
>
> The idea is to break 40 bit DES using film as an analog computer.
> Photographic film can hold 2^30 pixels per square inch, so 10 yards
> of 70 mm movie film could hold 2^40 pixels.
>
> Treating pieces of such film as long, 2^40 bit "registers", certain
> logical operations can be performed on them using photographic techniques.
> Negating a register can be done by taking the photographic negative of
> the film. NOR is done by stacking multiple strips of film and exposing
> through them. NAND is a double exposure (first expose through one,
> then expose through the other). XOR is a combination of these.
>
etc.....
This looks a lot like some of the Lehmer's machines for sieving. Using logical
rather than arithmetic operations.
Tony
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: Re: Deadly threats
Date: Tue, 04 May 1999 14:11:46 GMT
In article
<[EMAIL PROTECTED]
>, root <[EMAIL PROTECTED]> wrote:
> On Sun, 2 May 1999, Anonymous wrote:
> > 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?
>
> only if you admit that its a threat...ooops too late...seriously though
> the secret servise doesnt have a very good sense of hummer when it comes
> to that sort of thing...(although the chances of them coming after you is
> still slim)
>
> --Hawkhaven
>
Do we even know which government he is talking about. He could
be a albanian sending email to the Yougoslovian government.
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
------------------------------
From: "Alberty Pascal" <pal@nospam*bsb.be>
Subject: Search for Certificate Servers
Date: Tue, 4 May 1999 17:31:27 +0200
Hi,
I'm searching for a good certificate server.
I know Microsoft and Netscape ones. I know that RSA'll launch Kone soon too.
Any others ?
TIA
--
======================================================================
pal@bsb*nospam.be
Please remove *nospam if you want to send me a mail
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO
Date: Tue, 04 May 1999 13:56:08 GMT
In article <[EMAIL PROTECTED]>,
mok-kong shen <[EMAIL PROTECTED]> wrote:
> SCOTT19U.ZIP_GUY wrote:
> >
>
> >
> > AGAIN IT IS DUMB TO HAVE AN EOF FOR COMPRESSION since the attacker
> > can rule out many keys since only the one that lead to your EOF would
> > be the correct ones. IS THIS TO HARD FOR YOU TO GRASP? YES OR NO?
>
> I can't understand why do you have so much against using one more
> symbol. If I write only in the alphabet of 26, it can happen that
> I have to use 'z'. But maybe I could use some roundabout way to avoid
> the use of 'z' and agree with my partner that 'z' ends my message
> and everything that follows is rubish just to fool the analyst.
> Do you have something against my using 'z' as EOF this way?
What you fail to consider is that the so-called enemy knows every thing
about the compression method. Let us say that your compression method
writes a Z only as the end of file symbol. You encrypt the file and send
it. Your enemy intercepts the message. And tries various keys. Suppose
the candidate one he looks out does not contain your "Z" symbol. Now
the enemy rejects that as a candidate message. So the very fact that
there is no "Z" in the file he got by guessing a key is information.
Look I have anwsered you questions. When you asked a yes or no. I
would like anwsers from you. But you don't want anwsers or understanding
why can't you see the obvious. Try to seperate compression from encryption
if you can. If you can don't you see that when a file is compressed
it shoould have no extra information. Do you understand that when the
enemy guesses a key the file that he has to examen must be uncompressable
and recompressabe to the same file. DO YOU UNDERSTAND THIS YES OR NO
AGAIN YES OR NO? IF you don't understand write back when you do I
have repeatedly tried to communicate this to you. But you don't seem
to have the logic background to understand the obvious.
David A. 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
------------------------------
From: mok-kong shen <[EMAIL PROTECTED]>
Subject: Re: Fast random number generator
Date: Tue, 04 May 1999 09:37:05 +0200
John Savard wrote:
>
> [EMAIL PROTECTED] wrote, in part:
>
> >Also given a deck of m n-bit words does anyone know a good shuffle algorithm?
>
> Depends what you mean by good.
>
> If one uses a generator of good random numbers much larger than m, one can of
> course use the classical shuffle algorithm to guarantee that all shuffles are
> equally likely:
>
> bottom = m ;
> choices = m ;
> For top = 1 to m-1 :
> { choose a random number, N, between 1 and choices;
> if N is not equal to 1 :
> { swap List(top) and List(top+N-1) ;
> }
> }
>
> When one is generating random integers from 1 to m, though, then if one wants
> a good shuffle though not necessarily a perfect one, one has to fiddle around
> a bit. Running RC4 for a while is, I suppose, one way to do it.
>
> In my block ciphers Quadibloc II and Quadibloc III, I used a scheme which
> satisfied me, after I couldn't find anything out there that I liked. Maybe
> the method I use in them will appeal to you as well, although it's somewhat
> elaborate.
>
> To complement the English-language description of the method I use on my web
> site, at
>
> http://members.xoom.com/quadibloc/co040705.htm
>
> here's some pseudocode for the same method. This just shows the method I use
> to generate one permutation: I generate S-box S8 by generating three of these
> permutations, thus ensuring near-perfect randomness.
>
> USED, UNUSED, and EMPTY are flags, -1 can be used for them, so they won't
> conflict with the numbers also stored in these arrays.
>
> * Initialize arrays
>
> SourceNumbers[0..255] = 0..255 ;
> ShuffledResult[0..255] = UNUSED ;
> Duplicates[0..255] = EMPTY ;
> DuplicatePonter = 0 ;
>
> * First phase: ShuffledResult is to be largely identical to the
> * first 256 random numbers, except that it can't have any number
> * appearing in it twice. So, try to fill it from those numbers
> * as far as possible.
>
> For counter = 0 to 255 :
> { choose a random number, N, between 0 and 255 ;
> if SourceNumbers[ N ] = USED :
> { Duplicates[ DuplicatePointer ] = N ;
> increment DuplicatePointer ;
> }
> else
> { SourceNumbers[ N ] = USED ;
> ShuffledResult[ counter ] = N ;
> }
> }
>
> * Now, see how many duplicates there were in the first 256 random numbers.
> * If there were 2 or fewer, proceed immediately to generating the final
> * random shuffle.
Could you briefly say the relative merits of the classical shuffling
and your method? How do you determine whether the shuffle is good
or less good? Any quantitative measure?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Chris Yearsley)
Subject: Embarrassing question about Blowfish
Date: Tue, 04 May 1999 16:06:28 GMT
Reply-To: [EMAIL PROTECTED]
I'm planning to implement Blowfish, specifically cfb64 mode from Eric Young's
code.
I'm having problems understanding the use of the initialisation vector.
Suppose I've loaded the IV with 8 bytes from a unique sequence, and called the
encrypt routine. What 's my 'cyphertext'? Particularly if the plaintext is
short (5 or 6 chars, say)?
Is the cyphertext all the 8 bytes now in the IV, catenated with the cyphertext
generated from the encryption routine? Or, do I look at 'n' which measures how
far through IV you are, and use the first 'n' bytes from IV and then the
cyphertext?
Similarly, on decryption, do I need to slice the first (8? variable?) bytes
from the cyphertext and make them the IV?
I've stusied the code and Schneier's 'Applied Cryptography' but neither seem
to make this clear. Applied Crypto suggests loading the IV with a sequence -
fine, but it doesn't say what you should do with it afterwards!
(I'm planning to encrypt many 4-6 character strings for database storage.)
--
Chris Yearsley
[EMAIL PROTECTED]
------------------------------
** 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
******************************
