Cryptography-Digest Digest #291, Volume #13 Fri, 8 Dec 00 05:13:01 EST
Contents:
Toy cipher question (Benjamin Goldberg)
Re: Wei Dai Crypto++ and PGP SDK ("NoEmail")
Enigma and math ("kihdip")
Re: Enigma and math (Scott Contini)
Re: Math background required for Cryptology ? ("NoEmail")
Re: Enigma and math (Mark VandeWettering)
PKCS#1 v2.1 ("Alain")
Re: [Question] Generation of random keys (Benjamin Goldberg)
Re: Hole in MCRYPT_TripleDES ("NoEmail")
Re: [Question] Generation of random keys (David Schwartz)
Re: weten we die PIN? (David Dylan)
Re: PKCS#1 v2.1 ("Jakob Jonsson")
Re: Math background required for Cryptology ? (Scott Craver)
----------------------------------------------------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Toy cipher question
Date: Fri, 08 Dec 2000 06:35:02 GMT
I'd like to know what kind of attacks would be used on a toy cipher with
the following psuedocode:
uint64 encrypt( uint64 data, uint64 * key ) {
data += *key++;
// prewhiten
for( int i = 0; i < ROUNDS; ++i ) {
uint8 x[8] = (uint8[8])data;
uint8 y[8];
for( int j = 0; j < 8; ++j )
x[j] *= "x**16" in GF(2^8) with polynomial p[j];
// linear transform
for( int k = 0; k < 8; ++k )
y[k] |= ((x[j]>>k)&1) << j;
// after doing a linear transformation on the
// rows of the 8x8 matrix of bits, transpose
// x and store it in y.
for( int j = 0; j < 8; ++j )
y[k] = AES_sbox[ y[k] ];
// do a nonlinear transform on the rows of 8x8 bit
// matrix y
data = (uint64)y;
data += *key++;
// add in the round key.
}
return data;
}
I know noone is going to do, say, differential analysis for me, but...
I'd like to know, can it be done? How would I go about finding
impossible differentials? Also, can linear analysis work on something
like this? Some other attacks? Obviously not slide attack unless there
were repeated round keys, but surely there's some attack better than
impossible differentials?
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: "NoEmail" <[EMAIL PROTECTED]>
Subject: Re: Wei Dai Crypto++ and PGP SDK
Date: Fri, 8 Dec 2000 08:45:38 +0200
Reply-To: "NoEmail" <[EMAIL PROTECTED]>
Both are excellent sources for any programmer.
PGP is very popular, has a big following and is pure C , you may find the
code easier to understand.
Probably the best way to decribe it is an application with source.
If you crazy about C++ then Wei is your man.
To me Wei's lib is technology with source. No fancy front end but solid
technology.
Really depends what you want to do. If you trying to lock something up
quickly and knock out a quick app then the shear size and complexity of
these two applications should act as a gentle warning.
If you dont know C, oh boy!
If you a VB programmer trying to lock something up then have a look at this
http://www.kewlstuff.co.za/
Its windows specific, hides technical detail, and is an unusual approach to
the science.
I like it, but its not in the same league as the above. You will be able to
write an app in one evening though.
Good luck
P.C. Teo <[EMAIL PROTECTED]> wrote in message
news:90n1si$phu$[EMAIL PROTECTED]...
> Can anyone analyze the advantage and disadvantage of these two crypto
> library?
>
> Which is better?
>
> Thanks
>
>
------------------------------
From: "kihdip" <[EMAIL PROTECTED]>
Subject: Enigma and math
Date: Fri, 8 Dec 2000 08:04:34 +0100
Just a qiuck question on the Enigma:
Did the machine have an encrypt/decrypt setting, or was the 'mathematical
function' infact an involution. (a->d, d->a, e->p, p->e etc. ) ??
Thanks in advance
Kim
------------------------------
From: [EMAIL PROTECTED] (Scott Contini)
Subject: Re: Enigma and math
Date: 8 Dec 2000 07:08:07 GMT
In article <90q0k0$cgo$[EMAIL PROTECTED]>,
kihdip <[EMAIL PROTECTED]> wrote:
>Just a qiuck question on the Enigma:
>
>Did the machine have an encrypt/decrypt setting, or was the 'mathematical
>function' infact an involution. (a->d, d->a, e->p, p->e etc. ) ??
>
>Thanks in advance
>Kim
>
>
It was an involution, because of the reflector rotor.
Scott
------------------------------
From: "NoEmail" <[EMAIL PROTECTED]>
Subject: Re: Math background required for Cryptology ?
Date: Fri, 8 Dec 2000 09:13:38 +0200
Reply-To: "NoEmail" <[EMAIL PROTECTED]>
Hopefully you find this useful advice
If you want to learn crypto in order to create new algs etc.
You going to have to be a whiz of mammoth proportions, years dude!, and go
do a majors.
If you like most normal programmers accept the work of others and know that
any new alg is treated with great skepticism regardless of how brilliant it
is, then the maths aint too bad, it works, just use it.
Then a simple little book like Bruce Schneiers will probably get you going.
Ryan J Schave <[EMAIL PROTECTED]> wrote in message
news:BhgX5.134660$[EMAIL PROTECTED]...
> I have recently become interested in cryptology. Unfortunately my
knowledge
> of math is pretty weak. I imagine this small detail will hold me back
from
> learning everything I can about cryptology. I have pulled out my old math
> books from college and looked at the TOC of each of them.
>
> What topics in math should I have a firm grasp of before I can expect to
get
> the most of cryptology? Obviously many topics in math are based on other
> topics, but I don't want to spend time teaching myself stuff that I won't
> use in my study of cryptology.
>
> Hope this makes sense.
>
> Ryan
>
>
>
>
------------------------------
From: [EMAIL PROTECTED] (Mark VandeWettering)
Subject: Re: Enigma and math
Date: Fri, 08 Dec 2000 07:53:43 GMT
On Fri, 8 Dec 2000 08:04:34 +0100, kihdip <[EMAIL PROTECTED]> wrote:
>Just a qiuck question on the Enigma:
>
>Did the machine have an encrypt/decrypt setting, or was the 'mathematical
>function' infact an involution. (a->d, d->a, e->p, p->e etc. ) ??
The function computed by the enigma was symmetric, so there was no
difference between encryption and decryption.
>Thanks in advance
>Kim
--
/* __ __ __ ____ __*/float m,a,r,k,v;main(i){for(;r<4;r+=.1){for(a=0;
/*| \/ |\ \ / /\ \ / /*/a<4;a+=.06){k=v=0;for(i=99;--i&&k*k+v*v<4;)m=k*k
/*| |\/| | \ V / \ \/\/ / */-v*v+a-2,v=2*k*v+r-2,k=m;putchar("X =."[i&3]);}
/*|_| |_ark\_/ande\_/\_/ettering <[EMAIL PROTECTED]> */puts("");}}
------------------------------
From: "Alain" <[EMAIL PROTECTED]>
Subject: PKCS#1 v2.1
Date: Fri, 8 Dec 2000 08:57:51 +0100
Hi,
RSA PKCS#1 v2.1 has been in a draft version from a long time. I would like
to know whether or not it is intended to become the standard or not and if
so what is the expected date of that evenement.
Thank you for your response
Alain
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: [Question] Generation of random keys
Date: Fri, 08 Dec 2000 08:08:31 GMT
David Schwartz wrote:
>
> Benjamin Goldberg wrote:
>
> > Umm, Alan is saying that it's impossible to algorithmically perform
> > a real-world physical act. Code can simulate a coin flip, but not
> > actually do one. Anyone who believes that they can algorithmically
> > generate random number is in a state of sin. (Name that quote!)
>
> By what definition of "random" is it impossible to
> algorithmically convert non-random numbers into random ones?
My definition of a random source is one that has finite or zero state,
and produces a stream of values that never degenerates into a
continually repeating cycle.
However, I do not claim that all random sources are equally good. Id
est, do I claim that every bit of output must have 1 bit of entropy for
the source to be random.
Any algorithm which starts with a state, and recieves no exterior inputs
is a non-random number source. An algorithm which *filters* data,
however, *can* output random numbers, provided that a random stream is
input it to it, and it doesn't remove the randomness from that stream.
Note that can does not mean will. If an algorithm is fed a high quality
random stream, and throws it away and outputs 0s, it's not going to be
random. [This example is of course an extreme case]
A stream which contains any randomness is random. A stream which
doesn't contain randomness is non-random.
> You would have to accept biased numbers as random, no matter
> how heavy the bias, because you can algorithmically remove bias.
Yes and no. I can accept biased as random (low quality random, but
still random), but that does not mean that an algorithmic removal of
bias necessarily removes the property of randomness. However, using
*just* an algorithm (and a finite sized seed) cannot produce random
numbers.
> You would have to accept correlated numbers as random, because
> you can algorithmically remove correlation.
Again, although I can accept correlated numbers as random, this does not
mean that they are high quality random. Also, using an algorithm to
remove correlation does not remove randomness. It is only using an
algorithm to *produce* numbers that produces non-random values.
> In fact, you would have to accept practically anything that
> was to any extent unpredictable as "random". Because unpredictability
> is the _only_ thing you can't create algorithmically.
Why yes, you are exactly correct.
We can, algorithmically, convert a low quality random stream into a
higher quality random stream, with a reduced number of bits/second, but
we can't algorithmically produce random numbers without having a random
input stream.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: "NoEmail" <[EMAIL PROTECTED]>
Subject: Re: Hole in MCRYPT_TripleDES
Date: Fri, 8 Dec 2000 10:05:58 +0200
Reply-To: "NoEmail" <[EMAIL PROTECTED]>
Do yourself a favor and just hash the thing.
Randy Sofia <[EMAIL PROTECTED]> wrote in message
news:90enfm$b93g$[EMAIL PROTECTED]...
> Listen to this... I'm writing a backend for a site that requires tight
> security... being a novice to cryptography I decided to use
MCRYPT_TripleDES
> and changing the key each hour depending on the hour.. so for example if
its
> 7:00 the key would be "19 2000-12-03cheese" if its 8:00 the key would be
"20
> 2000-12-03cheese" cheese is the password, so the password is also used in
> the key.
>
> During my testing phases I noticed that sometimes two different hours
would
> give me the same encrypted password. Let me show you...
>
> I'm encrypting the password "cheese" the following is a long list of
> encrypted versions of cheese -- the key used to encrypt it:
>
> 81dc31f6d6139ed2 -- 19 2000-12-03cheese
> 81dc31f6d6139ed2 -- 18 2000-12-03cheese
> bcd7f6e6f2986639 -- 17 2000-12-03cheese
> bcd7f6e6f2986639 -- 16 2000-12-03cheese
> eab3a333ef5051eb -- 15 2000-12-03cheese
> eab3a333ef5051eb -- 14 2000-12-03cheese
> c93d913fc87e6ec8 -- 13 2000-12-03cheese
> c93d913fc87e6ec8 -- 12 2000-12-03cheese
> dca38d8d8eaf50b4 -- 11 2000-12-03cheese
> dca38d8d8eaf50b4 -- 10 2000-12-03cheese
> 02c39858203aeb6f -- 9 2000-12-03cheese
> 02c39858203aeb6f -- 8 2000-12-03cheese
> 5d028682eb17fb30 -- 7 2000-12-03cheese
> 5d028682eb17fb30 -- 6 2000-12-03cheese
> b52cfd438d53662b -- 5 2000-12-03cheese
> b52cfd438d53662b -- 4 2000-12-03cheese
>
> Now take a look at that... Why does the encypted password recur even
though
> the key changes by 1?
>
> In order to fix this I took the square of the time rather then the time
> itself. But still, why would it recur even though I incremented a number
in
> the key by 1? Isn't that odd?
>
> Thanks,
> ~Randy
>
>
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: [Question] Generation of random keys
Date: Fri, 08 Dec 2000 00:19:08 -0800
Benjamin Goldberg wrote:
> David Schwartz wrote:
> > Benjamin Goldberg wrote:
> > > Umm, Alan is saying that it's impossible to algorithmically perform
> > > a real-world physical act. Code can simulate a coin flip, but not
> > > actually do one. Anyone who believes that they can algorithmically
> > > generate random number is in a state of sin. (Name that quote!)
> > By what definition of "random" is it impossible to
> > algorithmically convert non-random numbers into random ones?
> My definition of a random source is one that has finite or zero state,
> and produces a stream of values that never degenerates into a
> continually repeating cycle.
I'm not at all clear on what you mean by "finite or zero state". It
sounds to me like this would include lots of things we don't normally
consider random.
> However, I do not claim that all random sources are equally good. Id
> est, do I claim that every bit of output must have 1 bit of entropy for
> the source to be random.
>
> Any algorithm which starts with a state, and recieves no exterior inputs
> is a non-random number source. An algorithm which *filters* data,
> however, *can* output random numbers, provided that a random stream is
> input it to it, and it doesn't remove the randomness from that stream.
Neither of these things are the issue. The issue is whether an
algorithm can convert an unlimited quantity of input data that is not
random into an unlimited quantity of output data that is random. And I
submit that an algorithm _can_ unless by "random" you mean exactly the
same thing as "unpredictable".
> > You would have to accept biased numbers as random, no matter
> > how heavy the bias, because you can algorithmically remove bias.
>
> Yes and no. I can accept biased as random (low quality random, but
> still random), but that does not mean that an algorithmic removal of
> bias necessarily removes the property of randomness. However, using
> *just* an algorithm (and a finite sized seed) cannot produce random
> numbers.
You are missing my point. My point is that an algorithm that removed
bias would increase randomness.
> > You would have to accept correlated numbers as random, because
> > you can algorithmically remove correlation.
> Again, although I can accept correlated numbers as random, this does not
> mean that they are high quality random. Also, using an algorithm to
> remove correlation does not remove randomness. It is only using an
> algorithm to *produce* numbers that produces non-random values.
Again, I'm arguing the reverse. Using an algorithm to remove
correlation increases randomness. And the amazing thing is that you can
remove correlation _without_ decreasing the data rate.
> > In fact, you would have to accept practically anything that
> > was to any extent unpredictable as "random". Because unpredictability
> > is the _only_ thing you can't create algorithmically.
> Why yes, you are exactly correct.
> We can, algorithmically, convert a low quality random stream into a
> higher quality random stream, with a reduced number of bits/second, but
> we can't algorithmically produce random numbers without having a random
> input stream.
Actually, we can lagorithmically covert a low quality random stream
into a higher quality random stream with NO change in the bit rate.
Consider the following stream:
000000000000011111111111111111000000000000000001111111111111111111111100000000000000000011111111111111111
It's highly correlated. We can remove that correlation, and thus
improve the randomness like this:
000000000000010000000000000000100000000000000001000000000000000000000010000000000000000010000000000000000
Note that no reduction in bit rate occurs.
There are two things you can say about algorithms, however:
1) They can't create unpredictability.
2) They can't have more possible output values than they have possible
input value.
DS
------------------------------
From: [EMAIL PROTECTED] (David Dylan)
Crossposted-To:
alt.cracks.nl,alt.nl.telebankieren,nl.comp.crypt,nl.financieel.bankieren,nl.juridisch
Subject: Re: weten we die PIN?
Date: Fri, 08 Dec 2000 08:28:36 GMT
On 7 Dec 2000 22:09:58 GMT, John <[EMAIL PROTECTED]> wrote:
Hoi hoi,
>Geen van beiden, het wordt namelijk op de kaart zelf bijgehouden.
Dat is wel het meest logische vanuit een efficiency standpunt, maar is
het ook veilig? Inbreken in een banksysteem lijkt mij een end lastiger
dan op je gemak in een achterkamertje met een paar nerds de code op
een kaart uitdokteren... Of zie ik dat nu helemaal verkeerd?
Je verzamelt een paar kaarten waar je de PIN van weet, en kijk &
vergelijk... (simpel gezegd)...
Groetz.
DD.
--
Kijk eens op mijn community site:
http://www.grep.nu/beleggers
Of op mijn persoonlijke site:
http://www.xs4all.nl/~nobeard
------------------------------
From: "Jakob Jonsson" <[EMAIL PROTECTED]>
Subject: Re: PKCS#1 v2.1
Date: Fri, 8 Dec 2000 10:01:43 +0100
Hi Alain,
It is true that PKCS#1 v2.1 has been a draft for some time, and it will
remain so for another couple of months. Instead, a second draft (d2) of
PKCS#1 v2.1 superseding the current draft (d1) will be posted on our web
site (www.rsasecurity.com/rsalabs/pkcs) in a few weeks. The main update will
be a modified RSA-PSS scheme aligning with current standards efforts within
IEEE and ISO/IEC.
Jakob Jonsson
RSA Laboratories
"Alain" <[EMAIL PROTECTED]> skrev i meddelandet
news:90q58f$l5c$[EMAIL PROTECTED]...
> Hi,
>
> RSA PKCS#1 v2.1 has been in a draft version from a long time. I would like
> to know whether or not it is intended to become the standard or not and if
> so what is the expected date of that evenement.
>
> Thank you for your response
> Alain
>
>
------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Subject: Re: Math background required for Cryptology ?
Date: 8 Dec 2000 09:40:35 GMT
M.S. Bob <[EMAIL PROTECTED]> wrote:
>Scott Craver wrote:
>>
>> Information theory is often taught in electrical eng, and you're
>> better off taking some other signal processing courses too.
>> A course on signals and systems, a course on random processes,
>
>Why do you recommend signal processing? I'm curious, as never having
>taken a signals course.
Aside from direct applications such as steganography (or
analysis of pseudo-random sequences, say) signal processing is an
important prerequisite for a random processes course. I walked
into an EE department having never taking a signals course, and
hoo boy did I pay for that. Some basic intuition about transforms
and various domains for data (time vs. frequency) are extremely
helpful, and a background in random processes is subsequently an
important prerequisite for Information Theory.
=S
------------------------------
** 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
******************************
