Cryptography-Digest Digest #334, Volume #11 Wed, 15 Mar 00 01:13:01 EST
Contents:
Question about Blowfish source code in "Applied Cryptography" (Night Heir)
Re: Q: Twofish' S-Boxes (David A. Wagner)
Re: how to introduce hs students to cryptography (wtshaw)
Re: Improvement on Von Neumann compensator? (Guy Macon)
Re: NIST, AES at RSA conference (Terry Ritter)
Re: Improvement on Von Neumann compensator? (Guy Macon)
Re: Improvement on Von Neumann compensator? (Guy Macon)
Re: how to introduce hs students to cryptography ("Steven Alexander")
Re: sci.crypt.applied ("Trevor L. Jackson, III")
Re: how to introduce hs students to cryptography ([EMAIL PROTECTED])
Re: Improvement on Von Neumann compensator? (Terry Ritter)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Night Heir)
Subject: Question about Blowfish source code in "Applied Cryptography"
Date: 15 Mar 2000 03:30:43 GMT
In the Blowfish algorithm source (I have the Second Edition) on page 654, Mr
Schneier presents the main function for his sample code. The excerpt is:
void main(void) {
blf_ctx c;
char key[]="AAAAA";
unsigned long data[10];
int i;
for(i=0;i<10;i++) data[i] = 1;
blf_key(&c,key,5)
blf_enc(&c,data,5)
blf_dec(&c,data,1)
blf_dec(&c,data+2,4)
..... and so on
}
I understand that blf_key performs initialization for the encryption and that
blf_enc encrypts 5 bytes of data. What I do not understand is why the
decryption in blf_dec has been performed in two parts one consisting of 1 byte
and the second consisting of 4 bytes. Please excuse any errors in my
translation of the source code but it should serve this purpose. Any input
would be greatly appreciated.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Q: Twofish' S-Boxes
Date: 14 Mar 2000 18:53:00 -0800
In article <8alti3$434$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
> The box I am referring to is a combination of the four s-boxes and the columns
> of the MDS matrix. My question should read if it is true that the g-function
> is not bijective and why not?
If I understand your question correctly, yes, it is bijective.
Why? It may be written as the sequential composition of two
functions: (1) the four parallel 8-to-8 S-boxes; and (2) the
MDS matrix (32-to-32). Each of those two transformations are
bijective. (Each S-box is bijective; the MDS matrix is bijective.)
The composition of bijective functions is bijective, so the
whole thing is bijective.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: how to introduce hs students to cryptography
Date: Tue, 14 Mar 2000 21:13:35 -0600
In article <8allmf$rfo$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> I want to design one or two lessons for 12th grade students majoring in
> computer science, that will introduce them to the basic concepts,
> problems, and ideas of cryptography. The activity can include anything
> from a computer lab session to group activity or perhaps even a
> cryptosystem competition of some sort.
> If you have any creative, engaging, interesting ideas please share them
> with me. Where would you start? what do you think is most important?
> what should my goals be?
>
I suggest that you prepare some simple cipher program, explain the cipher
involved, how to use it if you know the key, and solve it if you don't.
Then, show use a brute force solving program to solve it that way. It
does not need to be difficult, something like a railfence is sufficient:
imse an et lcssip ettn htectdhh ifei rti msltsnctw srpw tea ecpehyeee ayirnh
Rails = 4; Start = 1
isih mi mp sylest test ennechat tewe ncs artedpywh thti eil fareecicn prsteh
Rails = 4; Start = 2
sthi si im yspmel etts tsennehc etta ewa scntrypde hwit hti erafleenc icrphe
Rails = 4; Start = 3
this is my simple test sentence that was encrypted with the railfence cipher
Rails = 4; Start = 4
hisi im ys pmelet tsts ennehcet taew asc ntrypdehw itht ier afleencic rphets
Rails = 4; Start = 5
msii sy lp metest stne cnehtewt aesa rcn tpywdehti ehti are flecnpicr ehhtsi
Rails = 4; Start = 6
siim ys pm eletts tsen nehcetta ewas cnt rypdehwit htie raf leencicrp hetsih
--
Imagine an internet on an up and up basis, where there are no subversive techniques to
rob a person of their privacy or computer
functionality, no hidden schemes used to defraud anyone. :>)
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Improvement on Von Neumann compensator?
Date: 14 Mar 2000 22:59:47 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Scott Nelson)
wrote:
>Yes, measuring the total time between events is much better
>than just using the least significant bit (a.k.a. latching
>an oscillator.)
>
>If you measure time with infinite precision, and make the same
>ridiculous independence assumptions that you must for the
>Von Neumann compensator to work,
>then this will produce unbiased bits.
>If time is measured with finite precision,
>then it's necessary to reject equal length timings,
>but it will then theoretically produce unbiased bits.
Would it not also answer Mike Rosing's observation that "The Von
Neumann method will stop sending output if the system locks up
and this proposal won't."?
>However, it's exceptionally unlikely that you are dealing
>with actual independent events. Even radio-active decay
>is dependant on the size of the source. Each event reduces
>the size of the source, so there is a slight bias for the
>second event taking longer. But compared with other sources
>of error, this bias is insignificant.
This assumes that the length between events is related to the
amount of atoms left undecayed. That assumption is not always
true. Alpha emitters have a length between decay events at
the is proportional to the exposed surface (the alpha particles
generated in the interior are blocked). Potassium decays into
argon, so a potassium sample in an argon atmosphere will lose
mass but still remain 100% potassium. combine the two and
you can make a 6 inch disk of potassium in an argon atmoshere
with a detector 0.01 inch from the center - you have a system
that has the same rate of decay events at the detector even
though the potassium is shrinking (until the disk gets too
thin and holes appear). Possible in theory, but not worth
doing in real life.
Hmmm. how about a von neumann compensator to remove such
residual bias?
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: NIST, AES at RSA conference
Date: Wed, 15 Mar 2000 03:59:55 GMT
On Tue, 14 Mar 2000 18:50:45 -0000, in <OzeTulij$GA.214@cpmsnbbsa02>,
in sci.crypt "Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
>I was not in any way attempting to state that a cipher
>offered authentication. If you look at PKCS #1 you will find
>that it had to be rewritten for just such a reason.
>
>Let's take a fairly simple case (where I am making up all
>the numbers, and haven't done any math).
>Using addition mod 26 as a cipher (because I can compute it
>easily)
>Original plaintext: abcdefghijklmnopqrstuvwxyz
>Original Key: zyxwvutsrqponmlkjihgfedcba
>Ciphertext: aaaaaaaaaaaaaaaaaaaaaaaaaa
>New Plaintext: someworthlessstuffImadeup
>New Key (which I substitute for the original key):
>something, it exists, I just didn't feel like computing it
>New Ciphertext: aaaaaaaaaaaaaaaaaaaaaaaaaa
>By having a person sign the ciphertext, based on them seeing
>the original plaintext and key, I can substitute my new
>plaintext, and no matter what signature scheme you use, I
>can forge a message. If you instead sign the plaintext, I
>must attack the signature scheme instead of the cipher or
>the signature.
First of all, no cipher system could be called practical without
having some form of message authentication. Certainly it is necessary
to automatically check for use of the wrong key, and transmission
errors may occur and need to be detected.
Next, it is of course true that simple additive stream cipher schemes
without authentication can be fooled if someone knows both the
plaintext and ciphertext. So don't allow that.
These areas of weakness simply do not exist in a properly designed
system. Complaining about them is not a complaint about the essence
of the system, but rather a particular design and implementation.
While it is not exactly trivial, it is not "rocket science" either.
Stuff like this is required in *any* cipher system, and when not
present similar complaints can be made. It has nothing to do with
multiciphering stacks or dynamic cipher changes per se.
Cipher systems which change ciphers must coordinate cipher changes on
both ends. It would be insane to do this as unciphered plaintext.
The opponents have no ability to force particular ciphers by changing
the ciphertext because changed ciphertext will be detected.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Improvement on Von Neumann compensator?
Date: 14 Mar 2000 23:08:56 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul Koning) wrote:
>However, the practical story is a whole lot more complicated.
>It's a bit like one time pad: wonderful in theory but not in
>the real world. If you build a physical randomness source, you
>have to start with a source like the quantum effects, but in
>addition you have to do a LOT of work to ensure that you weed
>out sources of bias. For example, you wouldn't want your
>"thermal noise source" to become highly predictable because you
>happened to set up your computer next door to a radio transmitter...
Fourmilab describes a method that seems to avoid such biases.
see [ http://www.fourmilab.ch/hotbits/ ] for an overview and
[ http://www.fourmilab.ch/hotbits/how.html ] for details.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Improvement on Von Neumann compensator?
Date: 14 Mar 2000 23:16:02 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry Ritter) wrote:
>
>
>On Tue, 14 Mar 2000 19:41:52 GMT, in
><[EMAIL PROTECTED]>, in sci.crypt
>[EMAIL PROTECTED] (Scott Nelson) wrote:
>
>>[...]
>>Even radio-active decay
>>is dependant on the size of the source. Each event reduces
>>the size of the source, so there is a slight bias for the
>>second event taking longer. But compared with other sources
>>of error, this bias is insignificant.
>
>Recently I tried to use a Geiger counter to produce random values,
>only to find that the event rate seemed to vary much more than I
>expected. With the tube positioned close to a lantern mantle, the
>event rate would start out high, then decrease almost to zero over
>time, or sometimes slow down and then start up again repeatedly.
>
>Some experimentation showed that the internal HV supply (a 5V -> 500V
>flyback inverter) was drifting and even *cycling*, probably due to a
>lower than expected source voltage. Geiger tubes are designed to have
>a "plateau region" where applied voltage does not affect sensitivity
>much, but voltage always does affect sensitivity somewhat. And if the
>voltage gets lower than the plateau, sensitivity drops off a cliff.
>
>The thing is, the device gave no indication that it was not producing
>the correct HV -- it just had decreasing or cyclic sensitivity. And
>in that respect, of course, the *reported* event rate was somewhat
>predictable, even with a radioactive source.
You also have to either use a source with a lower rate than a
typical mantle has or give the geiger counter a rest.
If you do a thought experiment of measuring your lousy source
the way Fourmilab does, you will realize that you would have
still recieved an unbiased and random bit stream...
see [ http://www.fourmilab.ch/hotbits/ ] for an overview and
[ http://www.fourmilab.ch/hotbits/how.html ] for details.
------------------------------
From: "Steven Alexander" <[EMAIL PROTECTED]>
Subject: Re: how to introduce hs students to cryptography
Date: Wed, 15 Mar 2000 04:38:18 GMT
Your goals should be to give them enough to be aware of the subject and to
go further on their own if they are interested and willing. Give them a
handout on pen and paper ciphers before the first lecture. Start by
answering questions and then show some reasons why they are weak(often
because computers can break them with brute force). Then tell them about
modern ciphers. Use DES as an example, there is more information available
about it than anything else. Explain key lengths and why you can't brute
force 2^128 keys. Mention the AES contest. Describe RSA for them, the math
really isn't that hard, unlike the factoring algorithms. Explain confusion
and diffusion to them. Tell them where they can get more information. Use
scenarios if you can, spy vs. spy will get their attention.
For their further enjoyment:
Applied Cryptography, by Bruce Schneier--perhaps the best cryptography
reference for programmers
Handbook of Applied Cryptography, by Alfred J. Menezes, Paul C. vanOorschot,
and Scott A. Vanstone--a hard read, they should read this second if they are
serious about the subject.
http://www.certicom.com/ecc/ This page has an introduction to Elliptic
curves, the basic math isn't that hard and they're kinda fun.
[EMAIL PROTECTED] wrote in message <8allmf$rfo$[EMAIL PROTECTED]>...
>I want to design one or two lessons for 12th grade students majoring in
>computer science, that will introduce them to the basic concepts,
>problems, and ideas of cryptography. The activity can include anything
>from a computer lab session to group activity or perhaps even a
>cryptosystem competition of some sort.
>If you have any creative, engaging, interesting ideas please share them
>with me. Where would you start? what do you think is most important?
>what should my goals be?
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
------------------------------
Date: Tue, 14 Mar 2000 23:51:49 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: sci.crypt.applied
Paul Rubin wrote:
> In article <[EMAIL PROTECTED]>,
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >In my understanding, the reason for creation of a subgroup is
> >normally because a certain subfield has very often been discussed
> >and has occupied a very significant portion of the whole traffic
> >such that it would cause some inconvenience to those who have less
> >interest in that subfield, i.e. the reason is not because certain
> >subfields have almost never beed touched upon.
>
> I agree with this. I think we should make a subgroup
> (sci.crypt.secure?) for provably secure cryptography systems such as
> one-time pads and truly random number generators. Discussions of
> advanced ciphers such as SCOTT16U could also go there, as could
> discussions of NP-completeness. Sci.crypt would be left for, um, more
> conventional topics like AES, public key implementation, etc. Then
> the more brilliant of the leading-edge types could use
> sci.crypt.secure and the rest of us would stick with sci.crypt. Sound
> like a plan?
Sounds like a plot. You probably want to read sci.crypt without laughing. Shame on
you. :-)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: how to introduce hs students to cryptography
Date: Wed, 15 Mar 2000 04:43:41 GMT
In article <8allmf$rfo$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I want to design one or two lessons for 12th grade students majoring in
> computer science, that will introduce them to the basic concepts,
> problems, and ideas of cryptography. The activity can include anything
> from a computer lab session to group activity or perhaps even a
> cryptosystem competition of some sort.
> If you have any creative, engaging, interesting ideas please share them
> with me. Where would you start? what do you think is most important?
> what should my goals be?
>
The RSA algorithm is the primary basis for
modern public key cryptography but cannot be
understood without an introduction to modular
arithmetic (the foundation of the algorithm).
There is an easy- to- read introductory paper
on public key cryptography (RSA) which
explains modular arithmetic at a level
suitable for high school students (even middle
school students). You can see this paper at:
http://arXiv.org/abs/cs/9903001
Although this paper is intended for
undergraduates, it might be a useful and not-
too- difficult tutorial for high school
students.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Improvement on Von Neumann compensator?
Date: Wed, 15 Mar 2000 05:10:12 GMT
On 14 Mar 2000 23:16:02 EST, in <8an2q2$[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] (Guy Macon) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry Ritter) wrote:
>>
>>
>>On Tue, 14 Mar 2000 19:41:52 GMT, in
>><[EMAIL PROTECTED]>, in sci.crypt
>>[EMAIL PROTECTED] (Scott Nelson) wrote:
>>
>>>[...]
>>>Even radio-active decay
>>>is dependant on the size of the source. Each event reduces
>>>the size of the source, so there is a slight bias for the
>>>second event taking longer. But compared with other sources
>>>of error, this bias is insignificant.
>>
>>Recently I tried to use a Geiger counter to produce random values,
>>only to find that the event rate seemed to vary much more than I
>>expected. With the tube positioned close to a lantern mantle, the
>>event rate would start out high, then decrease almost to zero over
>>time, or sometimes slow down and then start up again repeatedly.
>>
>>Some experimentation showed that the internal HV supply (a 5V -> 500V
>>flyback inverter) was drifting and even *cycling*, probably due to a
>>lower than expected source voltage. Geiger tubes are designed to have
>>a "plateau region" where applied voltage does not affect sensitivity
>>much, but voltage always does affect sensitivity somewhat. And if the
>>voltage gets lower than the plateau, sensitivity drops off a cliff.
>>
>>The thing is, the device gave no indication that it was not producing
>>the correct HV -- it just had decreasing or cyclic sensitivity. And
>>in that respect, of course, the *reported* event rate was somewhat
>>predictable, even with a radioactive source.
>
>You also have to either use a source with a lower rate than a
>typical mantle has or give the geiger counter a rest.
I don't see a problem: When operating properly, the counter easily
handles the high event rate. I expect the tube itself should handle
orders of magnitude higher rates.
>If you do a thought experiment of measuring your lousy source
>the way Fourmilab does, you will realize that you would have
>still recieved an unbiased and random bit stream...
If the probability of events changes, that influences the expectation
of which pair of events is likely to have the most delay. The result
is specifically not "unbiased." Why would you think it was?
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
** 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
******************************
