Why IDEA is to weak for PGP
dave scott
This is a about good block encryption. First I would like to tell you
I am a retired scientific programmer. I have been doing assembly language
for over 25 years. I now am unemployed and do mostly C programming. I never
was good at typing or English but have always been good at science and
math.
1. How good is IDEA. In some ways it is very good and in others it is
very bad. It is bad in that the key is 128 bits in length. Folks its the
computer age. Wake up 128 bits suck. My first attempt to improve on it was
to make each of the 52 16 bit subblocks part of the key. This can not make
it worse. Even if it does not improve the code very much most people
who know nothing about mathematics think this might be easier to break.
This is dumb because if this long key easy to break one could pretend that
all the whole 52 bit subblocks are keys with the added advantage that if
part of key found they would automatically have other parts of some of the
52 subblock keys. So this is better. The question is why did the inventors
use such a short key. Here is an example that may explain why:
If one where encrypting a 16 bit word with XOR of another 16 bit word.
Then a 16 bit key is requires to represent the 2^16 possible mappings.
If one where encrypting a 16 bit word using another 16 bit word and doing
a multiply the way IDEA does multiply one would need a 16 bit word again to
represent each of the 2^16 possible mappings. Now I ask suppose some one
combines them by doing a XOR with 16 bit word, then a MUL with 16 bit word
like IDEA and another XOR with a 16 bit word. Does one need a 48 bit key
to describe this. Well for convenience you can use a 48 bits but there are not
2^48 combinations. since for example any time MUL is a one there many
redundant combination like in hex 0003 0001 0003 same as 0000 0001 0000.
It is for reasons like this that they may have chosen 128 bits.
2. How bad is 128 bits. It is so bad that again I have to give an example
if one is using 6 bits words (field data) then to have a 6 bit code for
the alphabet upper and lower and numbers 0-9 requires 62 representations
well adding ,.:; would more than exhaust the 64 representations available.
Now one could come up with a block encryption method that replaces each
symbol with another symbol. Forget block chaining for the moment. This
method of encryption is very old yet almost anyone can break it.
This is simple letter substitution. Believe it or not. with out feedback
or chaining this is as complicated as 6 bit encryption gets and it takes
a 296 bit encryption key to represent. no key with less bits covers the
complete 6 bit mappings that are possible. That is why 128 bits suck.
3. Can one improve on IDEA with out throwing it away besides using the
Unrolled version. When I first tried to analyze the unrolled IDEA which
has 832 bits. I wondered just what is the real key length. Which means
how many unique mappings are there for IDEA and what is the number of bits
that, that number represents. The first 4 16 bit words each have a 16 bit
key operation done on them. Since these are different independent characters
one can add the keys together on the first 4 operations this 64 so it least
in unrolled IDEA I know that the perfect key length has to be at least 64 bits
long. But in true IDEA I can't say that for sure, but I can say that it is at
most 128 bits. worse than a 6 bit substitution table. The quickest fix
to IDEA that would guarantee a real key length of over 3,000,000 bits is to
replace the first 4 subkeys and the functions where they are used with
mappings based on 954,037 bit keys for each of the 4 mappings.
4. How did IDEA get way with such a short key. The reason it got a way
with it is that simple 8 bit character substitution breaks down
because tables of letter frequencies for single characters readily available
since IDEA is 8 characters long one would needs different tables. The human
mind finds single characters easier to work with than 8 chars at a time.
Folks computers are getting faster and faster and 64 bit word widths are
getting to be around register size for faster computers. You are only fooling
your self if you think the NSA can not break IDEA. Of course it is also takes
more text to break it if done in 8 character chucks.
5. The worse thing about modern block computer encryption beside the small
keys sizes most people use is the method of chaining the blocks together.
1 reason IDEA is better than most blocks methods is that 8 characters are
chained together nicely. However the 64 bit blocks are chained together very
poorly with techniques the code breakers like people to use. They are so bad
that if one only has the middle third of a file but one has the key and
algorithm used you can recover the data. What this means for you, is that
the enemy to break your message needs to study only a small portion of it.
Good chaining for files should have 2 features not found in PGP's use
of IDEA. 1. The chaining should require the whole file error free before
it can be decoded. 2. It should be one way. By one way I mean if encoded
by going down a file. It should only be able to be decoded by looking at file
in one direction only. I like to use a compressed file with a variable
number of random bytes in front and back of file and then make 2 passes
through one in each direction with 2 different set of keys.
This means you can do to a whole file what IDEA did when it went from
one character to 8 characters.
6. Can simple IDEA be chained together to achieve this.
Yes you can chain IDEA but it is weak the key is short but I
will explain a simple way to do it. first think of the file as a set
of characters add random 8 bit characters to front and back of file
where the first and last charter not totally random but have bits representing
the number of random characters in front and back of file. now put first
8 characters in the IDEA 64 bit block and on output only write out first
character then use next character in file with the new 7 other characters
as input. Go through file reading one byte, write one byte, and using the
7 other new output characters as input to next block. when at last character
write out all 8 output characters to file. This output file can only be
decoded in reverse direction. what I like to do is add new random characters
top and bottom then use new key and go in reverse direction.
7. Is there a simple better way to chain like this while using a much
better method than IDEA. Yes we are trying to map eight bits which
requires a 1684 bit key for a complete mapping. IDEA only has 128 bits
so it can not do very many mappings. Here is a method that works much better
since is has a longer REAL KEY. First use a complete 16 bit mapping
based on a 954037 bit key. Then do like above example except use 2 8 bit
characters as input to first encryption block. On output only one character
goes out to temp file the second character out of block is feedback for next
block. Continue doing this for whole pass. Except on last pass output 2
character. This is a lot like the IDEA method except that 16 bit blocks
used for encryption instead of 64 bit blocks. However once both methods
have been used forward and backward this last method has many more
combinations and is based on complete mappings which IDEA is not.
8. To use the full real key all one has to do is create a mapping
based on value of key. Then use a lookup table for that mapping. It
is very fast once the table is built. for a single 16 bit key it would
take only 128k 8 bit bytes to store in memory.
Charles N. Johnson
dave scott <dsc...@ridgecrest.ca.us> wrote in article
<5b8nnt$n...@ash.ridgecrest.ca.us>...
> This is a about good block encryption. First I would like to tell you
> I am a retired scientific programmer. I have been doing assembly language
> for over 25 years. I now am unemployed and do mostly C programming. I >
never was good at typing or English but have always been good at science
and
> math.
> 1. How good is IDEA. In some ways it is very good and in others it is
> very bad. It is bad in that the key is 128 bits in length. Folks its the
> computer age. Wake up 128 bits suck.
[edited for brevity...]
With 128-bits in an IDEA key, there are ((2^128) - 1) different keys (the
key with all bits set to 0 doesn't encrypt), that means there are roughly
10^38 different keys. If you could test 10^12 keys per second, you would
still need about 10^9 years to have a 50/50 chance of finding the key.
Is there some other way to defeat IDEA other than brute force. I don't
know. Moreover, the people who might know ain't talking!
> You are only fooling your self if you think the NSA can not break IDEA.
I remain skeptical of claims about what the NSA can or cannot do.
Cheers--
Charles
dave scott
>In article <01bc001a$a7745520$d7c0...@i-charlej9.interramp.com>,
"Charles N. Johnson" <char...@mail.idt.net> wrote:
>> 1. How good is IDEA. In some ways it is very good and in others it is
>> very bad. It is bad in that the key is 128 bits in length. Folks its the
>> computer age. Wake up 128 bits suck.
>
>[edited for brevity...]
>
>With 128-bits in an IDEA key, there are ((2^128) - 1) different keys (the
>key with all bits set to 0 doesn't encrypt), that means there are roughly
>10^38 different keys. If you could test 10^12 keys per second, you would
>still need about 10^9 years to have a 50/50 chance of finding the key.
>
Sorry Charlie I don't think your good enough for Star Kiss yet.
You seem to lack a solid math background and completely missed the whole
point. First of all my friend IDEA does encrypt with a key of all zero's
and before you make a bigger fool of your self it is not the identity
transform it really does encrypt. By your logic if I took 8 bit ascii
and replaced it by substituting a different character for each character
it would take a 1684 bit key to discribe this. Hey I think 1684 is bigger
than 128. Yet this method is as old as the hills and only some one of your
mental ability would actually be dumb enough to use it. The fact is history
has proven 128 bits is far to small.
>Is there some other way to defeat IDEA other than brute force. I don't
>know. Moreover, the people who might know ain't talking!
>
>> You are only fooling your self if you think the NSA can not break IDEA.
>
>I remain skeptical of claims about what the NSA can or cannot do.
I remain open to but you remind me of the Japanese who thought they
so smart that there war codes could not be broken. Yet someone who could
not even speak Japanese broke it. The point is sir you can have massive keys
where each value represent true proven unique mappings. You do not have to
remember these because they can be encrytped by a single master key. My god
man let the machine do the dam work. Only a fool who has not stuided history
or noticed the progress of computers would feel safe with 128 bit key.
>
>Cheers--
>Charles
Charles N. Johnson
[edited for brevity...]
> Sorry Charlie I don't think your good enough for Star Kiss yet.
> You seem to lack a solid math background and completely missed the whole
> point.
See Schneier's book.
>
> I remain open to but you remind me of the Japanese who thought they
> so smart that there war codes could not be broken. Yet someone who could
> not even speak Japanese broke it. The point is sir you can have massive
keys
>
I said nothing of breaking codes, I replied about what is said (or not
said) about the NSA. If you feel IDEA is unsafe, you are quite free to use
something else. Please, by all means, post your code and see if it stands
the test of attack as well as IDEA has. As Schneier says about IDEA,
"Design a chip that can test a billion keys a second, and throw a billion
of them at the problem and it will still take 10^13 years--that's longer
than the age of the universe. An array of 10^24 such chips can find the key
in a day, but there aren't enough silicon atoms in the universe to build
such a machine. Now we're getting somewhere--although I'd keep my eye on
the dark matter debate."
Literally, dozens of people have published results about IDEA, and only one
person (Joan Daemen) has managed to find a weakness, and hers were keys of
the form (in hex) 0000 0000 0 0000 0000 000x xxxx x000 (you may select the
"x" as you wish). Using such a key "leaks" key material in the sense that
certain plaintext pairs guarantee the bit-wise XOR of the resultant
ciphertext pairs. According to Ms. Daemen, the probability of randomly
generating such a key is 2^96...I wouldn't be too worried about it. If you
are worried about it, simply XOR every sub-key with 0x0dae and be done with
it.
Does this mean that IDEA is immune, or "the best?" No, of course not. It
does means that many very bright people have attempted to subvert IDEA, and
all published attempts have failed. You want "completely safe?" Sure thing.
Use IDEA-3. Triply encrypt (using no weak keys) with IDEA, and expand the
number of rounds from 8 (each) to 32 (each).
Moreover, IDEA on machines who natural word length in 16 or 32 bits is fast
enough.
It is also very small. The IDEA module in PGP 2.6.3i compiles to less than
6K with MSCV C++ 4.2b. The C++ version I wrote is less than 8k.
And these are the three real criteria for such algorithms: small, fast, and
tough. As Schneier points out, making tough algorithms big and slow is easy
(he mentions DES --56 bit key DES-- with 512 rounds) as an example.
So, like I said, if you have something small, fast, and tough (and you get
to decide what "small," "fast," and "tough" mean) then post your code and
see how it stands up.
Cheers--
Charles
dave scott
The reason I responded the way I did was when you showed your complete
lack of knowledge by stating all zeroes was not a key. I guess you must
have got a little bit smarter since then. I am not going to argue how long
it takes to do a brute force search that is foolish. I did point out a full
mapping of 6 bits results in a key much longer than 128 bits. What I was
pointing out that you appearently did not understand is that other methods
can be used and have been used on systems with keys much longer than 128bits
>generating such a key is 2^96...I wouldn't be too worried about it. If you
>are worried about it, simply XOR every sub-key with 0x0dae and be done with
>it.
Oh now you are suggesting modifying IDEA well welcome to the club it needs
beefing up.
>Does this mean that IDEA is immune, or "the best?" No, of course not. It
>does means that many very bright people have attempted to subvert IDEA, and
>all published attempts have failed. You want "completely safe?" Sure thing.
>Use IDEA-3. Triply encrypt (using no weak keys) with IDEA, and expand the
>number of rounds from 8 (each) to 32 (each).
This is still weaker than my suggestions.
>It is also very small. The IDEA module in PGP 2.6.3i compiles to less than
>6K with MSCV C++ 4.2b. The C++ version I wrote is less than 8k.
>
>And these are the three real criteria for such algorithms: small, fast, and
>tough. As Schneier points out, making tough algorithms big and slow is easy
I would agree when I was on some of the earlier computers that had a max
memory size of 16k however the complete mapping that i was talking about
for 16 bits which has a real key of 954037 does take a second or 2 to make the
table and the table is 128k in size but it is a screamer it involves only
a look up table. For large files it would leave your IDEA in the dust.
You can check my math there might be an error. to calulare the number
of bits in a real key that covers all mappings. you need to know the
number of items being mapped. In this case it is 2 to the 16
I thought this was 65,536. next to get the number of mappings
is 65,536!. this is 65,536*65,535*65,534*....*3*2*1
lets just call this number X
then the number of bits is log(X)/log(2) rounded up.
I hope this makes it easy for you.
Olen
Charles N. Johnson <char...@mail.idt.net> wrote in article
<01bc0046$8a557ba0$65c0...@i-charlej9.interramp.com>...
> [edited for brevity...]
> Use IDEA-3. Triply encrypt (using no weak keys) with IDEA, and expand the
> number of rounds from 8 (each) to 32 (each).
>
> Moreover, IDEA on machines who natural word length in 16 or 32 bits is
fast
> enough.
>
> It is also very small. The IDEA module in PGP 2.6.3i compiles to less
than
> 6K with MSCV C++ 4.2b. The C++ version I wrote is less than 8k.
>
By this do you mean you have PGP 2.6.3i with IDEA-3? I was not aware this
was doable. Could you please post methods and problems?
Charles N. Johnson
Sorry, Olen, if I led anyone to believe there was such an encryption
algorithm as IDEA-3. There isn't. It was a play on DES-3. Someone was
worried about the purported strength of IDEA. My reply was that if you are
worried about the strength of IDEA, then use three independent keys and
encrypt three times. Let's see, that would be an effective tripling of the
difficulty. Gee, if it took the age of the universe to break IDEA, now you
can do it in three time that long!
So, sorry, it was my little joke.
Cheers--
Charles
Olen <ork...@txdirect.net> wrote in article
<01bc0094$6c1979e0$f55c39cc@default>...
Charles N. Johnson
dave scott <dsc...@ridgecrest.ca.us> wrote in article
<5b9v9p$1...@ash.ridgecrest.ca.us>...
>
> The reason I responded the way I did was when you showed your complete
> lack of knowledge by stating all zeroes was not a key. I guess you must
Go read Schneier.
> have got a little bit smarter since then. I am not going to argue how
long
> it takes to do a brute force search that is foolish. I did point out a
full
You haven't argued anything, yet. Post your code.
> mapping of 6 bits results in a key much longer than 128 bits. What I was
> pointing out that you appearently did not understand is that other
methods
> can be used and have been used on systems with keys much longer than
128bits
>
> >generating such a key is 2^96...I wouldn't be too worried about it. If
you
> >are worried about it, simply XOR every sub-key with 0x0dae and be done
with
> >it.
> Oh now you are suggesting modifying IDEA well welcome to the club it
needs
> beefing up.
Quite the opposite. If *you* are worried, please use something else. If you
feel it is too weak, and you know a good way to increase its strength, or
you know of another algorithm then post the algorithm you think to be
stronger. That's all.
> >Does this mean that IDEA is immune, or "the best?" No, of course not. It
> >does means that many very bright people have attempted to subvert IDEA,
and
> >all published attempts have failed. You want "completely safe?" Sure
thing.
> >Use IDEA-3. Triply encrypt (using no weak keys) with IDEA, and expand
the
> >number of rounds from 8 (each) to 32 (each).
>
> This is still weaker than my suggestions.
>
It isn't at all clear that your suggestion is as strong as IDEA. Just post
a simple example and people here will be absolutely delighted to try it
out. In fact, if you do have a remarkably strong algorithm, you can make a
great deal of money.
> >It is also very small. The IDEA module in PGP 2.6.3i compiles to less
than
> >6K with MSCV C++ 4.2b. The C++ version I wrote is less than 8k.
> >
> >And these are the three real criteria for such algorithms: small, fast,
and
> >tough. As Schneier points out, making tough algorithms big and slow is
easy
>
> I would agree when I was on some of the earlier computers that had a max
> memory size of 16k however the complete mapping that i was talking about
> for 16 bits which has a real key of 954037 does take a second or 2 to
make the
> table and the table is 128k in size but it is a screamer it involves only
> a look up table. For large files it would leave your IDEA in the dust.
>
Look, just post a little code, or post the workings of the algorithm.
Surely, it can't be that hard, even for someone as dense as you take it
that I am.
Cheers--
Charles
Arnoud Galactus Engelfriet
-----BEGIN PGP SIGNED MESSAGE-----
In article <5b8nnt$n...@ash.ridgecrest.ca.us>,
dsc...@ridgecrest.ca.us (dave scott) wrote:
> 1. How good is IDEA. In some ways it is very good and in others it is
> very bad. It is bad in that the key is 128 bits in length. Folks its the
> computer age. Wake up 128 bits suck.
That depends on the algorithm. For something like RSA, 128 bits is
indeed laughably weak; but a private-key algorithm like IDEA or
Blowfish is quite strong with a 128-bits key. Paul Leyland (IIRC)
posted that 128-bits IDEA is roughly as secure as 3000-bits RSA.
Since the only currently known attack on IDEA is brute-force (on
either the keyspace or the person who knows the key), and there are
2^128 possible keys, 128 bits is more than sufficient.
I would be very interested in hearing your arguments as to why
you think 128 bits keyspace is not enough for IDEA, or what fast
method you have to decrypt standard IDEA-encrypted messages when
you don't know the key in advance.
Galactus
- --
To find out more about PGP, send mail with HELP PGP in the SUBJECT line to me.
NEW ADDRESS: --> gala...@stack.nl <-- Please PGP encrypt your mail.
Finger gala...@turtle.stack.nl for public key (key ID 0x416A1A35).
Anonymity and privacy site: http://www.stack.nl/~galactus/remailers/
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: cp850
iQCVAgUBMtkQYjyeOyxBaho1AQHUSAQA2OB4sWRXh1eHGitPOuw/67aISfTjYSun
twtf8tFCqbJxEkdQCZAqBq0LMeiZfJ50Ve0yzFxrmszJWm1ECGY3rXrxPXLPDeGq
GNCEQpWU+n2RFOp61sTzSdthGZiIV//4P/725smUXulY+p330aYU2Pa/Q7pXhZSq
NNhOqIVeXH0=
=JdEI
-----END PGP SIGNATURE-----
dave scott
>Quite the opposite. If *you* are worried, please use something else. If you
>feel it is too weak, and you know a good way to increase its strength, or
>you know of another algorithm then post the algorithm you think to be
>stronger. That's all.
>
If you read the orignal document I mentioned several easy changes that could
be made to strengthen IDEA as well as the chaining method that would improve
it. Even someone like you should be able to put in the fixes.
I have posted other algorithims and have gotten good response but I noticed
that the original article did not go to several stites. So not sure our
European
friends can comment on the code. They seem to be the only ones interested in
trying to make encryption good. It is obvious you just sit on your ass. Yes
you have read some books on the subject so have I. But I also have years of
real world experience.
>It isn't at all clear that your suggestion is as strong as IDEA. Just post
I tried to post it but it gets filtered. I can tell you how to build
a lookup table so that each value of a REAL KEY leads to a unique mapping
and I can show how to build a unique key from a given mapping.
Maybe it got filtered due to size limits I am not sure but I know it is hard
to find my post. I could only find it at owens.ridgecrest.ca.us
R. Keith Heinsohn
dsc...@ridgecrest.ca.us (dave scott) wrote:
>>With 128-bits in an IDEA key, there are ((2^128) - 1) different keys (the
>>key with all bits set to 0 doesn't encrypt), that means there are roughly
>>10^38 different keys. If you could test 10^12 keys per second, you would
>>still need about 10^9 years to have a 50/50 chance of finding the key.
>>
> Sorry Charlie I don't think your good enough for Star Kiss yet.
>You seem to lack a solid math background and completely missed the whole
>point. First of all my friend IDEA does encrypt with a key of all zero's
>and before you make a bigger fool of your self it is not the identity
>transform it really does encrypt. By your logic if I took 8 bit ascii
>and replaced it by substituting a different character for each character
>it would take a 1684 bit key to discribe this. Hey I think 1684 is bigger
>than 128. Yet this method is as old as the hills and only some one of your
>mental ability would actually be dumb enough to use it. The fact is history
>has proven 128 bits is far to small.
It is interesting to note that you are the sort of human who seemingly
can only refute others by attacking them and calling them names. Such
actions speak volumes about you.
.....Keith
Charles N. Johnson
dave scott <dsc...@ridgecrest.ca.us> wrote in article
<5bb3n6$7...@ash.ridgecrest.ca.us>...
>
> If you read the orignal document I mentioned several easy changes that
could
> be made to strengthen IDEA as well as the chaining method that would
improve
> it. Even someone like you should be able to put in the fixes.
I am sorry that I fumbled that one. Please, for my benefit, repost your
suggestions, and I'll see what I can do.
> Yes
> you have read some books on the subject so have I. But I also have years
> of
> real world experience.
>
I am unclear what you have read. You might be kind enough to mention the
titles or authors. It does seem odd, however, to have missed the point that
the 0-IDEA key doesn't encrypt. If you would like, I would be delighted to
post the IDEA code straight from PGP. If you like, I can even point out the
lines from idea.c where you can select your key at will and re-compile. The
small test-bed that Phil Zimmermann included with IDEA makes de-bugging
relatively easy. You select your key, and it encrypts the same 8-byte
pattern (which you can also choose) 65,536 times. Then displays the results
of the encryption. Then it inverts your key, and decrypts 65,536 times and
compare the resulting 8 bytes to your original selection. It is really
quite nifty. On my pentium it runs the code in about 1.5 seconds when
compiled for speed. In debug mode it is about twice that.
Moreover, it will print out table values as the encryption-decryption
proceeds in both directions.
Believe me, I understand your hesitancy in accepting my word on this,
that's why I suggested reading someone who is publicly recognized. But if
you are unable to read him (that book can be hard to find sometimes) you
can ask here. But like I said, I will be more than happy to post the
algorithms as used in PGP 2.6.3i and 2.6.2. That way you don't have to take
my word for it, or anyone else's either.
> I tried to post it but it gets filtered. I can tell you how to build
> a lookup table so that each value of a REAL KEY leads to a unique mapping
> and I can show how to build a unique key from a given mapping.
I understand how the big bit-bucket of the net can work. I, too, have had
posts go to "wherever." So, go ahead and re-post, or better yet, describe
the look up table, how it is constructed and used, and the final encryption
algorithm that uses the keys that are developed.
> Maybe it got filtered due to size limits I am not sure but I know it is >
hard
> to find my post. I could only find it at owens.ridgecrest.ca.us
>
Could be a server problem. Is there ftp access to owens.ridgecrest.ca.us?
If so, I can snare your algorithm and post it from here.
Cheers--
Charles
William Unruh
In <ONQ2y4uY...@stack.nl> gala...@stack.nl (Arnoud "Galactus" Engelfriet) writes:
*>I would be very interested in hearing your arguments as to why
*>you think 128 bits keyspace is not enough for IDEA, or what fast
*>method you have to decrypt standard IDEA-encrypted messages when
*>you don't know the key in advance.
His arguement is that if one had a table of all 64 character
substitution cyphers, and one's key was the number of the table which
you used to encrypt your text using a simple character substitution
cypher, then your key would be 168 bits long. Yet despite that long key,
the encryption would be weak. (Ie, a long key does not guarentee a
strong cypher).
He then argues that IDEA is just a substitution cyper on 64 bit
characters and should therefor be weak, just as the classical
substitution cypher is.
At this point his position becomes confusing to me.
I think the first point ( a long key is no guarentee of a strong cypher)
is one we all would agree with. However his second point, that idea is
thus weak, is more problematical. The classical substitution cypher is
weak because of frequency analysis. A 64 character table is not hard to
fill in using frequency analysis, and plaintext. However, a 2^64 bit
substitution table is much much harder to fill in. That is 10^18
characters and would require a giga worth of gigabyte disks to hold.
Also frequency analysis becomes somewhat difficult, since the
probability of the same 64 bit "character" occuring even twice in the
text is small. Granted if you had terabytes worth of encrypted text to
work with you might find some repeats. (NOte the above does not apply to
chaining type uses of the cypher but then a chained alphanumeric substitution cypher
would also be hard to crack I syspect.
--
Bill Unruh
un...@physics.ubc.ca
Joe Feenin
>That depends on the algorithm. For something like RSA, 128 bits is
>indeed laughably weak; but a private-key algorithm like IDEA or
>Blowfish is quite strong with a 128-bits key. Paul Leyland (IIRC)
>posted that 128-bits IDEA is roughly as secure as 3000-bits RSA.
>
I have heard this of the IDEA type encryption. However I have several
concerns about conventional type encryption. All of them are
duscussed in the PGP mamnual and are things such as anyone with the
pass phrase can open the file, tranfering the pass-phrase to the
intended recipient etc. All of these types of things should obviously
be done with Public Key encryption. My concern about IDEA is not how
strong the encryption itself is but rather how easy is it to guess the
pass-phrase. Unfortunately most people use poor pass phrases without
mixed case or non-alphabetical characters. Wouldn't it be much
quicker for a computer program to simply attempt to crack a
conventionally encrypted file by guessing the pass-phrase rather than
attempting to break the encryption itself? With some of the pass
phrases (or should I say words) I've seen I would think it could be
done in a few hours. I think too many people get lazy since it says
PGP that they use weak pass-phrases on they keys and in conventional
encryption.
Joe
dave scott
>I am sorry that I fumbled that one. Please, for my benefit, repost your
>I am unclear what you have read. You might be kind enough to mention the
>titles or authors. It does seem odd, however, to have missed the point that
>the 0-IDEA key doesn't encrypt. If you would like, I would be delighted to
>post the IDEA code straight from PGP. If you like, I can even point out the
>lines from idea.c where you can select your key at will and re-compile. The
>small test-bed that Phil Zimmermann included with IDEA makes de-bugging
>relatively easy. You select your key, and it encrypts the same 8-byte
>pattern (which you can also choose) 65,536 times. Then displays the results
>of the encryption. Then it inverts your key, and decrypts 65,536 times and
>compare the resulting 8 bytes to your original selection. It is really
>quite nifty. On my pentium it runs the code in about 1.5 seconds when
>compiled for speed. In debug mode it is about twice that.
>
>Moreover, it will print out table values as the encryption-decryption
>proceeds in both directions.
>
>Believe me, I understand your hesitancy in accepting my word on this,
>that's why I suggested reading someone who is publicly recognized. But if
>you are unable to read him (that book can be hard to find sometimes) you
>can ask here. But like I said, I will be more than happy to post the
>algorithms as used in PGP 2.6.3i and 2.6.2. That way you don't have to take
>my word for it, or anyone else's either.
Go ahead post the key and show how the zero key does not work.
I got my code that I used for IDEA from DR. DOBBS journal it was quit
some time ago. I also test several keys with my code but that version
died when I had a had disk crash. But I still have part of it fron a working
porgram
on a floppy I thought it was illegal to actually post the code so you first.
ALso you may have a copy of my IDEA code in which I use an unrolled key of 832
bits. I sent it to a guy a few years ago who lived in Colorado. Also there was
a preston I think his initals where pdl he asked for a copy when I posted a
description a few years ago. I have not heard from these people for a long
time. The guy in Colorada said he would post it in his BBS in a secure area
for U.S. citizens only. I no longer have that code in C. but have others.
Also at one time had all the versions of PGP but those are gone to.
sal
You are correct
dave scott
In article <5bc4ik$dlh$1...@nntp.ucs.ubc.ca>,
un...@physics.ubc.ca (William Unruh) wrote:
>
>His arguement is that if one had a table of all 64 character
>substitution cyphers, and one's key was the number of the table which
>you used to encrypt your text using a simple character substitution
>cypher, then your key would be 168 bits long. Yet despite that long key,
a block code on 6 bit groups) encode a 6 bit group you have a group of
64 objects being mapped into another such group it would take a key 296
bits long to represent every possible mapping. I hope 296 is number
of bits in 64! or I made a mistake.
I also realize a long key is no guarantee to security. But a lot of
poor encription systems have long keys that are internally wasteful.
I guess by real KEY I mean how many bits in binary can represent the unique
code mappings that are available with the encryption method regardless
of how long the author claims the key is. For example in IDEA i can see
that it is at least 64 bits long and at most 128 bits. Just becasue
you have 128 bit key does not mean you have a Real key lenth of 128 bits.
Also some clever math person might realize there is another algebra
that maps it to a easier to understand problem.
>strong cypher).
>He then argues that IDEA is just a substitution cyper on 64 bit
>characters and should therefor be weak, just as the classical
>substitution cypher is.
>
many combinations that would never occur in an encryption because
english does not use all of the 256 8 bit characters. A fair test
would be to encode same standard version of a book like the bible
then encode some other text and see if some one could break it?
I will most likely not be that person to solve it.
>I think the first point ( a long key is no guarentee of a strong cypher)
I agree with this. But it is no guarantee of a weak one either.
>is one we all would agree with. However his second point, that idea is
>thus weak, is more problematical. The classical substitution cypher is
>weak because of frequency analysis. A 64 character table is not hard to
I maybe should not have used word weak rather is not as strong as
it could be with simple changes. It can be made orders of magnitude
stronger.
>fill in using frequency analysis, and plaintext. However, a 2^64 bit
>substitution table is much much harder to fill in. That is 10^18
>characters and would require a giga worth of gigabyte disks to hold.
>Also frequency analysis becomes somewhat difficult, since the
>probability of the same 64 bit "character" occuring even twice in the
>text is small. Granted if you had terabytes worth of encrypted text to
>work with you might find some repeats. (NOte the above does not apply to
>chaining type uses of the cypher but then a chained alphanumeric substitution
cypher
>would also be hard to crack I syspect.
I also feel that if the 16 bit blocks where subkeys used are actually
tables it would greatly enhance IDEA security. It least do it on first 4
or last 4 subkeys.
I think some people are confused how to go from a number REAL KEY VAULE
to table and back. I hope the below helps
Here is a complete example for using a full key for mapping
a 3 bit word. I know that 3 bits very short but explains how
it is done and one can go to more bits quite easily.
notice with 3 bits you have 2 to the 3 number of patterns
which is 8. Now notice that there are 8! different mappings
or possible tables. This is 40320 different tables. This
also means 16 bits necessary to encode a key to represent
the table. Now represent the key as a value of 0 to 40319
lets make one up.
let the key be 1000 maybe a poor choice but who cares
now divide by 8 then 7 and so on to 2 as follows
8 goes into 1000 125 times remainder 0
7 goes into 125 17 times remainder 6
6 goes into 17 2 times remainder 5
5 goes into 2 0 times remainder 2
4 goes into 0 0 times remainder 0
and remainder for 3 and 2 is 0 also
now take 3 tables both 8 units long and assume 0 filled
at first table the 0 row (we are using C) look at first
remainder it is zero now go to third table since 0 first
element of array find first element not used.
in this case no element used so place a 1 in zero entry
to mark it as used. Place that row number 0 in row zero
of table 1 and row 0 of table two.
first entry in encryption table and decryption table done
now ready to do row second row which is 1 ( c start first row
at 0)
remainder is 6 so go to table 3 and find the seventh entry
that has a zero this is 7 so place a one in third table c
index of 7. go to table 1 place a 7 at c index 1 and in
table 2 at c index 7 place a 1.
now for next row
remainder is 5 following procedure above this leads to a
6 at c index 2 table 1 and a 2 at c index 6 table 2 and
a 1 at c index 6 table 3
now next row
remainder is 2 leads to
3 at 3 table 1 and table 2 and a 1 at 3 in table 3
the rest of remainders 0 so the first available numbers
as marked by zero are brought across to table 1 and reverse
to table 2
the final result is
row tbl1 tbl2 tbl3
0 0 0 1
1 7 4 1
2 6 5 1
3 3 3 1
4 1 6 1
5 2 7 0
6 4 2 1
7 5 1 1
the 0 entry in table 3 is because I never divide by 1 it just
is last value to be used.
to do the reverse some one uses what ever exotic means of
encryption on 3 bit block let us assume for example it is
just an XOR with 001 this leads to a mapping of
row value
0 1
1 0
2 3
3 2
4 5
5 4
6 7
7 6
doing reverse of procedure above leads the follow remainders
for 8 divide it is a 1
for 7 divide it is a 0
for 6 divide it is a 1
for 5 it is 0 and the pattern continues
so the real key as a subset of mappings is
((((((1)*3+0)*4+1)*5+0)*6+1)*7+0)*8+1
21897
I now this is a bigger key than 001 that was used in the encryption
but XOR does not do a whole mapping it is only a small subset.
The point being no matter what you to it, it is a subset of the table
lookup and the table lookup can create the smallest key covering
every possibility.
I hope this is easy to follow.
also it is easy to modify if one does not like the 0 remainder
bringing the next available number for use one could use a smaller
base and start dividing by one number less and then and add one to
remainder when building the table. But at least this way you
can tell for sure each key has a unique mapping and the keys
get long fast and it is easy by changing your generating method to
exclude classes of undesired keys if one wishes.
I did this example on the fly so I hope it is correct if not I will
fix the errors if people spot them
dave scott
In article <87buaui...@ice.cs.byu.edu>,>> or what fast
>> method you have to decrypt standard IDEA-encrypted messages when
>
>
Sorry Don only some one from Utah would make a claim like that
and I'm not from there.
Camillo S{rs
dsc...@ridgecrest.ca.us (dave scott) writes:
> Well I never said a full table had to be created. There are many
> combinations that would never occur in an encryption because english
> does not use all of the 256 8 bit characters.
You have apparently misunderstood the way modern cryptography works.
Very few applications encrypt English text, they encrypt compressed
data (English text, Hebrew, Japanese, binaries, whatever). Compressed
data can be analyzed using statistical methods, but that already
requires a bit of work.
The compressed stream, which to an observer looks very like random
bits, is encrypted using a cipher. Typically this is a block cipher
in CBC mode or a stream cipher that uses a block cipher at its core.
Basically this means that the cipher uses different substitutions for
every bit in the cleartext. Calculating this substitution function is
what the cipher and the key do. Reversing this substitution function
without knowledge of the key is usually considered a hard problem.
Regards,
--
Camillo Särs <g...@iki.fi> ** Aim for the impossible and you
Faculty of Computer Science ** will achieve the improbable.
Helsinki University of Technology **
PGP public key available ** http://www.iki.fi/ged
Arnoud Galactus Engelfriet
-----BEGIN PGP SIGNED MESSAGE-----
In article <32d990ec...@news.servtech.com>,
j...@servtech.com (Joe Feenin) wrote:
> My concern about IDEA is not how
> strong the encryption itself is but rather how easy is it to guess the
> pass-phrase.
Well, that doesn't have anything to do with IDEA, but only with
its users. You can make exactly the same argument about triple DES
or any other secret-key cipher.
> Unfortunately most people use poor pass phrases without
> mixed case or non-alphabetical characters. Wouldn't it be much
> quicker for a computer program to simply attempt to crack a
> conventionally encrypted file by guessing the pass-phrase rather than
> attempting to break the encryption itself?
Yes. This is what programs like PGPcrack do; they guess passphrases
until they hit the "right" one.
Galactus
- --
To find out more about PGP, send mail with HELP PGP in the SUBJECT line to me.
NEW ADDRESS: --> gala...@stack.nl <-- Please PGP encrypt your mail.
Finger gala...@turtle.stack.nl for public key (key ID 0x416A1A35).
Anonymity and privacy site: http://www.stack.nl/~galactus/remailers/
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: cp850
iQCVAgUBMtqcpjyeOyxBaho1AQHwEgP/a58Zc7Yt36oCpNiGEjwCZbbLo7O7QB0M
TbCqpIG322Aj6rlhAvRzNU7cViNTK0KG4JyfOIIO+dAiIfaYtQl55+5ppgkEcVNl
eIwXhpEYv4ieFxTQkn5X8qmFJMDidMuLxR+2SmX/67egby+NFxMzigwGNvyPlxeE
nb7Tr7WtlhE=
=v1EO
-----END PGP SIGNATURE-----
dave scott
In article <l874tgl...@tinasolttu.cs.hut.fi>,
Camillo S{rs <g...@iki.fi> wrote:
>dsc...@ridgecrest.ca.us (dave scott) writes:
>
>> Well I never said a full table had to be created. There are many
>> combinations that would never occur in an encryption because english
>> does not use all of the 256 8 bit characters.
>
>You have apparently misunderstood the way modern cryptography works.
>Very few applications encrypt English text, they encrypt compressed
>data (English text, Hebrew, Japanese, binaries, whatever). Compressed
>data can be analyzed using statistical methods, but that already
>requires a bit of work.
>
>The compressed stream, which to an observer looks very like random
>bits, is encrypted using a cipher. Typically this is a block cipher
>in CBC mode or a stream cipher that uses a block cipher at its core.
>Basically this means that the cipher uses different substitutions for
>every bit in the cleartext. Calculating this substitution function is
>what the cipher and the key do. Reversing this substitution function
>without knowledge of the key is usually considered a hard problem.
>
>Regards,
I think you msiunderstand what I said. When I use encryption I use
Pkziped files. of course the PK in front gives file away so it can
be randomly changed and added back in later. I am only looking at the
64 bit block cipher part not how to add security past the block
encoding itself but just to the IDEA part alone. I can add various
compression and such to any block cipher part. I personally feel CBC
mode not that good either If you read my original post on this thread
it meantions why.
>
Another approach that could be used to break this code is an algebric
attack. Notice that if one only used the first four subkeys this would
amount to a 64 bit key. yet i can divide input 16 bit word by output word
and get first subkey subtract on next 2 and get next 2 on last do another
divide. This would get the full 64 bits. Easy you just have to have one
block in and one block out to break if only the first 4 subkeys used.
Lets pretend that if each subblock unique that the mapping unique.
then since 52 subkeys and each place where they are used are of form
a operation key = b
and
a reverse_opretion b =key
Then if someone knew 7 unencoded blocks in and 7 encoded blocks out.
maybe provided that one not a linear combination of other blocks or
related in some way that affects the algrabra of the system. One most
likely could solve directly for the key used. Or even be able to directly
induce the decryption of rest of code from these 7 blocks alone.
I am not that good at this algebra yet since it is a mixture of 3 algebras
but I would bet am left testicle some one out there at NSA is or if like
the rest of government before down sizing someone who was there may have
already done this.
The thing to protect against such an attack would be to make the first 4
subkeys that of a random table. That way you break the problem. That in
reduced form says
if
a op key = b
then
a rev-op b = key
end
since if a table you have only one entry sovled
so it is a much harder problem. One does not know
what operation is used so it will not
fall out due to some exotic algebra. Since the information
is not there.
My god man 52 equations 52 unknows. It can and will be solved.
It is only a finite algebra problem. And before you asked I have
not sloved it yet nor have I wasete time trying yet. But it should
be obvious that it has this weakness which can be fixed.
Charles N. Johnson
dave scott <dsc...@ridgecrest.ca.us> wrote in article
<5bc8pv$g...@ash.ridgecrest.ca.us>...
>
[edited for brevity...]
> on a floppy I thought it was illegal to actually post the code so you
first.
Here's one of those cases where copyright actually helps. Posting part of
the code for a research discussion is considered "fair use." I have
attached the files you'll need to compile the code. Plus two other files
(test1.mak, and test1.mdp) in case you have access to the Microsoft Visual
C++ compiler. If you do not, retain all the files *.h and *.c (there are
seven all together) and compile them in DOS (or windows) with a C compiler
and run it.
The attachment is a ZIP file: test1.zip Snare it and unzip it.
Please check the idea.c file at about line 371 or so, and you'll see the
modification to use a zero key. You'll find the output identical to the
input in CFB mode.
If you can't handle a .zip file attachment, I can also upload a UUE file
which your browser can unencode into the ZIP file. Just unzip and go!
And thanks for your explanation. Things are busy at work for the next 2
days or so (and the weather's lousy, too!) so it'll be Thurs or Fri before
I can respond with some reflection. I appreciate your taking the trouble to
do it again.
Cheers--
Charles
Camillo S{rs
dsc...@ridgecrest.ca.us (dave scott) writes:
> I think you msiunderstand what I said.
This is very possible, as you do not use established cryptographic
terms or methods. I am not a cryptographer, and find your arguments
so hard to follow that I usually give up. Your descriptions of
partial "mappings" within the algorithm are utterly confusing to me.
Why don't you try to present your ideas in a more formal way, as
cryptographers typically do. That way more people may understand what
you are trying to say.
Personally I am convinced that the numerous papers I have read or seen
referred to are authentic, and that their claim that IDEA is quite
strong is correct. Therefore I would be very interested if you
actually managed to present an attack on IDEA that shows that it is
weak.
Camillo
dave scott
In article <01bc01c5$371d8d80$1ac0...@i-charlej9.interramp.com>,
"Charles N. Johnson" <char...@mail.idt.net> wrote:
>This is a multi-part message in MIME format.
>
>
>
>
>dave scott <dsc...@ridgecrest.ca.us> wrote in article
><5bc8pv$g...@ash.ridgecrest.ca.us>...
>>
>[edited for brevity...]
>
>> on a floppy I thought it was illegal to actually post the code so you
>first.
>
>Here's one of those cases where copyright actually helps. Posting part of
>the code for a research discussion is considered "fair use." I have
>attached the files you'll need to compile the code. Plus two other files
>(test1.mak, and test1.mdp) in case you have access to the Microsoft Visual
>C++ compiler. If you do not, retain all the files *.h and *.c (there are
>seven all together) and compile them in DOS (or windows) with a C compiler
>and run it.
>
like -khit (spelling?) are not there or I don't know which systems .h files
to include and which libraires to use with it. I notice some
interanl assemlby code. It may not be the same as what your
compiler uses. There are different formats for assembly from
different manufactures. Also have not followed the #ifs to
see if those are compiling also it complains about code is
tryting to complie an include. And then dies. Any way I will
look to see if it is like my IDEA from DR DOBBS. One major
problem I had is I treat files in 8 bit chunks so when I moved
my code to sun there was a lot of swaping to get it to match pc
the order of bytes is different on sun, Just thought I would add
that.
Also I have lots of faith in the GNU C compiler. At work it
seemed that the SUN C complier produced slow code and had more
bugs so I will stick with it. It also runs on lots of Platforms.
>The attachment is a ZIP file: test1.zip Snare it and unzip it.
>
>Please check the idea.c file at about line 371 or so, and you'll see the
>modification to use a zero key. You'll find the output identical to the
>input in CFB mode.
>
>If you can't handle a .zip file attachment, I can also upload a UUE file
>which your browser can unencode into the ZIP file. Just unzip and go!
>
>And thanks for your explanation. Things are busy at work for the next 2
>days or so (and the weather's lousy, too!) so it'll be Thurs or Fri before
>I can respond with some reflection. I appreciate your taking the trouble to
>do it again.
>
>Cheers--
>Charles
>
>
>< Content-Type: application/octet-stream; Filename: test1.zip >
>
Peter Nilsson
-----BEGIN PGP SIGNED MESSAGE-----
Saturday January 11 1997, dave scott writes to All:
ds> This is a about good block encryption. First I would like to tell
ds> you
ds> I am a retired scientific programmer. I have been doing assembly language
ds> for over 25 years. I now am unemployed and do mostly C programming. I
ds> never was good at typing or English but have always been good at science
ds> and math. 1. How good is IDEA. In some ways it is very good and in others
ds> it is very bad. It is bad in that the key is 128 bits in length. Folks its
ds> the computer age. Wake up 128 bits suck. My first attempt to improve on it
Well, consider that there's 2^128 possible keys to try.
2^128 is appr. 3.4*10^38. That's quite a large number.
Assume NSA has 1000 super-hyper-duper computers around U.S. and each one of
them can try out 1 billion combinations per second (!).
That will make 10^12 comb. per second.
It will take them (3.4*10^38/10^12) seconds, in worst case, to find the right
key. That is 3.4*10^26 seconds or ca. 10 000 000 000 000 000 000 000 years.
How long has this little green planet of ours existed? 4 000 000 000 years?
The whole universe (this one)? 25 000 000 000 years?
Not retired :-)
("`-/")_..-'"``-._
Peter Nilsson . . ) `. )-,;-,_`)
<p...@cw.ct.se> (v_).' . ` _`-,\ ``-'
http://hem.passagen.se/oldwolf/ _. _,-_) ) ((,'
PGP KeyID: 0xD6C1A845 ((,.-' ((,/
[Public key on servers]
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: cp850
Comment: Protect your privacy -> Use PGP!
iQCVAwUBMtvqOL0D4GDWwahFAQFb7QQAqZnxpYhoVe+zE5mnifCaQI4WBHbuwZ7s
ng/FQ40qo+R84EqCaaspkNOlE3bJUh8vMZMhAH71o17VnrRuJDJBKCh1sWZF+ovQ
CA6iC5gxcVFOMoeDWAToX1+28OPuyxlcG7oSDNhlIZsup/tja/g63o0E8VnDKWJc
8O9tgPjzYvQ=
=sRe0
-----END PGP SIGNATURE-----
dave scott
In article <87zpycw...@cool.cs.byu.edu>,
>> and I'm not from there.
>
>
Thank YOU I had a better one but it might have pissed mormans off.
>
>How about we talk about IDEA. Since you claim that IDEA is insecure, and
>have mathmatically "proven" it, how about you demonstrate it. I'm a little
>skeptical of your claims to know something that no other cryptographer has
>demonstrated to the scientific community. I'm even more doubtful of your
>claim to have something that's better.
>
I pointed out why it was much weaker than it needed to be. I did not
say that I have broken it. If you actually read the posts you can see
why it is weaker than it should be and how to make it stronger.
Yes I have code that is much stronger by several orders of magnitude
than straight IDEA. You can to. As I stated just change first four subkeys
to mappings. I feel any cryptographer who is honest would tell you
that this alone is much stronger but the ones who talk here either
wish to mislead you. Or they don't care if it is stronger becasue
they are fat dumb and happy wiht the status quo.
>If nobody else here can donate IDEA cyphertext for you to crack, I'm sure
>I can dig out my IDEA code and cook up something.
>
>Don
>
>PS: I'm not from Utah either.
Well what does byu stand for if not Bringem Young University
I bet you think of National Basketball Association if I said NBA
but I would think of the Nevada Brothel Assoication first since
it has done more for mankind
dave scott
In article <l87d8v8...@tinasolttu.cs.hut.fi>,
>
>This is very possible, as you do not use established cryptographic
>terms or methods. I am not a cryptographer, and find your arguments
>so hard to follow that I usually give up. Your descriptions of
>partial "mappings" within the algorithm are utterly confusing to me.
>
you could set me up with some blond sweetish chick unless you are in
Norway or Denmark but I here chicks there nice too.
I can best explain by example. I already tried to explain by a 3 bit
example but maybe I am not that good at explaining. Some how better at
pissing people off.
if one ( don't try to use this) wanted to build a 2 bit block encryption
program what is most one can do. Look forget chainning for a minute will
are looking at 2 bits in 2 bits out period.
since there are 4 patterns 00 01 10 11 in general 2 to the N power in this
case N=2 so 4 patterns. by a "mapping" i mean how do the four objects in
related to 4 objects out.
example
in out
00 01
01 10
10 11
11 00
this is one mapping of 4 object in and 4 out I added a 01
now a new mapping
00 10
01 11
10 00
11 01
this is a new mapping I added a 10
so we did 2 of them
now how many mappings can there be. well 4*3*2*1 24 unique mappings
or 4! or (2^^n)! where number of bits input block
it would be ridulous to do a mapping where n much larger than 16
on todays computers. 64 is really out of question whith todays
science but maybe not in the next 100 years but technology would
really have to change may be to use parts of quarks. Hell I don't know
but it would have to cahnge to do 64 bit words but not 16 bit words
any way there are 24 such mappings for 2 bits one needs a key of length
to write number zero to 24-1 (i like c starts at zero not 1)
23 is less than 16 + 8 + 4 + 2 + 1 but is 10111 in binary
that means a 5 bit key is all that is need to do block encodeing
on 2 bit words. But it means more if some one comes a long
and says I have a 8 bit key to do a block encodeing for a 2 bit
word and shows that he adds first 2 bits then xor the next 2 bits of
key to output and than does what he calls a mulitply to the next
and and he does an inversion with the last 2 bits. Then says find the key.
Bull shit you dont need his dam key since all the mappings can be expressed
in 5 bits the real key length is 5 bits not 8. It also says
more if for example the guy has a 2 bit key and you see the algorithm
a + key = b
then if you know only one value for a and one value for b
you have the whole mapping because key = a-b
IDEA though mixed has nothing more than thes type of operations
granted it is in 3 normal algebra but every operations is the
same.
with a key based on mapping number the breaker can't write
a op key = b
and do a ( key = a rev b)
since at most he solved only one entry to table
where as if a xor or any 2 bit op used one can
create the whole table from the reverse.
I no longer have access to things like MATHCAD that i
used at work using standard algrebra it can solve very
large and complicated algebgra equations that most
mathematicans either would not solve becasue the length
of time leads to boredom and mistakes but computer
does it in a blink of the eye. Know do you think the NSA
has better stuff than MATHCAD capable of more abstract
algebras. My god man N equations N unknows give it some
thought.
>Why don't you try to present your ideas in a more formal way, as
>cryptographers typically do. That way more people may understand what
I guess because I think most of them are guys in clown sutis. I think ties
are stupid and dumb. I feel phonies wear ties to imprees. Hay at work
I did not have to impress anyone how i spoke or what I wore. But may be
impressions and bull shit more important than reality.
dave scott
In article <ftn_2.200.116_32db...@cw.ct.se>,
peter....@cw.ct.se (Peter Nilsson) wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Saturday January 11 1997, dave scott writes to All:
>
> ds> This is a about good block encryption. First I would like to tell
> ds> you
> ds> I am a retired scientific programmer. I have been doing assembly
language
> ds> for over 25 years. I now am unemployed and do mostly C programming. I
> ds> never was good at typing or English but have always been good at science
> ds> and math. 1. How good is IDEA. In some ways it is very good and in
others
> ds> it is very bad. It is bad in that the key is 128 bits in length. Folks
its
> ds> the computer age. Wake up 128 bits suck. My first attempt to improve on
it
>
>Well, consider that there's 2^128 possible keys to try.
>
>2^128 is appr. 3.4*10^38. That's quite a large number.
>
>Assume NSA has 1000 super-hyper-duper computers around U.S. and each one of
>them can try out 1 billion combinations per second (!).
use a program that blindly sreachers through every combination of key in form
that the IDEA people use. I thought that fact was obvious. But it seems
like some of you are so hung up on the 2**128 that you fail to see that much
easier systems fail that are based on long keys. Get a life.
>That will make 10^12 comb. per second.
>It will take them (3.4*10^38/10^12) seconds, in worst case, to find the right
>key. That is 3.4*10^26 seconds or ca. 10 000 000 000 000 000 000 000 years.
>
>How long has this little green planet of ours existed? 4 000 000 000 years?
>The whole universe (this one)? 25 000 000 000 years?
>
>Not retired :-)
>
RETIRED :-) :-)
it means twice as happy
> ("`-/")_..-'"``-._
>Peter Nilsson . . ) `. )-,;-,_`)
><p...@cw.ct.se> (v_).' . ` _`-,\ ``-'
>http://hem.passagen.se/oldwolf/ _. _,-_) ) ((,'
>PGP KeyID: 0xD6C1A845 ((,.-' ((,/
>[Public key on servers]
>
That's a nice Pussy can I borrow it?
John Savard
dsc...@ridgecrest.ca.us (dave scott) wrote:
> 1. How good is IDEA. In some ways it is very good and in others it is
>very bad. It is bad in that the key is 128 bits in length.
128 bits is adequate to avoid the possibility of brute-force attacks.
With a modest increase, to, say, 160 bits, it would match the key
lengths used in some military systems.
>This can not make it worse.
With DES, independent subkeys don't make it much better, according to
some research results.
>Even if it does not improve the code very much most people
>who know nothing about mathematics think this might be easier to break.
The only weakness that might be introduced is that some worse weak
keys would be possible.
> If one where encrypting a 16 bit word with XOR of another 16 bit word.
>Then a 16 bit key is requires to represent the 2^16 possible mappings.
See my comment below about mappings.
>Well for convenience you can use a 48 bits but there are not
>2^48 combinations. since for example any time MUL is a one there many
>redundant combination like in hex 0003 0001 0003 same as 0000 0001 0000.
>It is for reasons like this that they may have chosen 128 bits.
The multiplication operation used in IDEA is multiplication modulo
65537 (a prime number, in fact, a Fermat prime) with 0 standing in for
65536. As it is multiplication modulo a prime, there is no information
loss - otherwise, IDEA would not be invertible.
>The quickest fix
>to IDEA that would guarantee a real key length of over 3,000,000 bits is to
>replace the first 4 subkeys and the functions where they are used with
>mappings based on 954,037 bit keys for each of the 4 mappings.
The 2^128 combinations represented by 128 bits are indeed less than
(2^64) factorial. But that is an inevitability rather than a weakness.
>since IDEA is 8 characters long one would needs different tables.
CBC and OFB modes are not inherently all that much more secure than
ECB, so we can accept this as a philosophical point about the weakness
of block ciphers in general. However, 2^64 is a BIG number. And PGP
compresses text before encrypting it.
>First use a complete 16 bit mapping
>based on a 954037 bit key.
128 Kbytes is not small...
>Then do like above example except use 2 8 bit
>characters as input to first encryption block. On output only one character
>goes out to temp file the second character out of block is feedback for next
>block.
Actually, this is almost sounding like Blowfish.
Because IDEA works by using XOR, addition, and multiplication, with no
arbritrary tables (as in DES), there is the potential for analytic
attacks we don't know of yet. And, certainly, it's easy enough to use
keys larger than 128 bits, since the moduli used for the RSA component
of PGP are big enough that larger keys would fit.
It's one thing to say that it would be easy to make a program that is
even stronger, but quite another to say that a much stronger program
is really needed.
John Savard
Camillo S{rs
dsc...@ridgecrest.ca.us (dave scott) writes:
> OK I will try to explain "mappings" since may be if I ever visit helsinky
> you could set me up with some blond sweetish chick unless you are in
> Norway or Denmark but I here chicks there nice too.
You basically described "mappings" as I thought you would, a basic
confusion step in an encryption algorithm. At no point have you
mentioned the impact of diffusion on your claim that 128 bit keys are
too short.
> it would be ridulous to do a mapping where n much larger than 16
> on todays computers. 64 is really out of question whith todays
> science but maybe not in the next 100 years but technology would
> really have to change may be to use parts of quarks. Hell I don't know
> but it would have to cahnge to do 64 bit words but not 16 bit words
Did I misinterpret this, or did you just say that a brute force attack
on a 64-bit key is out of question with today's science?
> >Why don't you try to present your ideas in a more formal way, as
> >cryptographers typically do. That way more people may understand what
> I guess because I think most of them are guys in clown sutis. I think ties
> are stupid and dumb. I feel phonies wear ties to imprees. Hay at work
> I did not have to impress anyone how i spoke or what I wore. But may be
> impressions and bull shit more important than reality.
You completely lost me there. I have no idea of how ties relate to
cryptography, and I have never noticed that ties have anything with
academic competence to do.
And what is wrong with expressing something formally?
Lewis McCarthy
dsc...@ridgecrest.ca.us (dave scott) writes:
> 5. The worse thing about modern block computer encryption beside the small
> keys sizes most people use is the method of chaining the blocks together.
> 1 reason IDEA is better than most blocks methods is that 8 characters are
> chained together nicely. However the 64 bit blocks are chained together very
> poorly with techniques the code breakers like people to use.
This is an extremely vague criticism. Are you referring to CBC (Cipher Block
Chaining Mode) ? See Bellare, Kilian, and Rogaway's paper "The Security of
Cipher Block Chaining" from Crypto `94, available as
http://www-cse.ucsd.edu/users/mihir/papers/cbc.ps.gz. I don't know which
"code breakers" you believe are trying to promote insecure chaining modes for
block ciphers. Our friends at Ft. Meade would appreciate it if
everyone used shorter keys and/or handed them over, but that's a different
issue.
> They are so bad
> that if one only has the middle third of a file but one has the key and
> algorithm used you can recover the data.
We would like anyone who possesses the correct encryption key to be able to
recover as much of the plaintext as possible -- usually, all of it. If a
chunk of the ciphertext is missing, then information is irretrievably lost.
> What this means for you, is that
> the enemy to break your message needs to study only a small portion of it.
> Good chaining for files should have 2 features not found in PGP's use
> of IDEA. 1. The chaining should require the whole file error free before
> it can be decoded.
Encryption alone should not in general be relied upon for message
authentication; this is one of the reasons for the use of digital signatures,
as in PGP (signing an MD5 hash of the input with an RSA private key).
> 2. It should be one way. By one way I mean if encoded
> by going down a file. It should only be able to be decoded by looking at file
> in one direction only.
I don't see your point here. Why do you consider this an important quality of
a decryption function?
-Lewis
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Camillo S{rs
dsc...@ridgecrest.ca.us (dave scott) writes:
> Also why did you not attack me for making the glaring mistake about
> Finland.
I am not in the habit of attacking people during discussions...
> If is did not know better I would suspect you work for the NSA but
> since you live in Finland you are more likely KGB
... but you seem to be. I'd say this concludes this discussion for my
part. Oh, and I am still convinced IDEA is good enough.
dave scott
In article <5bjluh$g...@tor-nn1-hb0.netcom.ca>,
sew...@netcom.ca (John Savard) wrote
>128 bits is adequate to avoid the possibility of brute-force attacks.
>With a modest increase, to, say, 160 bits, it would match the key
>lengths used in some military systems.
a dumb blind straight forward pure search was a good thing to try. So
please stop repeating this one fact.
>>This can not make it worse.
>
>With DES, independent subkeys don't make it much better, according to
>some research results.
>
>>Even if it does not improve the code very much most people
>>who know nothing about mathematics think this might be easier to break.
>
>The only weakness that might be introduced is that some worse weak
>keys would be possible.
weak keys. Buy the very fact you have a larger map space. But every
attempt to limit the size makes it easier for computers to break as
the available mappings go down. You can get some bad keys but the
strong keys are stronger and there are more of them.
>
>> If one where encrypting a 16 bit word with XOR of another 16 bit word.
>>Then a 16 bit key is requires to represent the 2^16 possible mappings.
>
>See my comment below about mappings.
>
>>Well for convenience you can use a 48 bits but there are not
>>2^48 combinations. since for example any time MUL is a one there many
>>redundant combination like in hex 0003 0001 0003 same as 0000 0001 0000.
>>It is for reasons like this that they may have chosen 128 bits.
>
>The multiplication operation used in IDEA is multiplication modulo
>65537 (a prime number, in fact, a Fermat prime) with 0 standing in for
>65536. As it is multiplication modulo a prime, there is no information
>loss - otherwise, IDEA would not be invertible.
above example was referring to was an example of encrytpion useing an
xor then a mul idea style and then a xor
the multiply was a one. IN IDEA a multiply of one is the identity operator.
so give me a break i was doing modular base multiplies while you where still
sucking on your mama's teats well unless you are an old fart or i guess there
is even the possibilty she refused to suckle you and it may have affected your
ability to do math problems i really am not sure which case is true..
>
>>The quickest fix
>>to IDEA that would guarantee a real key length of over 3,000,000 bits is to
>>replace the first 4 subkeys and the functions where they are used with
>>mappings based on 954,037 bit keys for each of the 4 mappings.
>
>The 2^128 combinations represented by 128 bits are indeed less than
>(2^64) factorial. But that is an inevitability rather than a weakness.
i never gave a number approaching the number of bits in (2^64)! so
i think you are lost.
>
>>since IDEA is 8 characters long one would needs different tables.
>
>CBC and OFB modes are not inherently all that much more secure than
>ECB, so we can accept this as a philosophical point about the weakness
>of block ciphers in general. However, 2^64 is a BIG number. And PGP
We do not have to accept this as a weakness of block ciphers. We can
chain a hell of a lot better.
dave scott
>> They are so bad
>> that if one only has the middle third of a file but one has the key and
>> algorithm used you can recover the data.
>
>We would like anyone who possesses the correct encryption key to be able to
>recover as much of the plaintext as possible -- usually, all of it. If a
>chunk of the ciphertext is missing, then information is irretrievably lost.
>
them encrytpted. You should check if you decrypted correctly by doing a
pkunzip -t a.zip
or what ever. If part of a file is missing especially a compressed file it
does the reciever little good. And for Gods sake why would anyone want to
send a file that only aportion is needed to break the code. It should be
chainned together so that it would take whole file to break the code.
if you don't get it all then ask for it again.
>> What this means for you, is that
>> the enemy to break your message needs to study only a small portion of it.
>> Good chaining for files should have 2 features not found in PGP's use
>> of IDEA. 1. The chaining should require the whole file error free before
>> it can be decoded.
>
>Encryption alone should not in general be relied upon for message
>authentication; this is one of the reasons for the use of digital signatures,
>as in PGP (signing an MD5 hash of the input with an RSA private key).
>
I didn't say don't use signatures on your file. But they don't do
shit for you unless you get the whole file exact in the first place
know do they?
>> 2. It should be one way. By one way I mean if encoded
>> by going down a file. It should only be able to be decoded by looking at
file
>> in one direction only.
>
>I don't see your point here. Why do you consider this an important quality of
>a decryption function?
I think it is an important quality for an encryption system. YES
it makes it hard to break.
dave scott
>You basically described "mappings" as I thought you would, a basic
>confusion step in an encryption algorithm. At no point have you
I really thought I did a good job of explaining mappings but I am
sure some one else who read this can explain to you I still think you
don't know what I mean. Also why did you not attack me for making the
glaring mistake about Finland.
>mentioned the impact of diffusion on your claim that 128 bit keys are
>too short.
>
>> it would be ridulous to do a mapping where n much larger than 16
>> on todays computers. 64 is really out of question whith todays
>> science but maybe not in the next 100 years but technology would
>> really have to change may be to use parts of quarks. Hell I don't know
>> but it would have to cahnge to do 64 bit words but not 16 bit words
>
>Did I misinterpret this, or did you just say that a brute force attack
>on a 64-bit key is out of question with today's science?
>
Yes you missed it again the REAL KEY length for a total MAPPING of
a 64 bit word would be the number of bits to express ((2^^64)!-1)
this number would be a little larger than 128.
Also before you ask the IDEA would be a subset of that. To do a 64 bit
block size the IDEA people chopped it up to 16 bit blocks and chained
them togethere in a way that has non NSA people confused. But they
should have used full MAPPINGS on those 16 bit words before or while
they are mixing them together. Any one can add this feature. Just ask
so one who is serious about encryption.
Gaudia
Lewis McCarthy <lmcc...@cs.umass.edu> wrote:
>dsc...@ridgecrest.ca.us (dave scott) writes:
>> 5. The worse thing about modern block computer encryption beside the small
>> keys sizes most people use is the method of chaining the blocks together.
>> 1 reason IDEA is better than most blocks methods is that 8 characters are
>> chained together nicely. However the 64 bit blocks are chained together very
>> poorly with techniques the code breakers like people to use.
>This is an extremely vague criticism. Are you referring to CBC (Cipher Block
>Chaining Mode) ? See Bellare, Kilian, and Rogaway's paper "The Security of
>Cipher Block Chaining" from Crypto `94, available as
>http://www-cse.ucsd.edu/users/mihir/papers/cbc.ps.gz.
-snip-
Lewis McCarthy <lmcc...@cs.umass.edu> wrote:
>dsc...@ridgecrest.ca.us (dave scott) writes:
>> 5. The worse thing about modern block computer encryption beside the small
>> keys sizes most people use is the method of chaining the blocks together.
>> 1 reason IDEA is better than most blocks methods is that 8 characters are
>> chained together nicely. However the 64 bit blocks are chained together very
>> poorly with techniques the code breakers like people to use.
>This is an extremely vague criticism. Are you referring to CBC (Cipher Block
>Chaining Mode) ? See Bellare, Kilian, and Rogaway's paper "The Security of
>Cipher Block Chaining" from Crypto `94, available as
>http://www-cse.ucsd.edu/users/mihir/papers/cbc.ps.gz.
[snip]
Lewis--
Please address directly the point that Dave Scott makes re: chaining
using 64's and 16's.
Is this "right" or "wrong"? Help us dummies out here decide this.
That's his central point, repeated again in his posting immediately
preceding yours.
TIA,
Gaudia
Arnoud Galactus Engelfriet
-----BEGIN PGP SIGNED MESSAGE-----
In article <5bjvbn$p...@ash.ridgecrest.ca.us>,
dsc...@ridgecrest.ca.us (dave scott) wrote:
> If is did not know better I would suspect you work for the NSA but since
> you live in Finland you are more likely KGB
Can we keep this discussion serious please? If you have a valid
point, then I don't see why you should use comments like this to
"defend" your position.
Galactus
- --
To find out more about PGP, send mail with HELP PGP in the SUBJECT line to me.
NEW ADDRESS: --> gala...@stack.nl <-- Please PGP encrypt your mail.
Finger gala...@turtle.stack.nl for public key (key ID 0x416A1A35).
Anonymity and privacy site: http://www.stack.nl/~galactus/remailers/
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: cp850
iQCVAgUBMt5+zDyeOyxBaho1AQFMigP8DaotydmtK0rFFD+ZJDY9qjqD7t2V1MBs
M0XW6FepSQJnhtQZs65WcmQ4QAtxBCvi+en8o/3WAEyz0zn56co1VIbeotHQcupf
J8KHi2MF0nJaK3TLBPx4BD2FYGJdv7cp7AMCTsgMfI1xnCG6R5GwcDOjY66rFIC1
/kb6vofWh24=
=aS6u
-----END PGP SIGNATURE-----
William Unruh
In <5bls8q$k...@ash.ridgecrest.ca.us> dsc...@ridgecrest.ca.us (dave scott) writes:
*>some one gives a sample of 16bit words in hex in groups of 8
*>to make 64 bits. Then give me 100 randam 64 bits blocks with
*>the matching out put blocks. all in 8 16bit word groupings
*>then give me 10 more 64 bit blccks as described above and
*>I will calulate what the matching output black would be. Notice
*>I did not say solve for the key but what the method does.
So, let me see what the test you propose is. We give you 100 random 64
bit blocks plus for each of these blocks, we give you the output of IDEA
for each of these blocks. (No chaining- each block is encrypted
seperately and independently). We now give you one more 64 bit block and
do not give you the output to IDEA. You will give us the encrypted
version of that 64 bit block.
Is this correct? The only reason I ask is that your first sentence above
seems to be irrelevant to this test. If it is not then I guess I do not
understand your test.
If this is what you mean, then, yes, I am sure that we could put you to
the test, and yes, it would be an interesting test.
(Of course, we will not give you the one key used to encrypt the above
blocks).
--
Bill Unruh
un...@physics.ubc.ca
dave scott
In article <thn3y4uY...@stack.nl>,
gala...@stack.nl (Arnoud "Galactus" Engelfriet) wrote:
>In article <5bjvbn$p...@ash.ridgecrest.ca.us>,
>dsc...@ridgecrest.ca.us (dave scott) wrote:
>> If is did not know better I would suspect you work for the NSA but since
>> you live in Finland you are more likely KGB
>
>Can we keep this discussion serious please? If you have a valid
>point, then I don't see why you should use comments like this to
>"defend" your position.
>
>Galactus
You are right. I guess most people do not have a sense of humor
any way here is my public pgp key
Type Bits/KeyID Date User ID
pub 2048/A013BD29 1997/01/14 David A. Scott <dsc...@ridgecrest.ca.us>
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3a
mQERAzLbV5wAAAEIALSCbxLzA5IXgErmrsGq88FkJHslxNFKf9ogH9vYuPNvFn2X
bgpJRkHxnq8cLwkzcbKOEBwjeNn4bo5ApRvpx5vKb3ofnjLcNEFN8Bg1zVsrjrGr
pHGD2tNPcStXu2WwQuR5j8ujfYeKDTQHv0E+ImlWeiJsAs3VtpE/wUvQgdCTvQNc
68qTzRyYn/1mAXERWBBSMj8R3Ku/Yf1zv9C1ZWLmGPAg5fOyVi63V9k1enqG+WP1
SD7FmSEfa0coSV7V77CzrJPADQZkpaydpcX7B6YnvzMnQVU5XuvPVVPFi+e+/Dp2
DPGNRKrggppAli0RiLMeU1i1amIi80GRHaATvSkAJRAAAAABtChEYXZpZCBBLiBT
Y290dCA8ZHNjb3R0QHJpZGdlY3Jlc3QuY2EudXM+iQEVAwUQMttXnvNBkR2gE70p
AQGodgf/S4s2GvOpst32iAlf3j4qXDKfpeN0s37+oY9gtsRZRRlFF13zJ3GJqwps
+VhqJf55TxKrylRj1i0dFEIhWn0dscsd8n12vA5PmK5+EVBmzNFuPUMCNtSM9GEu
UglSvqJJ8gChm5GV4PKyIPh9OIqAamuAP1C5n9Pm5elGz54HrwXLxI81rBRnA623
TJswhbvQTe+JuMbBSHi21zu8ckzlg+xr1ahGjqGB5IVV4GKwe1TXKtsny0ps0Z2K
jPV6gOuwYg05hXEHzYwxzD+DmRG5bctIG3p75n5SMYfCUkk89gXar6xUH/qVf4Ym
Jn4Fd5mxuBaJpF+HNxeoVsWo0itk2Q==
=Zyc6
-----END PGP PUBLIC KEY BLOCK-----
and here is a way to make a mapping from a reamainder table
to do a single map for 16bits notice I didn't do method in
my example becasue that is to slow for a PC but same results
I hope you know what I mean be remainder table see posts
-----BEGIN PGP SIGNED MESSAGE-----
#include <stdio.h>
#include <stdlib.h>
#include "dstypes.h"
/* the file dstypes defines things like un16 is unsigned 16 bit word
you folks will have to write you on to match mine not to hard */
#define T16L 65536
un64 w1, w2, w3;
un16 ftb[T16L], btb[T16L], rtb[T16L];
un16 *cpp[256], *cp, ct[T16L] = {0};
un16 cpn[256];
/* for the truely alert I created a mapping table based on
remainder table rtb but I did not use technique described
in post since that is slower than molasses on a PC, but
the resulting tables are the same. Also not rtb has more
bits than needed for a complete mapping but it is a hell
of a lot more easier to use */
main()
{
register i, j, k, l; /* change case or rtb your self */
int kase=2; /* 0 idenity mappingp */
/* 1 decending order mapping */
/* 2 worst case type */
/* build a 16 bit master table where remainder is max each time */
printf(" build remainder table make largest case \n");
for (i = 0; i < T16L; i++) {
rtb[i] = T16L - 1 - i;
ct[i] = i;
}
printf(" remainder table has been built \n");
/* build ftb btb and key1 from rtb */
for (i = 0; i < 256; i++) {
cpn[i] = 256;
cpp[i] = &ct[i * 256];
}
for (i = 0; i < T16L; i++) {
k = rtb[i]; /* this case ftb goes T16L-1 to 0 */
if(kase==0) k=0; /* this case ftb goes 0 to T16L-1 */
if(kase==2) k=k/2; /* this is slowest case */
for (j = 0, l = cpn[0]; k >= l;)
l += cpn[++j];
cp = cpp[j];
if (j != 0)
k = k - l + cpn[j];
cpn[j]--;
ftb[i] = cp[k];
btb[cp[k]] = i;
if (2 * k > cpn[j]) {
for (; k < cpn[j]; k++)
cp[k] = cp[k + 1];
} else {
for (; k > 0; k--)
cp[k] = cp[k - 1];
cpp[j]++;
}
/* just some minor print to see how it is doing */
if ((i > 32764)&&(i < 32776))
printf("yy %i %i %i\n", i, ftb[i], btb[ftb[i]]);
if (i > T16L - 5)
printf("yy %i %i %i\n", i, ftb[i], btb[ftb[i]]);
if (i < 4)
printf("xx %i %i %i\n", i, ftb[i], btb[ftb[i]]);
}
printf(" done building tables \n");
/* now lets test if it is right */
if (kase==0) for (i=0;i<T16L;i++){
if(btb[i]!=i){printf(" **error1** \n");break;}
if(ftb[i]!=i){printf(" **error2** \n");break;}
}
if (kase==1) for (i=0;i<T16L;i++){
if(ftb[i]!=T16L-i-1){printf(" **error3** \n");break;}
if(btb[i]!=T16L-i-1){printf(" **error4** \n");break;}
}
if (i==T16L)printf(" good table \n");
if (kase==2){ /* hell do a general test check
for a valid one to one mapping */
j=kase==2?0:1;
for (i=0;i<T16L;i++){
ct[i]=0;
if(ftb[i]==0)j=1;
}
if(j==0)printf(" *error5* \n");
for (i=0;i<T16L;i++){
ct[ftb[i]]=1; /* one could check bounds for real general case */
if(i!=btb[ftb[i]]){
j=0;
printf("%i %i %i \n",i,ftb[i],btb[ftb[i]]);
break;}
}
if(j==0)printf(" *error6* \n");
for(i=0;i<T16L;i++)if(ct[i]!=1)j=0;
if(j==0)printf(" *error7* \n");
}
if(j!=0)printf(" really good dog and pony show \n");
}
-----BEGIN PGP SIGNATURE-----
Version: DOWN.WITH.IDEA
Charset: cp850
iQEVAwUBMt6ht/NBkR2gE70pAQH6cAgAoTjzOlGa5ja7MYKsvlDiE/V7L5bRjvYs
hlrKJ8hzzXFPFDudcALsydxr89PsjHCHxcco6+HPSjYbVP/u/DdErwd093Ryroyg
ZdRAmD9dJf4UQ0VEIeykk1iI5anVoEeZg++u4juCMgRmyCVDGHj39fMuv2OCV35z
HFDXd7OLCyEAbWXDE6EOFOSkscsF9Ss7yNx4JrK1F2aZMTVtciuggy1sPkXSvg/v
YmyE/Pn0yAXvlikaEDHReeEXL3zso84X7YlrdaOBXg6h/KIiqkSZrnIx0WO6THPH
d7jg7h16Od+j/M3tVd8BSAyYNRsQTVF6ChKS0qFqDKrj8YE4yCasTw==
=AVDN
-----END PGP SIGNATURE-----
dave scott
In article <l87n2u9...@tinasolttu.cs.hut.fi>,
>> Finland.
>
attack anyone but the IDEA method itself. That was my attempt
at hurmor. I thought I was being funny but I guess to most people
I am a very strange fellow. I think if I do not get a job soon
that has a governemnt security clearance attached to it I will
actually spend some time and show people how to break this dam
thing. Because it can be done it is obvious from just a quick look
and by brake I mean this:
some one gives a sample of 16bit words in hex in groups of 8
to do same thing. I thought I pointed this out in the threads.
But even to do this you need a trusted person to come up with
the blocks. This would be a ture test. Not the mickey mouse short
thing the IDEA people had posted one time.
>
>> If is did not know better I would suspect you work for the NSA but
>> since you live in Finland you are more likely KGB
>
>.... but you seem to be. I'd say this concludes this discussion for my
>part. Oh, and I am still convinced IDEA is good enough.
>
No I do not work for the NSA I think they only take young people
but in some ways I wished I did. And if I did I would hope people
use stronger stuff than IDEA so as to make job fun and challenging.
>Camillo
>
dave scott
In article <5bm8jc$dio$1...@nntp.ucs.ubc.ca>,
un...@physics.ubc.ca (William Unruh) wrote:
>In <5bls8q$k...@ash.ridgecrest.ca.us> dsc...@ridgecrest.ca.us (dave scott)
writes:
>*>some one gives a sample of 16bit words in hex in groups of 8
>*>to make 64 bits. Then give me 100 randam 64 bits blocks with
>*>the matching out put blocks. all in 8 16bit word groupings
>*>then give me 10 more 64 bit blccks as described above and
>*>I will calulate what the matching output black would be. Notice
>*>I did not say solve for the key but what the method does.
>
>So, let me see what the test you propose is. We give you 100 random 64
>bit blocks plus for each of these blocks, we give you the output of IDEA
>for each of these blocks. (No chaining- each block is encrypted
>seperately and independently). We now give you one more 64 bit block and
>do not give you the output to IDEA. You will give us the encrypted
>version of that 64 bit block.
written in hex for ease of use. But 1 is ok to.
>
>Is this correct? The only reason I ask is that your first sentence above
>seems to be irrelevant to this test. If it is not then I guess I do not
>understand your test.
out I want to use 4 shown in hex 16 bit words in and out for each set.
I hope that was clear. I am somewhat dsylexic and have a hard time explaining
things that seem clear in my mind. However maybe that is not necessary.
I will work on it this summer if no one else does it. But it should be enough
to slove it.
>If this is what you mean, then, yes, I am sure that we could put you to
>the test, and yes, it would be an interesting test.
>(Of course, we will not give you the one key used to encrypt the above
>blocks).
>
dave scott
In article <5bm8jc$dio$1...@nntp.ucs.ubc.ca>,
un...@physics.ubc.ca (William Unruh) wrote:
>In <5bls8q$k...@ash.ridgecrest.ca.us> dsc...@ridgecrest.ca.us (dave scott)
writes:
>*>some one gives a sample of 16bit words in hex in groups of 8
>*>to make 64 bits. Then give me 100 randam 64 bits blocks with
>*>the matching out put blocks. all in 8 16bit word groupings
>*>then give me 10 more 64 bit blccks as described above and
>*>I will calulate what the matching output black would be. Notice
>*>I did not say solve for the key but what the method does.
>
>So, let me see what the test you propose is. We give you 100 random 64
>bit blocks plus for each of these blocks, we give you the output of IDEA
>for each of these blocks. (No chaining- each block is encrypted
>seperately and independently). We now give you one more 64 bit block and
>do not give you the output to IDEA. You will give us the encrypted
>version of that 64 bit block.
>
>seems to be irrelevant to this test. If it is not then I guess I do not
>understand your test.
1 64 bit word. But I only wanted it since SUN and PC swap bytes differently
and basically IDEA is 4 16 bit words in and 4 16 bit words out
plus so no confusion I want it in hex.
W T Shaw
> It's one thing to say that it would be easy to make a program that is
> even stronger, but quite another to say that a much stronger program
> is really needed.
Would you take a voyage in a ship that leaked only a little less than the
pumps could keep up with, or would you look for one that leaked little if
any? Apparent secuity overkill is meant to eclipse the unknown with some
reasonable expectation of margin.
When you try to cut things so closely that only friendlies can break it
and unfriendlies can't, you are really making some raw assumptions about
the abilities of various individuals and groups which may or not be
justified.
--
WTShaw, Macintosh CryptoProgrammer, wts...@htcomp.net
Private conversations should be protected. Right, Newt?
Support the development of an Electronic Bill of Rights
Proposal is at http://www.efflorida.org/florida/EBR.htm
dave scott
What follow is some old stuff I have notice PCBC you don't see it mentioned
much any more. Though it has some very nice features. Any body know why
could it be that it is more secure. Think about it.
5.14. What are ECB, CBC, CFB, OFB, and PCBC encryption?
These are methods for using block ciphers, such as DES, to encrypt
messages, files, and blocks of data, known as ``modes of operation.''
-- press space for next page --
Arrow keys: Up and Down to move. Right to follow a link; Left to go back.
(p56 of
128)
Four ``modes of operation'' are defined in FIPS 81 (1980 December 2),
and also in ANSI X3.106-1983.
FIPS 81 specifies that when 7-bit ASCII data is sent in octets, the
unused most-significant bit is to be set to 1.
FIPS 81 also specifies the padding for short blocks.
The four FIPS/ANSI standard DES modes of operation are:
Electronic Code Book (ECB),
Cipher Block Chaining (CBC),
K-bit Cipher FeedBack (CFB), and
K-bit Output FeedBack (OFB).
All four of the ANSI/FIPS modes have very little "error extension".
For a single bit error in the cipherstream, none of them produce an
error burst in the decrypted output stream of longer than 128 bits.
A fifth mode of operation, used in Kerberos and elsewhere but not
defined in any standard, is error-Propagating Cipher Block Chaining
-- press space for next page --
Arrow keys: Up and Down to move. Right to follow a link; Left to go back.
(p57 of
128)
(PCBC). Unlike the 4 standard modes, PCBC extends or propagates the
effect of a single bit error in the cipherstream throughout remainder
of the decrypted textstream after the point of error.
These 5 methods are explained below in a C-language-like notation.
Some symbols:
P[n] The n'th block of plaintext, input to encryption, output from
decryption. Size of block determined by the mode.
C[n] The n'th block of ciphertext, output from encryption, input to
decryption. Size of block determined by the mode.
E(m) The DES encryption function, performed on 64-bit block m, using
the 16-key schedule derived from some 56-bit key.
D(m) The DES decryption function, performed on 64-bit block m, using
the same key schedule as in E(m), except that the 16 keys
in the schedule are used in the opposite order as in E(m).
-- press space for next page --
Arrow keys: Up and Down to move. Right to follow a link; Left to go back.
(p58 of
128)
IV A 64-bit ``initialization vector'', a secret value which, along with
the key, is shared by both encryptor and decryptor.
I[n] The n'th value of a 64-bit variable, used in some modes.
R[n] The n'th value of a 64-bit variable, used in some modes.
LSB(m,k) The k least significant (right-most) bits of m.
e.g. m & ((1 << k) - 1)
MSB(m,k) The k most significant (left-most) bits of m.
e.g. (m >> (64-k)) & ((1 << k) - 1)
= ^ << >> & operators as defined in the c langage.
Electronic Code Book (ECB):
P[n] and C[n] are each 64-bits long.
-- press space for next page --
Arrow keys: Up and Down to move. Right to follow a link; Left to go back.
(p59 of
128)
Encryption: Decryption:
C[n] = E(P[n]) P[n] = D(C[n])
Cipher Block Chaining (CBC):
P[n] and C[n] are each 64-bits long.
Encryption: Decryption:
C[0] = E(P[0]^IV) P[0] = D(C[0])^IV
(n>0) C[n] = E(P[n]^C[n-1]) P[n] = D(C[n])^C[n-1]
Propagating Cipher Block Chaining (PCBC):
P[n] and C[n] are each 64-bits long.
Encryption: Decryption:
C[0] = E(P[0]^IV) P[0] = D(C[0])^IV
(n>0) C[n] = E(P[n]^P[n-1]^C[n-1]) P[n] = D(C[n])^P[n-1]^C[n-1]
-- press space for next page --
Arrow keys: Up and Down to move. Right to follow a link; Left to go back.
(p60 of
128)
k-bit Cipher FeedBack (CFB):
P[n] and C[n] are each k bits long, 1 <= k <= 64.
Encryption: Decryption:
I[0] = IV I[0] = IV
(n>0) I[n] = I[n-1]<<k | C[n-1] I[n] = I[n-1]<<k | C[n-1]
(all n) R[n] = MSB(E(I[n]),k) R[n] = MSB(E(I[n]),k)
(all n) C[n] = P[n]^R[n] P[n] = C[n]^R[n]
Note that for k==64, this reduces to:
I[0] = IV I[0] = IV
(n>0) I[n] = C[n-1] I[n] = C[n-1]
(all n) R[n] = E(I[n]) R[n] = E(I[n])
(all n) C[n] = P[n]^R[n] P[n] = C[n]^R[n]
CFB notes: Since I[n] depends only on the plain or cipher text from the
-- press space for next page --
Arrow keys: Up and Down to move. Right to follow a link; Left to go back.
(p61 of
128)
previous operation, the E() function can be performed in parallel with
the reception of the text with which it is used.
k-bit Output FeedBack (OFB):
P[n] and C[n] are each k bits long, 1 <= k <= 64.
Encryption: Decryption:
I[0] = IV I[0] = IV
(n>0) I[n] = I[n-1]<<k | R[n-1] I[n] = I[n-1]<<k | R[n-1]
(all n) R[n] = MSB(E(I[n]),k) R[n] = MSB(E(I[n]),k)
(all n) C[n] = P[n]^R[n] P[n] = C[n]^R[n]
Note that for k==64, this reduces to:
I[0] = IV I[0] = IV
(n>0) I[n] = R[n-1] I[n] = R[n-1]
(all n) R[n] = E(I[n]) R[n] = E(I[n])
(all n) C[n] = P[n]^R[n] P[n] = C[n]^R[n]
-- press space for next page --
Arrow keys: Up and Down to move. Right to follow a link; Left to go back.
(p62 of
128)
OFB notes: encryption and decryption are identical. Since I[n] is
independent of P and C, the E() function can be performed in advance of
the receipt of the plain/cipher text with which it is to be used.
Additional notes on DES ``modes of operation'':
ECB and CBC use E() to encrypt and D() to decrypt, but the feedback
modes use E() to both encrypt and decrypt. This disproves the following
erroneous claim: ``DES implementations which provide E() but not D()
cannot be used for data confidentiality.''
Charles N. Johnson
John: recognizing how busy I'd guess you are, can you be a bit more
specific about strengthening PGP using ECB with a byte-sized pre- and
post-wash with a stream cipher. Would you retain IDEA in ECB mode, or would
you use something like GHOST (assuming good s-boxes could actually be
constructed), or BLOWFISH, or ?? And the stream cipher?
Any insights would be greatly appreciated!
Cheers--
Charles
John Savard <sew...@netcom.ca> wrote in article
<5boq57$a...@tor-nn1-hb0.netcom.ca>...
> wts...@htcomp.net (W T Shaw) wrote:
>
[snip!]
> I am happy to suggest making PGP more secure, but I will not make
> blanket claims that its current security is unsatisfactory, or endorse
> such claims. I'd drop CBC mode, and just use ECB mode *plus*
> old-fashioned stream ciphers before and after - byte stream, not bit
> stream.
>
> John Savard
>
>
W T Shaw
In article <5blr1h$k...@ash.ridgecrest.ca.us>, dsc...@ridgecrest.ca.us
(dave scott) wrote:
>
> >> They are so bad
> >> that if one only has the middle third of a file but one has the key and
> >> algorithm used you can recover the data.
> >
> >We would like anyone who possesses the correct encryption key to be able to
> >recover as much of the plaintext as possible -- usually, all of it. If a
> >chunk of the ciphertext is missing, then information is irretrievably lost.
I totally agree. Solid communication may be impossible in some circumstances,
> >
> No that is not true for the internet. We usually compress files then send
> them encrytpted. You should check if you decrypted correctly by doing a
> pkunzip -t a.zip
> or what ever. If part of a file is missing especially a compressed file it
> does the reciever little good. And for Gods sake why would anyone want to
> send a file that only aportion is needed to break the code.
You are making a false assumption here about compression. It is only
advantageous for long files, not for something short or of standard
message length. The very act of compression and decompression just add
additional steps that may not be needed.
> It should be
> chainned together so that it would take whole file to break the code.
> if you don't get it all then ask for it again.
Tell that to someone in deep space where each leg of the communications
could take a long time. It is better to be as redundant as possible. The
old protocol of sending everything twice is often used for that reason.
With encryption, the copy need not be the same ciphertext.
> >> What this means for you, is that
> >> the enemy to break your message needs to study only a small portion of it.
> >> Good chaining for files should have 2 features not found in PGP's use
> >> of IDEA. 1. The chaining should require the whole file error free before
> >> it can be decoded.
In marginal circumstances this may not be feasible. You are cornered into
this requirement by your selection of algorithms and their reliance on it
to increase security, not by the innate value of doing it.
parker_rob
I am visiting from sci.crypt, after seeing a post by Dave Scott which
referred to a "WHY IDEA SUCKS" thread on this group (I guess he meant
this thread, which he apparently started).
To summarize the relevant parts of this thread so far, Dave Scott is
arguing that IDEA is a weak algorithm. As best I can follow it, his
argument goes as follows:
1. A 64-character (6-bit) simple substitution cipher is weak.
2. A 6-bit substitution cipher has (2^6)! = 64! ~= 1.27*10^89 possible
mappings (almost 2^296), and can be specified with 296 bits. Thus
a 6-bit substitution cipher has a "key" of length 296 bits.
3. IDEA has a key of length 128 bits, which is considerably less than
the 296-bit "key" of a 6-bit substitution cipher.
4. Since IDEA has a smaller key than a 6-bit substitution cipher, it
is "obviously" weaker than a 6-bit substitution cipher.
5. Thus IDEA is weak.
Why is this conclusion totally wrong? First let me address a few
specific points from one of his more recent posts...
dave scott (dsc...@ridgecrest.ca.us) wrote:
>In article <5bjluh$g...@tor-nn1-hb0.netcom.ca>,
> sew...@netcom.ca (John Savard) wrote
>>128 bits is adequate to avoid the possibility of brute-force attacks.
>>With a modest increase, to, say, 160 bits, it would match the key
>>lengths used in some military systems.
> I think we are killing a dead horse here. So get a life. I never said
>a dumb blind straight forward pure search was a good thing to try. So
>please stop repeating this one fact.
You seem to be missing something very important here; that's why people
keep repeating it.
> IN IDEA a multiply of one is the identity operator.
Yes, and a multiply by 0 (treated as 65536 or -1) will invert itself.
(For that matter, add or XOR by 0 is also the identity, and adding 0x8000
or XORing by 0xFFFF will invert themselves.)
That is why mutliplication modulo 65537 is combined with addition modulo
65536 (a non-linear combination) as well as 16-bit XOR, why there are
multiple rounds with a key schedule that shifts the 128-bit key through
a number of positions that make repeated multiplication by 1 (or -1)
unlikely. It is not as simple as you would suggest.
>so give me a break i was doing modular base multiplies while you where still
>sucking on your mama's teats well unless you are an old fart or i guess there
>is even the possibilty she refused to suckle you and it may have affected your
>ability to do math problems i really am not sure which case is true..
Oh what fun, more personal attacks. You sure know how to bolster your
arguments! You asked in a different post why someone did not respond
to another of your potentially-insulting comments; the reason is most
likely that they did not feel the comment was at all relevant to the
discussion.
Let's get back to the topic at hand and leave the insults to alt.flame.
>>>The quickest fix
>>>to IDEA that would guarantee a real key length of over 3,000,000 bits is
>>>to replace the first 4 subkeys and the functions where they are used with
>>>mappings based on 954,037 bit keys for each of the 4 mappings.
>>
>>The 2^128 combinations represented by 128 bits are indeed less than
>>(2^64) factorial. But that is an inevitability rather than a weakness.
>
> i never gave a number approaching the number of bits in (2^64)! so
>i think you are lost.
I guess the number you gave was the number of bits in (2^16)! My quick
estimate shows that this would be over 900,000 bits (but I think less
than 1,000,000). The question is then what does this value have to do
with IDEA? IDEA is a 64-bit substitution cipher. It is not a simple
combination of four 16-bit substitution ciphers, that much would certainly
have been proven by the inventors, or it would have been easily proven
to be a simple combination of four 16-bit substitution ciphers by the
investigations of others (and we would certainly have heard about such a
weakness from credible sources), and it would be considerably weaker than
it is actually considered to be (by those with expertise in this area).
>>CBC and OFB modes are not inherently all that much more secure than
>>ECB, so we can accept this as a philosophical point about the weakness
>>of block ciphers in general. However, 2^64 is a BIG number. And PGP
>>compresses text before encrypting it.
>
> We do not have to accept this as a weakness of block ciphers. We can
>chain a hell of a lot better.
First of all, the chaining method has nothing to do with the IDEA
algorithm. There are a number of chaining methods (I suggest you
check out the sci.crypt FAQ (the one with about 10 parts) and look
for the section about block-chaining methods (near the info about
DES and other secret-key block ciphers)), and they are essentially
independent of the actual block-cipher algorithm used (provided it
is "secure" in the first place). An analysis of a given block-cipher
algorithm's general strength would best be done at the basic level
of individual blocks; if it is weak here then block chaining will not
significantly improve the security, and if it is sufficiently stong
at the individual block level then you can chose whatever chaining
method meets the requirements of your application.
Second, how do you think we can chain better (ie, with better security)
than with methods that are already known and have been studied and
compared by those with much more experience than you or I?
Ok, let me repeat my summary of Dave Scott's argument:
1. A 64-character (6-bit) simple substitution cipher is weak.
2. A 6-bit substitution cipher has (2^6)! = 64! ~= 1.27*10^89 possible
mappings (almost 2^296), and can be specified with 296 bits. Thus
a 6-bit substitution cipher has a "key" of length 296 bits.
3. IDEA has a key of length 128 bits, which is considerably less than
the 296-bit "key" of a 6-bit substitution cipher.
4. Since IDEA has a smaller key than a 6-bit substitution cipher, it
is "obviously" weaker than a 6-bit substitution cipher.
5. Thus IDEA is weak.
So why is this conclusion totally wrong? The problem is essentially
in number 4. This faulty assertion stems from a misunderstanding
about the insecurity of 6-bit substitution ciphers.
The leap from #3 to #4 assumes that the strength of *any* substitution
cipher depends primarily on the size of space of available substitution
functions (the number of different "keys"). Since a general 6-bit
substitution cipher has 64! possible substitution functions, it has
a "key" space of approximately 2^296 (it could be expressed with a
296-bit key, though the lookup table itself requires 64*6 = 384 bits
for efficient opperation). Since IDEA has a key size of 128 bits, the
number of possible substitution functions is only 2^128, considerably
less than the number of possible 6-bit substitution ciphers. All this
appears completely correct, so what is wrong with #4?
The problem is that no attention has been paid to *how* a 6-bit
substitution cipher (with it's very large key space) is cracked so
easily. First, how is it *not* cracked: It is not cracked by testing
each possible "key" with no progress until the entire key is guessed
correctly; that would take on average (2^296)/2 opperations which,
with 10^18 computers each performing 10^18 tests per second, would
take over 10^45 years. Even with 2*10^51 computers (which is more
than the number of electrons on Earth), each running 10^18 tests per
second, it would still take over 10^12 years on average (which, I
believe, is longer than the age of the universe, and is much longer
than it will take for our sun to exhaust itself and become a red dwarf).
Clearly there is a faster way to crack a 6-bit substitution cipher.
The fact is, the properties of such a cipher allow the "key" to be
attacked piece-by-piece and not only all-or-nothing. Using frequency
analysis it is relatively simple to pin down the more frequently-
occuring ciphertext characters to being most likely from a small
set of plaintext characters. When a relatively small number of
ciphertext characters are correctly decrypted, words or perhaps
partial words become recognizable which confirms a part of the "key"
and usually starts to give probable decryptions for other characters
(to complete the words). If the actual plaintext is known for a
fairly small amount of ciphertext, the attack is even faster. This
makes the security limited not by the size of the 64! possible 6-bit
substitution functions, but by the size of the block. Performing
a similar analysis on a 64-bit block is *much* more difficult than
on a 6-bit character, enough more that it is essentially impossible.
The fact that IDEA has only 2^128 possible substitution functions
compared to 2^296 possible 6-bit substitutions does not make it
proportionally weaker than 6-bit substitution ciphers, because the
primary weakness of a 6-bit substitution cipher comes from it's
small block size, over which the 64-bit block of IDEA is a massive
improvement.
A true analysis of the strength of IDEA requires a further understanding
of the principles by which secure block ciphers are designed, and will
have to wait for a separate post (and I can only discuss it in general
terms, not solid proofs). If you are interested in truly understanding
these security issues about algorithms and protocols, you should read
sci.crypt, starting with the FAQ (posted every couple of weeks, at least).
Please try reading for a while before posting, and if you aren't learning
enough from that please try posting short questions instead of launching
into a massive post about how you know better than all the public
researchers in cryptography--who have so far been unable to find any way
to crack IDEA (or even DES, with it's much smaller keyspace than IDEA)
anywhere near as easily as a general 6-bit substitution cipher can be
cracked (except for certain "weak" keys that can be "easily" cracked by
a chosen-plaintext attack--see the sci.crypt FAQ, I think they explain
what that is--but they can be easliy checked against and not used).
It might also be a good idea to read books on modern cryptography.
"Applied Cryptography" by Bruce Schneier is pretty good and often
mentioned on sci.crypt. It includes a discussion of IDEA specifically
(as well as many other algorithms) and what is known about its security.
By the way, you will be happy to know that your feeling that IDEA could
be more secure with independent subkeys is probably correct (though it
may not be)--but the benefit is probably nowhere near as much as you
might expect from the new keyspace, and certainly does not mean that
the standard IDEA algorithm is "too weak".
-Rob Parker (only an *amateur* cryptographer, if that)
parker_rob
W T Shaw (wts...@htcomp.net) wrote:
>In article <5bjluh$g...@tor-nn1-hb0.netcom.ca>, sew...@netcom.ca (John
>
>> It's one thing to say that it would be easy to make a program that is
>> even stronger, but quite another to say that a much stronger program
>> is really needed.
>Would you take a voyage in a ship that leaked only a little less than the
>pumps could keep up with, or would you look for one that leaked little if
>any? Apparent secuity overkill is meant to eclipse the unknown with some
>reasonable expectation of margin.
>When you try to cut things so closely that only friendlies can break it
>and unfriendlies can't, you are really making some raw assumptions about
>the abilities of various individuals and groups which may or not be
>justified.
They aren't talking about security that is "close" to breakable. Dave
Scott erroneously believes that IDEA is "breakable" because the number
of possible keys (2^128) is considerably smaller than the number of
possible keys of known-breakable 6-bit simple substitution ciphers
(which have 64! or about 2^296 "keys").
John Savard is trying to point out that while IDEA might be made stronger,
there is no reason to believe it is in any way necessary (because IDEA is
apparently plenty strong enough to resist any practical attack), and it
is not clear that independent subkeys would vastly increase the security.
You have to also consider that a 104-byte key is more awkward to handle
than a 16-byte key.
At least I *think* that's what he was trying to point out; it's hard to
be sure with the lack of context which you or he have omitted.
-Rob Parker
parker_rob
dave scott (dsc...@ridgecrest.ca.us) wrote:
[...Attribution omited by Dave Scott...]
>>It is also very small. The IDEA module in PGP 2.6.3i compiles to less than
>>6K with MSCV C++ 4.2b. The C++ version I wrote is less than 8k.
>>
>>And these are the three real criteria for such algorithms: small, fast, and
>>tough. As Schneier points out, making tough algorithms big and slow is easy
> I would agree when I was on some of the earlier computers that had a max
>memory size of 16k however the complete mapping that i was talking about
>for 16 bits which has a real key of 954037 does take a second or 2 to make
>the table and the table is 128k in size but it is a screamer it involves
>only a look up table. For large files it would leave your IDEA in the dust.
Actually, a mere 16-bit block size would be considerably weaker than IDEA
against certain attacks. A dictionary attack (which involves a known-
or chosen-plaintext attack to reproduce the "dictionary", ie a substitution
table) would require only the 128 KB space and 2^16 operations (perhaps
more if neither the plaintext nor ciphertext can be chosen by the attacker)
which is well within the realm of attainability. On a 64-bit block, the
attack would require 147 Exabytes (1 Exabyte is a billion billion bytes,
or 10^18 bytes) of storage and would take 2^64 opperations (more if ...).
This *might* be possible in the next couple decades, but it would still
be very expensive and require access to a considerable amount of plaintext
(and corresponding ciphertext), which is no small task. A dictionary
attack against a 16-bit block could be done with resources trivially
attainable today and access to a much smaller amount of plaintext and
ciphertext.
It might even be possible to effectively attack a 16-bit substitution
cipher with *no* prior knowledge of the plaintext just by statistical
analysis (pretty likely if ECB mode is used and without compression
of the plaintext, since a 16-bit block only contains two characters).
Experts believe a 64-bit block to be large enough to prevent such analysis.
-Rob Parker
parker_rob
dave scott (dsc...@ridgecrest.ca.us) wrote:
> What follow is some old stuff I have notice PCBC you don't see it mentioned
>much any more. Though it has some very nice features. Any body know why
>could it be that it is more secure. Think about it.
It is probably not "avoided because it is more secure". While there may
be individuals and organizations who would like us to use weaker security
(so that they can break it, presumably), there are also competent people
who can analyze the security of various algorithms and protocols and who
make publish their findings. If it were significantly more secure than
the other chaining methods, you would be likely to see credible sources
recommending it for applications in which error-propagation is not a
problem.
Each of the five methods (and others you might come up with) have
their advantages and disadvantages. Some of these can affect security.
For example, OFB mode is simply acting like a PRNG which is then XOR'd
with the plaintext. This is pretty good against passive attacks, but
it has no protection against alteration by an enemy; Mallet can change
any plaintext bits (and exactly the bits he wants to), and if he actually
knows the true plaintext he can alter it to any other value he wants
without affecting bits he doesn't want to. With the other modes, attempts
to do this without knowing the actual key (or otherwise reproducing the
encryption/decryption effects) will result in uncontrolable results
(he can change them, but has little control over what it will do to
the recovered plaintext, making it likely to be noticed as an error).
PCBC is simply less useful in some applications *because* it is
intentionally less tollerant of errors in the ciphertext. As an
example, consider an encrypted file. If you encrypt an important
file using PCBC (and destroy the original, of course), and the
encrypted file then gets partially corrupted (even a single bit),
then everything from approximately the point of the error through
the end of the file is unrecoverable. You can't simply request a
new copy of the ciphertext, because no one has a copy of the original
to re-encrypt. If a non-propagating mode is used, you can still
recover most of the file and (as long as you didn't compress it or
something) you can likely recover the lost information, provided
the errors are very localized.
If you think there is an attack which PCBC protects against much better
than other modes, please describe the attack, and we'll see if we agree
with you or if we can explain how it is not significantly better than
other modes.
>5.14. What are ECB, CBC, CFB, OFB, and PCBC encryption?
[...]
> The four FIPS/ANSI standard DES modes of operation are:
> Electronic Code Book (ECB),
> Cipher Block Chaining (CBC),
> K-bit Cipher FeedBack (CFB), and
> K-bit Output FeedBack (OFB).
>
> All four of the ANSI/FIPS modes have very little "error extension".
> For a single bit error in the cipherstream, none of them produce an
> error burst in the decrypted output stream of longer than 128 bits.
>
> A fifth mode of operation, used in Kerberos and elsewhere but not
> defined in any standard, is error-Propagating Cipher Block Chaining
> (PCBC). Unlike the 4 standard modes, PCBC extends or propagates the
> effect of a single bit error in the cipherstream throughout remainder
> of the decrypted textstream after the point of error.
[Leave this part in your response, for future reference]
>
> Propagating Cipher Block Chaining (PCBC):
>
> P[n] and C[n] are each 64-bits long.
>
> Encryption: Decryption:
> C[0] = E(P[0]^IV) P[0] = D(C[0])^IV
> (n>0) C[n] = E(P[n]^P[n-1]^C[n-1]) P[n] = D(C[n])^P[n-1]^C[n-1]
-Rob Parker
W T Shaw
In article <5bp4ip$6...@gazette.loc3.tandem.com>, rpa...@loc3.tandem.com
(parker_rob) wrote:
>
> They aren't talking about security that is "close" to breakable. Dave
> Scott erroneously believes that IDEA is "breakable" because the number
> of possible keys (2^128) is considerably smaller than the number of
> possible keys of known-breakable 6-bit simple substitution ciphers
> (which have 64! or about 2^296 "keys").
>
> John Savard is trying to point out that while IDEA might be made stronger,
> there is no reason to believe it is in any way necessary (because IDEA is
> apparently plenty strong enough to resist any practical attack), and it
> is not clear that independent subkeys would vastly increase the security.
> You have to also consider that a 104-byte key is more awkward to handle
> than a 16-byte key.
A good answer is that keysize of the same lengths may have different real
strengths in different algorithms, and most likely do. As I understand,
PGP's weakest point, if you might call it that, is not in IDEA, but
elsewhere. Off line discussions with others indicate widespread agreement
that the logic behind a perception weakness in IDEA in this thread in not
well founded. But, we should try to stay open to any such claim in quest
for the nature of the matter.
>
> At least I *think* that's what he was trying to point out; it's hard to
> be sure with the lack of context which you or he have omitted.
That's a problem with long discussions. Sometimes you can purge too much,
it was not intentional.
Jill Baker
>To summarize the relevant parts of this thread so far, Dave Scott is
>arguing that IDEA is a weak algorithm. As best I can follow it, his
>argument goes as follows:
Dave Scott's statements have received much criticism in this thread. But I can
agree with him *up to a point*. I also think his words have been
misunderstood. At the risk of unintentionally upsetting Dave, I will try to
paraphrase his proposition, in the hope of stating it (hopefully) more
clearly.
Imagine you have a very large sheet of paper, and a pen, and an unlimited
amount of time.
Draw a table with 2^128 rows and 2^64 columns. The rows are labelled with all
possible 128-bit keys, and the columns are labelled with all possible 64-bit
data blocks.
Now fill in the table by assigning to each cell the result of encrypting the
column's data-block using the row's encryption key, and the IDEA algorithm.
This table gives you all possible outcomes of IDEA encryption.
Dave asserts (correctly) that *some* rows of the table will identical to (or
easily derivable from) some preceeding row. (This includes the column
headings themselves - the plaintext).
Eliminating such rows from the table produces a smaller table. The height of
this new table is what Dave refers to as the "real key size", which I believe
is a term he invented. He notes (correctly) that this number is greater than
2^64, and less than 2^128.
He asserts that it is possible to devise a modified-IDEA algorithm which, when
the above steps are followed, would produce a table with more rows than
plain-IDEA. In his language, the "real key size" would be greater. (We don't
know, of course, whether or not this claim is true, since his modified-IDEA
algorithm has not been published on this newsgroup, and has not been subjected
to close scrutiny).
But let's give him the benefit of the doubt, and assume that he has indeed
produced a stronger algorithm. Thus we would have:
2^64 < RealKeySize(IDEA) < RealKeySide(modified-IDEA) < 2^128
Which brings us - finally - the question "So What?". Is IDEA weak?
The question hinges on the actual numerical value of RealKeySize(IDEA). If it
close to 2^64, then IDEA is weak. If it is close to 2^128 then IDEA is strong.
For what it's worth, the evidence I have seen leads me to suspect that it is
much closer to 2^128 than to 2^64, and my intuition (unreliable though that
may be) tells me it is likely to be greater than 2^127. Thus, I am convinced
that IDEA is indeed strong, despite a small amount of redundancy, and that it
is safe for me to continue to use it.
Dave, please feel free to jump in if I have misrepresented you.
Jill (my opinions are my own, no-one else's)
-----------------------------------------------------------------------
PGP Key ID: 0xA3C0D615
Fingerprint: 37 4A 75 9E 50 90 8A 35 55 3D DE DD 56 E5 F7 F3
John Savard
"Charles N. Johnson" <char...@mail.idt.net> wrote:
>John: recognizing how busy I'd guess you are, can you be a bit more
>specific about strengthening PGP using ECB with a byte-sized pre- and
>post-wash with a stream cipher. Would you retain IDEA in ECB mode, or would
>you use something like GHOST (assuming good s-boxes could actually be
>constructed), or BLOWFISH, or ?? And the stream cipher?
>Any insights would be greatly appreciated!
I definitely wouldn't use GOST. IDEA is a good block cipher, although
it is proprietary. And, the use of modulo-65537 multiplication as
though it were addition with an S-box does raise the very slight
possibility of a mathematical weakness. I think that IDEA, DES,
Blowfish, or SAFER are all reasonable alternatives. (Of course,
there's always QUADIBLOC...a block cipher I designed myself a few
months back in sci.crypt.)
Even a simple stream cipher, that is insecure in itself, used in
combination with a block cipher in ECB mode far surpasses the gain in
security with CBC mode. That is why I wasn't specific: because nearly
any stream cipher would provide a significant improvement.
However, as a reasonably strong stream cipher, I would suggest the
following variation on McLaren-Marsaglia:
For each random byte desired:
1) Generate _two_ pseudorandom numbers using a mixed-congruential
generator operating modulo 2^128, and retain only the most significant
byte of each;
2) Using two additional mixed-congruential generators, modulo A^n and
B^m, where A and B are two odd primes, pick an element from each of
two buffer arrays, initially filled with pseudo-random bytes, and take
those two elements, XOR them to produce your random byte, and replace
them with the two bytes you generated in step 1.
Such bytes will have excellent statistical properties, and should even
have a modicum of cryptosecurity.
Before and after XOR-ing these bytes to your data stream, use a
256-byte lookup table to perform a simple substitution on the data as
well.
This will increase the key length vastly, and eliminate
known-plaintext attacks on the block cipher.
John Savard
sal
Jill
I enjoyed your posting but I would appreciate it if you could expand in
more detail on your statement:
"Dave asserts (correctly) that *some* rows of the table will identical to
(or
easily derivable from) some preceding row."
This statement is difficult for me to fathom:
For, if the "rows" are independently and randomly derived from the IDEA
keyspace I'm not sure why any row would, necessarily, be "identical to (or
easily derivable from)" any other row.
How could the row be so easily transparent?
Perhaps an example would make your statement more clear to me. I seem to be
missing something.
Thanks
sal-
Jill Baker
"sal" <sal...@not.concentric.net> wrote:
>Perhaps an example would make your statement more clear to me. I seem to be
>missing something.
I don't claim to be an expert, I'm afraid, and I don't know of any examples.
But it has been pointed out in this ng before a *particular subset* of IDEA
keys produces cyphertext which is weak. I think the poster said this was true
of keys of the form 0x00000000000000000000????????0000 (or something like that
- I wrote that from memory so it's probably wrong). Of course it is absurdly
unlikely that you would end up with such a key by random chance.
Dave also made some assertions about other keys. I confess I don't know how
IDEA works, but I gather that the key is split into 8 16-bit variables, and
these variables are used as parameters in a mathematical algorithm. Dave
pointed out that ((A EOR x)*B) EOR A) will always equal x if B equals one,
irrespective of the value of A. I don't have enough knowledge to know whether
or not this step occurs in the IDEA algorithm, but if it does, and if A is not
used elsewhere in the algorithm, then it would be true that for the 2^16 keys
in which B=1, the value of A would be irrelevant, and so there would be 2^16
identical rows in the table. But as I said - I have absolutely no idea of the
mathematical details of IDEA - I am speaking from a position of ignorance
here. I just gave Dave the benefit of the doubt.
(Nonetheless, I remain convinced that IDEA is strong enough for me).
Paul L. Allen
In article <853631...@mist.demon.co.uk>
io...@mist.demon.co.uk (Iolo Davidson) writes:
> In article <5bls8q$k...@ash.ridgecrest.ca.us>
> dsc...@ridgecrest.ca.us "dave scott" writes:
>
> > I think if I do not get a job soon
> > that has a governemnt security clearance attached to it I will
> > actually spend some time and show people how to break this dam
> > thing.
>
> That is what it would take.
Ummm, you mean the time? Yeah, quite a lot of it.
> > Because it can be done it is obvious from just a quick look
>
> But this comment convinces me that you will not be able to do it.
Why did you have to go and tell him that? I was going to enjoy watching
him spend the rest of his life trying.
--Paul
Jill Baker
rpa...@loc3.tandem.com (parker_rob) wrote:
>Perhaps you and/or Dave are confusing uniqueness for a
>specific block with uniqueness for an entire "row".
Hey, don't include me in this! I've already said I that I believe is very
strong. _I'm_ not the one claiming otherwise.
For what it's worth, I agree with you. (And thank you for elaborating on some
of the mathematical fallacies upon which Dave's argument partly rests).
parker_rob
To followup my own post...
parker_rob (rpa...@loc3.tandem.com) wrote:
>There is no way the number of unique keys in IDEA is anywhere near as
>low as 2^64.
> For a given block
>there are 2^64 unique encryptions (one being itself) while there are
>2^128 different keys. Obviously each possible encryption is going to
>occur with around 2^64 different keys, for that given block. However,
>those sets of keys redundant for *that* block have no necessary relation
>at all to the sets of keys that are redundant for any other block.
>The important question is then: for a given key, how many different
>blocks does it encrypt the same way as a second given key? This is
>at least 1, but is it much higher than this? (If you answer, be sure
>to argue with pretty solid mathematics.)
Actually, it appears that for some pairs of keys, there might be *no*
blocks that they encrypt the same way. For a given key and a given
block there are 2^64-1 *other* keys that would encrypt that block to
the same ciphertext as the given key (assuming absolutely uniform
distribution of the "redundant" keys, so that exactly 2^64 keys map
a given plaintext block to a given ciphertext block). Since there
are 2^64 blocks, for a given key there are at most 2^64 * 2^64-1
*other* keys that will encrypt at least one block the same way. This
is 2^128 - 2^64, which leaves 2^64-1 *other* keys that will not encrypt
*any* blocks the same as the given key. It appears possible for all
other pairs of keys to have no more than one block that will be encrypted
to the same ciphertext by both keys. (Of course, this may not actually
be the case for IDEA, it is (we would hope) too complicated to make
determining the true answer for IDEA an easy task.)
-Rob Parker
parker_rob
Jill Baker (jba...@pobox.com) wrote:
>Dave Scott's statements have received much criticism in this thread. But
>I can agree with him *up to a point*. I also think his words have been
>misunderstood. At the risk of unintentionally upsetting Dave, I will try
>to paraphrase his proposition, in the hope of stating it (hopefully) more
>clearly.
>Imagine you have a very large sheet of paper, and a pen, and an unlimited
>amount of time.
>Draw a table with 2^128 rows and 2^64 columns. The rows are labelled with
>all possible 128-bit keys, and the columns are labelled with all possible
>64-bit data blocks.
>Now fill in the table by assigning to each cell the result of encrypting the
>column's data-block using the row's encryption key, and the IDEA algorithm.
>This table gives you all possible outcomes of IDEA encryption.
>
>Dave asserts (correctly) that *some* rows of the table will identical to
>(or easily derivable from) some preceeding row. (This includes the column
>headings themselves - the plaintext).
I don't think Dave was actually asserting this, and I don't think it can
be shown that it *must* be true. This assertion is saying that there
exist at least some pairs (or sets) of keys for which *all* plaintext
blocks encrypt to the same ciphertext block, or that at least the encryption
(decryption) of *all* blocks for some keys can be derived from the
encryption (decryption) of some other key. This sounds like a related-key
attack, and I think IDEA has been found to resist such attacks (though
I'd have to recheck "Applied Cryptography" to be sure I'm not confusing
it with something else). Also, there are (2^64)! different reversible
mappings, and IDEA only uses 2^128 of them, a *VERY* small fraction, so
it is not hard to believe that each 128-bit key produces a unique encryption
function on a 64-bit block.
Dave's argument is more that the key space of a 6-bit simple substitution
cipher (about 296 bits) is much greater than IDEA's 128 bits, and yet
6-bit substitution ciphers are known to be easily broken; then then
incorrectly ascribes a weakness to IDEA's key space from this. Of course,
he may have had more than one point, and the idea you are getting at may
have been in there somewhere, too.
>Eliminating such rows from the table produces a smaller table. The height of
>this new table is what Dave refers to as the "real key size", which I believe
>is a term he invented. He notes (correctly) that this number is greater than
>2^64, and less than 2^128.
I think his "real key size" was the size of the "key" to represent all
possible 64-bit substitution ciphers. He argued that the size of a "key"
for a 16-bit substitution cipher would be around 950,000 bits, and the
lookup-table would be 128 KB (not that this is 16-bit, not 64-bit). He
suggests that including this 950,000-bit "key" in a modification to
IDEA would "correct" the weakness of IDEA's "small" 128-bit key. He is
probably wrong at a number of levels. IDEA does not have a weakness in
its 128-bit key, so it does not need to be corrected. Nor is there any
reason to believe that adding a 16-bit simple-substitution step with a
128 KB lookup table initialized from a key of around 950,000 bits would
significantly improve the security of IDEA (though it would make a brute-
force keyspace search a bit harder, it is already plenty hard; and it
would most likely *not* make it as hard as searching 950,000 bits of
keyspace). It might even weaken it by disrupting the careful design
of IDEA.
>He asserts that it is possible to devise a modified-IDEA algorithm which,
>when the above steps are followed, would produce a table with more rows
>than plain-IDEA. In his language, the "real key size" would be greater.
>(We don't know, of course, whether or not this claim is true, since his
>modified-IDEA algorithm has not been published on this newsgroup, and has
>not been subjected to close scrutiny).
>
>But let's give him the benefit of the doubt, and assume that he has indeed
>produced a stronger algorithm. Thus we would have:
>
> 2^64 < RealKeySize(IDEA) < RealKeySide(modified-IDEA) < 2^128
Actually, his modification would probably have more unique mappings
(effective number of keys) than 2^128, since he is talking about adding
a *ton* of bits to the "key" space. The problem is, there are many
more factors that affect security than the number of unique keys.
A small keyspace is a fairly good guarantee of a weak algorithm
(a 40-bit key is not very hard to crack by brute-force), but a large
keyspace is *not* a guarantee of a strong algorithm (the 296-bit "key"
of a 6-bit substitution cipher is quite easy to break). In his misguided
attempt to increase the keyspace of IDEA, he may end up introducing
weaknesses that could make his modified algorithm weaker than IDEA itself.
>Which brings us - finally - the question "So What?". Is IDEA weak?
>
>The question hinges on the actual numerical value of RealKeySize(IDEA).
>If it close to 2^64, then IDEA is weak. If it is close to 2^128 then IDEA
>is strong. For what it's worth, the evidence I have seen leads me to
>suspect that it is much closer to 2^128 than to 2^64, and my intuition
>(unreliable though that may be) tells me it is likely to be greater than
>2^127. Thus, I am convinced that IDEA is indeed strong, despite a small
>amount of redundancy, and that it is safe for me to continue to use it.
There is no way the number of unique keys in IDEA is anywhere near as
low as 2^64. Perhaps you and/or Dave are confusing uniqueness for a
specific block with uniqueness for an entire "row". For a given block
there are 2^64 unique encryptions (one being itself) while there are
2^128 different keys. Obviously each possible encryption is going to
occur with around 2^64 different keys, for that given block. However,
those sets of keys redundant for *that* block have no necessary relation
at all to the sets of keys that are redundant for any other block.
The important question is then: for a given key, how many different
blocks does it encrypt the same way as a second given key? This is
at least 1, but is it much higher than this? (If you answer, be sure
to argue with pretty solid mathematics.)
In a later post, Jill Baker (jba...@pobox.com) wrote:
%I don't claim to be an expert, I'm afraid, and I don't know of any examples.
%
%But it has been pointed out in this ng before a *particular subset* of IDEA
%keys produces cyphertext which is weak. I think the poster said this was true
%of keys of the form 0x00000000000000000000????????0000 (or something like that
%- I wrote that from memory so it's probably wrong). Of course it is absurdly
%unlikely that you would end up with such a key by random chance.
The form of the weak keys is not quite right, but it is *something* like
that--the poster you got it from didn't have it quite right, either, there
is another "don't-care" digit near the left end. I believe such keys are
"weak" because they "leak" key information into the ciphertext and can be
found fairly easily if used. Note that this does not mean that the various
"weak" keys have any obvious similarity in their encryption function.
%Dave also made some assertions about other keys. I confess I don't know how
%IDEA works, but I gather that the key is split into 8 16-bit variables, and
%these variables are used as parameters in a mathematical algorithm. Dave
%pointed out that ((A EOR x)*B) EOR A) will always equal x if B equals one,
%irrespective of the value of A. I don't have enough knowledge to know whether
%or not this step occurs in the IDEA algorithm, but if it does, and if A is not
%used elsewhere in the algorithm, then it would be true that for the 2^16 keys
%in which B=1, the value of A would be irrelevant, and so there would be 2^16
%identical rows in the table. But as I said - I have absolutely no idea of the
%mathematical details of IDEA - I am speaking from a position of ignorance
%here. I just gave Dave the benefit of the doubt.
IDEA uses 8 rounds with non-trivial shifts of the key in a non-trivial
(but not hard to implement) key schedule. Each round is more complex
than the XOR, times, XOR Dave talks about. (I have a post on sci.crypt
on the thread "IDEA?" which gives a block diagram of *part* of an IDEA
round. The diagram in "Applied Cryptography" by Bruce Schneier is
probably much easier to follow and is more complete--though there was
an error in the first edition.)
%(Nonetheless, I remain convinced that IDEA is strong enough for me).
-Rob Parker
David Scott
W T Shaw <wts...@htcomp.net> wrote in article
<wtshaw-1701...@pppc31-40.htcomp.net>...
> In article <5blr1h$k...@ash.ridgecrest.ca.us>, dsc...@ridgecrest.ca.us
> (dave scott) wrote:
>
> >
> > >> They are so bad
> > >> that if one only has the middle third of a file but one has the key
and
> > >> algorithm used you can recover the data.
> > >
> > >We would like anyone who possesses the correct encryption key to be
able to
> > >recover as much of the plaintext as possible -- usually, all of it. If
a
> > >chunk of the ciphertext is missing, then information is irretrievably
lost.
>
> I totally agree. Solid communication may be impossible in some
circumstances,
Sir I am addressing the situation where there is solid communications. I
want the
whole program or resend it.
> > >
> > No that is not true for the internet. We usually compress files then
send
> > them encrytpted. You should check if you decrypted correctly by doing a
> > pkunzip -t a.zip
> > or what ever. If part of a file is missing especially a compressed file
it
> > does the reciever little good. And for Gods sake why would anyone want
to
> > send a file that only aportion is needed to break the code.
>
> You are making a false assumption here about compression. It is only
> advantageous for long files, not for something short or of standard
> message length. The very act of compression and decompression just add
> additional steps that may not be needed.
I disagree. The additional steps may help encrypt and if computer set up
correctly these extra steps are very short.
>
> > It should be
> > chainned together so that it would take whole file to break the code.
> > if you don't get it all then ask for it again.
>
> Tell that to someone in deep space where each leg of the communications
> could take a long time. It is better to be as redundant as possible.
The
> old protocol of sending everything twice is often used for that reason.
> With encryption, the copy need not be the same ciphertext.
If the message is that dam important that it must be redundant and if
it of form still good if only partly recieved you are right. But if your
goal
is the whole message or none and totally security then I am right.
>
David Scott
Jill Baker <jba...@pobox.com> wrote in article
<5bvetc$8...@madge2.dev.madge.com>...
> Dave Scott's statements have received much criticism in this thread. But
I can
> agree with him *up to a point*. I also think his words have been
> misunderstood. At the risk of unintentionally upsetting Dave, I will try
to
> paraphrase his proposition, in the hope of stating it (hopefully) more
> clearly.
You did not upset me. But I could not follow what you said. In that I
don't
think that is what I totally meant. My English sucks but I like your style
may the two of use could fix this.
>
>
> Dave asserts (correctly) that *some* rows of the table will identical to
(or
Well I only stated, or meant to state that some might be same I do not
know.
> easily derivable from) some preceeding row. (This includes the column
> headings themselves - the plaintext).
>
> Eliminating such rows from the table produces a smaller table. The height
of
> this new table is what Dave refers to as the "real key size", which I
believe
Well the number of binary bits to write number representing the rows left
would
be my term for REAL KEY SIZE
> is a term he invented. He notes (correctly) that this number is greater
than
> 2^64, and less than 2^128.
>
> He asserts that it is possible to devise a modified-IDEA algorithm which,
when
> the above steps are followed, would produce a table with more rows than
> plain-IDEA. In his language, the "real key size" would be greater. (We
don't
> know, of course, whether or not this claim is true, since his
modified-IDEA
> algorithm has not been published on this newsgroup, and has not been
subjected
> to close scrutiny).
Well depending on which mod i made two suggestions. One was to use the
unrolled key where eack one of 52 16 bit blocks is part of key. This one I
am
not sure of its "real key lenght" but its longer than the one IDEA uses.
And
Should be harder to break since normal IDEA is a subset of it. I grant the
fact
if one uses poor choice in keys they could be solved but lets give people
some
credit for brains.
The second mode which I stated had a "real key length" of over 3 million
was
based on use of 4 table look ups a seperate table on each 1 of the 4 16bit
words
that go into the IDEA block. This would make it very strong. This would not
be used
for normal pgp public key stuff since the key is encrypted and sent along
but
would be very usefully if you give you friend a 3.5 inch floppy with the
key 2 of
you share for methods. Of course never save raw key on your machine have it
protected by a pass pharase.
>
> Which brings us - finally - the question "So What?". Is IDEA weak?
>
> The question hinges on the actual numerical value of RealKeySize(IDEA).
If it
> close to 2^64, then IDEA is weak. If it is close to 2^128 then IDEA is
strong.
Well i keep repeating my self. The 6 bit table look up was only to show
that
methods with key lengths longer then what IDEA could be are not safe. So
one should not feel safe just becasue it might have a real key length of
128
bits.
> For what it's worth, the evidence I have seen leads me to suspect that it
is
> much closer to 2^128 than to 2^64, and my intuition (unreliable though
that
> may be) tells me it is likely to be greater than 2^127. Thus, I am
convinced
> that IDEA is indeed strong, despite a small amount of redundancy, and
that it
> is safe for me to continue to use it.
If one looks at it as an algebra wiht 52 unknows. then maybe a short piece
of
known text with the output is enough to solve this mess.
>
> Dave, please feel free to jump in if I have misrepresented you.
>
>
Jill I was wondering is there a Jack in your life.:)
David Scott
>
> They aren't talking about security that is "close" to breakable. Dave
> Scott erroneously believes that IDEA is "breakable" because the number
> of possible keys (2^128) is considerably smaller than the number of
> possible keys of known-breakable 6-bit simple substitution ciphers
> (which have 64! or about 2^296 "keys").
>
No I gave an example of a simpler method that is easier to break than
IDEA. An example of something trivial to break and stated IDEA is not
safe just because someone says hay it has a key lenghth of 128 bits.
I stated others with true key lengths much longer are considered weak.
So one should not go around saying it is safe just because it appears
to be 128 bits in length. I farther stated that I was not sure it has a
real
key length of 128 bits but will admit that it is at least 64 bits.
> John Savard is trying to point out that while IDEA might be made
stronger,
> there is no reason to believe it is in any way necessary (because IDEA is
> apparently plenty strong enough to resist any practical attack), and it
> is not clear that independent subkeys would vastly increase the security.
> You have to also consider that a 104-byte key is more awkward to handle
> than a 16-byte key.
In a computer where a pass phrase hids true key. a 16 byte key is really
no different than a 16000 byte key. Since the user never really needs to
know what they are. In other words we can use long strong keys because
computers do the work. Short keys might be nice if one really needs to
know them but they are not as good as a long key if used correctly.
And true a long key does not necessary mean method is strong. But if you
make a key short enough it is guaranteed to be weak.
>
As i also pointed out IDEA is nothing but an algebra. Granted it is a
mixture of 3. but every where a sub key is used it of form:
a op subkey = b where op could be addtion or multiply or whatever
then
knowing just one a,b pair along with the op
directly yelids the subkey.
example :
10101010 + subkey = 1111111
this implies subkey is 01010101
now given ANY "a" since one has subkey you get the "b"
portion
if a table look up used this is not possible since only one entry to
table is known
David Scott
this is test of my new newsreader
John R MacMillan
| In a computer where a pass phrase hids true key. a 16 byte key is really
|no different than a 16000 byte key
I would tend to agree, but probably not for the reason you meant: I
think the passphrase is likely to be the weak point in either case, so a
16000 byte key is not much better than a 16 byte one.
David Scott
> It is probably not "avoided because it is more secure". While there may
> be individuals and organizations who would like us to use weaker security
> (so that they can break it, presumably), there are also competent people
> who can analyze the security of various algorithms and protocols and who
> make publish their findings. If it were significantly more secure than
> the other chaining methods, you would be likely to see credible sources
> recommending it for applications in which error-propagation is not a
> problem.
>
Actually if one has taken the the time to look it is considered more
secure
by the experts. But then one would have to read. It comes with a price
you lose everything beyond the error. What I am saying is most people
need ERROR FREE files. Little errors in an executeably can crash your
computer. If you don't get the file error free then send it again. You pick
either security or not.
David Scott
Well I think you missed the point by jumping on this late. IDEA use
16 bit blocks that are chained in a interesting way to make it appear
as a 64 bit block. I am not saying to directly replace IDEA by a straight
16 bit block encryption. I stated several things.
One was a way to make IDEA stronger. And that was to replace the
first four 16 bit operations involving subkeys wiht 4 different table
lookups
each with a real key of over 900,000 bits. This would make it very much
stronger.
Second was a way to chain blocks together using 16 bit chunks to
chain whole file together to do to a whole file what IDEA tries to do
to the 4 16 bit blocks IDEA chains to 64 bits.
parker_rob
David Scott (dsc...@ridgecrest.ca.us) wrote:
I (Rob Parker) wrote this next section (Dave omited the attribution):
Where to begin... First, even *if* PCBC is "more secure" than CBC or
other modes that recover from errors, that is *not* the reason that
people *don't* use it and it is not the reason that "experts" push the
"weaker" modes on people instead. That is just unfounded paranoid crap,
and *that* is what I was responding to (though you cut out the context
I was replying to, which is poor net-ettiquite).
Second, your point about needing "error free files" is true, but limited.
It also applies directly to the ciphertext. If you need an absolutely
error-free copy of the file, but you want to encrypt it for security,
then you also need to keep an absolutely error-free copy of the ciphertext,
too (or use an elaborate method of error-correction & redundancy, which
might tend to weaken your security a bit). On the other hand, if you are
in an application where short errors are tolerable (and perhaps inevitable)
as long as it gets back to recovering the proper plaintext, such as real-
time communication, then an encryption algorithm that propagates errors
indefinitely could be totally unacceptable. Simply "send it again" does
not work for such real-time communication, because you already have more
data to send on a channel that's already sucking up bandwidth and repeating
old data is just not going to work. Recovery from a transmission error
on real-time communication when using PCBC is going to be a bit more awkward
than recovery when using a non-error-propagating method.
Third, there is a difference between "more secure" and "significantly
more secure". A change that makes an attack take an average of 2 minutes
longer is "more secure". A change that makes an attack take, on average,
twice as long is "more secure". A change that makes an attack that
couldn't be completed in the lifetime of our sun become impossible to
complete within the expected lifetime of the universe is "more secure".
None of these improvements is terribly significant (though the last one
comes close). A change that makes an attack that is easy become an
attack that requires vast resources that may not even be attainable,
is "significantly more secure". A change that makes an attack that
requires vast resources become an attack that would require more resources
than could possibly be obtained is "significantly more secure". A change
that makes an attack that requires more resources than could possibly
be obtained (but might be cracked on a lucky guess) into an attack that
is impossible no matter how lucky (such as due to information theory)
is "significantly more secure". You said it is considered "more secure"
by the experts. I had said if it is "significantly more secure"...
Note that your statement (if it is assumed to be accurate) does not
contradict my statement or disprove my point. If you can find "experts"
who argue that PCBC is *significantly* more secure than other chaining
methods, and can present their reasoning to us, then please do so.
Fourth, how is it more secure? You previously made some mention of an
attacker with the "middle" portion of the plaintext being able to attack
a file encrypted with the non-propagating chaining and feedback methods.
Perhaps you don't see how an attacker with the same info could attack it
even if PCBC is used. Normal CBC uses the previous ciphertext block to
affect the encryption of the next block. PCBC uses both the previous
ciphertext block and the previous plaintext block. But if the attacker
has more than one block of plaintext, if they have as little as two
sequential blocks of plaintext, they can attack PCBC even in the middle.
They simply use the first plaintext block they have, and the ciphertext
from that block (which they also have), and incorporate that into their
mechanism for testing keys out on the next ciphertext block. If they
find the right key, they will have a match for the second block of
plaintext. For ciphers where this is not sufficient to identify a single
key, they can continue with additional sequential blocks up to the number
required to identify the one true key, assuming they have enough known
plaintext. The only difference between CBC and PCBC in this attack is
that attacking PCBC requires one more block of known plaintext in each
group of sequential blocks. (If you only have a group of individual
blocks with none sequential, attacking PCBC becomes somewhat harder;
however, if you have enough such blocks (which isn't very many) you can
use the blocks you have to test decode the *unknown* blocks that follow
and just check them for sensibility--if it's a plaintext with a
recognizable sense, that is.) Usually, if you can get access to one
block of known plaintext, you can get two or more without much additional
trouble.
And even the slight improvement in security in this case (and the slightly
better improvement if the plaintext is automatically compressed before
encryption, so that it is harder to make "sense" of blocks in the middle)
does not translate to an improvement against other attacks. The above
attack still requires a brute-force keyspace search (or do you have some
idea on how to make that more efficient?). But a brute-force keyspace
search doesn't require known-plaintext. You can simply try decrypting
the entire file with each key guess (and then try decompressing, or
whatever other known & reversible technique is used). PCBC isn't likely
to have any positive effect on security against this attack.
There may be other attacks against DES or other block ciphers which
become a bit harder with PCBC than with CBC, CFB, or OFB (if you know
of any from your "reading", please tell us about the specific attacks).
These attacks only become interesting if they can be "faster" than some
other attack (such as brute-force keyspace search); better security
against an attack that is more difficult than an attack for which it
offers no better security, does not improve security. I don't know
of any attacks that don't laugh at the differences between the various
chaining & feedback modes (or lack thereof). Maybe you can enlighten
me for a change?
-Rob Parker
David Scott
Look guys I proposed a contest where data given in form as below
in hex
input output
0001 DEAD FACE 1000 ABCD EF01 2345 678
several such lines of input and output maybe 60 or so each based on
nonchained
data each made with the same IDEA 128 bit key.
then have a few lines like
xxxx xxxx xxxx xxxx 0345 6789 8734 ACE1
and solve for the misssing input. Why don't the IDEA people or some one
that people trust make such a contest. is this to much to ask or is it best
to pretend IDEA is secure.
DAVE SCOTT
P.S. No i have not broken it yet. But the job prospects are getting
thinner
so I may spend a month or two solving this on my own. To avoid the
posibility
that I am doing IDEA wrong It would be nice to see some sample blocks of
form
input output key
0001 0002 0003 0004 1234 5678 9ABC DEF0 0001 0002 0003 0004 0005
0006 0007 0008
note the above is an example I am sure it is not a valid one.
Paul L. Allen
In article <01bc0901$74619220$0d9678c7@dscott>
"David Scott" <dsc...@ridgecrest.ca.us> writes:
> > They aren't talking about security that is "close" to breakable. Dave
> > Scott erroneously believes that IDEA is "breakable" because the number
> > of possible keys (2^128) is considerably smaller than the number of
> > possible keys of known-breakable 6-bit simple substitution ciphers
> > (which have 64! or about 2^296 "keys").
>
> No I gave an example of a simpler method that is easier to break than
> IDEA.
Yes, you did. A trivial cipher of a totally different nature to IDEA.
Not so much comparing apples and oranges as elephants and bacteria. Look,
I can pick up millions of bacteria in one hand, so I must also be able to
pick up millions of elephants.
> An example of something trivial to break and stated IDEA is not
> safe just because someone says hay it has a key lenghth of 128 bits.
No, bit-length is not the only concern. It also matters what you do
with them. It matters very much what you do with them.
> I stated others with true key lengths much longer are considered weak.
Because they work differently. Is this *really* so hard for you to see?
IDEA has 128 bits because its nature means that it is considered vulnerable
only to brute-force attacks and those 128 bits are sufficient to protect it
from brute force attacks if you could turn the entire mass of the universe
into the latest model of Cray and had several thousand years to run them.
RSA is designed for a different purpose, public key rather than secret key
operation. Its nature means that it is vulnerable to factoring attacks
rather than brute-force attacks and therefore you need (IIRC) about 3,000
bits of RSA to be as strong as 128 bits of IDEA. That doesn't meant that
all other ciphers are weaker than RSA because they use fewer bits but that
the nature of RSA means that it is open to specific forms of attack that
the others are not.
> So one should not go around saying it is safe just because it appears
> to be 128 bits in length.
Indeed not. I can invent a cipher that takes a 128-bit key and ignores
it completely, XORing the plaintext with $00, $01, $02... in turn. This
squanders the bits totally. Other, trivial ciphers, such as a simple
substitution cipher are almost as wasteful in terms of how effectively the
key bits are used. That just means they aren't sufficiently complex
algorithms to use those bits *well*, not that you necessarily need more
bits.
> I farther stated that I was not sure it has a real key length of 128 bits
> but will admit that it is at least 64 bits.
That's big of you. But others (who know the difference between a
substitution cipher and a block cipher running in CFB mode) have examined
the source and description and are happy there is 128 bits. Maybe they're
lying, but I doubt it.
> > John Savard is trying to point out that while IDEA might be made
> > stronger, there is no reason to believe it is in any way necessary
> > (because IDEA is apparently plenty strong enough to resist any practical
> > attack), and it is not clear that independent subkeys would vastly
> > increase the security. You have to also consider that a 104-byte key
> > is more awkward to handle than a 16-byte key.
>
> In a computer where a pass phrase hids true key. a 16 byte key is really
> no different than a 16000 byte key.
You really are an idiot, aren't you? Shannon showed that English has an
entropy which approaches 1 bit per character. A truly random 16-character
pass phrase has 16 bytes of entropy, whereas a memorable 16-character pass
phrase may (if well-chosen) have 4 or 5 bytes of entropy (guesstimate) and a
badly-chosen memorably phrase will have around 2 bytes of entropy. There is
no point using a 16,000-byte encryption key with what equates to a 4-byte
pass phrase - the pass phrase is the weak link if your opponent has physical
access to your machine (and if you really *need* strong encryption then your
opponent will find this the easiest way to break your traffic).
> Since the user never really needs to know what they are. In other words
> we can use long strong keys because computers do the work.
We can. And once we have found a crypto algorithm and a key-length that
gives us all the security we could conceivably need even if the universe
were turned into Crays then we need go no further, particularly if longer
keys require disproportionately more computer power to use.
> As i also pointed out IDEA is nothing but an algebra.
And Cipher Feedback. Please come back to us after you've looked at a few
references which explain what this is and how it is very much superior to
ECB mode.
In fact, why don't you look at the PGP docs, the PGP source and the
sci.crypt FAQ then get back to us. But make sure you understand the
difference between a block cipher and a stream cipher first.
Oh, and it might help you to look for discussions of product ciphers too.
That will take you into the world of S-boxes and resistance to differential
cryptanalysis if you dig deep enough. Hell, you might even start to
understand how IDEA works if you get that far.
Alternatively, because all that is a lot of hard work and you're convinced
IDEA is weak, write us a program that cracks IDEA keys using your theories.
Take as much time as you need...
--Paul
David Scott
Paul L. Allen <p...@sktb.demon.co.uk> wrote in article
<cD-4w...@sktb.demon.co.uk>...
>
> RSA is designed for a different purpose, public key rather than secret
key
> operation. Its nature means that it is vulnerable to factoring attacks
> rather than brute-force attacks and therefore you need (IIRC) about 3,000
> bits of RSA to be as strong as 128 bits of IDEA. That doesn't meant that
> all other ciphers are weaker than RSA because they use fewer bits but
that
> the nature of RSA means that it is open to specific forms of attack that
> the others are not.
You are right. But I never attacked RSA. I was talking about IDEA.
I guess if I get enough of you idoits pissed off maybe some one will really
make a contest like I suggested. Unless there is a fear that it is to easy
to crack.
> That's big of you. But others (who know the difference between a
> substitution cipher and a block cipher running in CFB mode) have examined
> the source and description and are happy there is 128 bits. Maybe
they're
> lying, but I doubt it.
You remind me of the PhD idiots who said we never would get to the moon
or the ones who said noble gas componds are impossible. I use unrolled
IDEA in some of me own personnel encryption programs that I have written
but use far stronger chainning methods than CFB mode. But this thread was
not discussing chainning but IDEA as a block cipher method alone. Many
weak ciphers can be strenghtened by proper chainning. I am talking
only about IDEA itself.
>
> >
> > In a computer where a pass phrase hids true key. a 16 byte key is
really
> > no different than a 16000 byte key.
>
> You really are an idiot, aren't you? Shannon showed that English has an
> entropy which approaches 1 bit per character. A truly random
16-character
> pass phrase has 16 bytes of entropy, whereas a memorable 16-character
pass
> phrase may (if well-chosen) have 4 or 5 bytes of entropy (guesstimate)
and a
> badly-chosen memorably phrase will have around 2 bytes of entropy. There
is
> no point using a 16,000-byte encryption key with what equates to a 4-byte
> pass phrase - the pass phrase is the weak link if your opponent has
physical
> access to your machine (and if you really *need* strong encryption then
your
> opponent will find this the easiest way to break your traffic).
>
I agree the pass phrase is a very weak link in encryption. But what I was
addressing
is that hopefully for most uses. The main exposure of you encrpted stuff is
what flows
on the internet. And there is where the majority of interceptions and
attacks can occur.
So if the program does the encryption and not the usrer it should be a
secure as possible.
> > Since the user never really needs to know what they are. In other words
> > we can use long strong keys because computers do the work.
>
> We can. And once we have found a crypto algorithm and a key-length that
> gives us all the security we could conceivably need even if the universe
> were turned into Crays then we need go no further, particularly if longer
> keys require disproportionately more computer power to use.
>
Only a true idiot would belive that IDEA gives such a high degree of
security.
Granted if an idiot such as you randomly tried to guess it you would never
get it done. Why are people like you so narrow minded that you FASLELY
assume one has to randomly search by using guesses for keys. Yes I took
a simpler system that has a longer REAL KEY length and it is easy to break.
Yes IDEA with shorter key is at present public knowledge not that easy to
break
however due to the nature of algebra I feel it can be done. Or at least I
feel most
matematicians would honestly admit that it appears that it could be broken
even
if they don't sit down and try to break it.
You are right in that why use algorithims that take a long time to run.
After all
encryption should be for the ease of one using it. But it would take only a
small
amount of time to encrypt with much stronger methods that happen to use a
larger
key space. I also feel as computers get faster the need to make stronger
and stronger
methods with longer and longer keys will continue.
If RSA history is an example earlier works suggested very short key
lengths would
be safe for hundreds of years. But now it seems that longer and longer keys
are
falling. As computers get faster and the use of pipe line hardware and
techniques in
factering improve it may be a short time 10 years at most or so before 3000
bit keys
fall. I was wondering if anyone has been plotting just for fun to see how
fast improvements
have occurred in the public sector.
> > As i also pointed out IDEA is nothing but an algebra.
>
> And Cipher Feedback. Please come back to us after you've looked at a few
> references which explain what this is and how it is very much superior to
> ECB mode.
>
Obviously you have not read my other posts. I have even but out some old
stuff on various Chainning modes but that is another story
> Alternatively, because all that is a lot of hard work and you're
convinced
> IDEA is weak, write us a program that cracks IDEA keys using your
theories.
> Take as much time as you need...
Actually I might write a program this summer that breaks IDEA. If every
one else is to damn lazy. And by break I don't mean find a KEY since I
am not sure at this point there are 100% unique. You would have to read
other posts to see what I mean.
David Scott
parker_rob <rpa...@loc3.tandem.com> wrote in article
> Second, your point about needing "error free files" is true, but limited.
> It also applies directly to the ciphertext. If you need an absolutely
> error-free copy of the file, but you want to encrypt it for security,
> then you also need to keep an absolutely error-free copy of the
ciphertext,
> too (or use an elaborate method of error-correction & redundancy, which
> might tend to weaken your security a bit). On the other hand, if you are
> in an application where short errors are tolerable (and perhaps
inevitable)
> as long as it gets back to recovering the proper plaintext, such as real-
> time communication, then an encryption algorithm that propagates errors
Actuall there is error checking in several file transfer protocols on the
net and when it detects an error the errored packet is resent so one would
not need to send the whole file. The goal of modern digital communications
is to get entire message error free. Inside the system several packets
maybe
resent. But the goal still is error free message transfer and encryption
systems
should and can take advatage of this.
> indefinitely could be totally unacceptable. Simply "send it again" does
> not work for such real-time communication, because you already have more
> data to send on a channel that's already sucking up bandwidth and
repeating
>
Hell sound and video are the real things that are sucking up bandwidth on
the net. Not the sending of a few encrypted messages my friend.
Charles N. Johnson
David: I don't know if the following is what you are looking for as a test
of your challenge, but here is what you can work on. There are two sets
where the unencrypted text is the same, and the key is different, and
trivial. In the second set, the key remains unchanged and trivial, but the
unencrypted text is changed in a trivial manner.
Finally, I supply a single example of the unencrypted text, and the
encrypted text, and your challenge is to find the key.
(All values are in Hex)
Set #1---------------------
Unencrypted: 00 01 02 03 04 05 06 07
Encrypted: 59 4d bb a4 98 27 d4 78
Key: 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10
Unencrypted: 00 01 02 03 04 05 06 07
Encrypted: 6b 66 0a 06 cb 20 51 a9
Key: 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11
Unencrypted: 00 01 02 03 04 05 06 07
Encrypted: 3d e1 b0 df 6c 96 f2 d6
Key: 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12
Unencrypted: 00 01 02 03 04 05 06 07
Encrypted: de 1a 8f 2a c5 7d c1 aa
Key: 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
Unencrypted: 00 01 02 03 04 05 06 07
Encrypted: b9 13 c8 85 12 14 6b 19
Key: 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14
Unencrypted: 00 01 02 03 04 05 06 07
Encrypted: 32 ee fe 31 cd fb 8e 8c
Key: 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15
Set #2---------------------
Unencrypted: 01 02 03 04 05 06 07 08
Encrypted: bf 93 36 4d 3f 91 ac 41
Key: 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10
Unencrypted: 02 03 04 05 06 07 08 09
Encrypted: 64 c8 ca 1b d0 72 d5 33
Key: 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10
Unencrypted: 03 04 05 06 07 08 09 0a
Encrypted: d5 4e 1b f6 b3 cc 06 07
Key: 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10
Unencrypted: 04 05 06 07 08 09 0a 0b
Encrypted: e4 25 57 2e 20 23 8a 6e
Key: 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10
Unencrypted: 05 06 07 08 09 0a 0b 0c
Encrypted: 71 33 b1 99 5e 61 73 8c
Key: 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10
The Challenge-----------
Unencrypted: 00 01 02 03 04 05 06 07
Encrypted: cd b5 51 9f 18 b9 d1 f4
Key: ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
There you go, David. See what you can do.
Cheers--
Charles
David Scott <dsc...@ridgecrest.ca.us> wrote in article
<01bc0a3f$37263700$839678c7@dscott>...
Arnoud Galactus Engelfriet
-----BEGIN PGP SIGNED MESSAGE-----
In article <01bc0af4$c85f0660$889678c7@dscott>,
"David Scott" <dsc...@ridgecrest.ca.us> wrote:
> I guess if I get enough of you idoits pissed off maybe some one will really
If you keep responding like that, then I would be surprised if
anyone took you seriously.
> Only a true idiot would belive that IDEA gives such a high degree of
> security.
Well, if the experts say so.. I have no reason to distrust them.
> assume one has to randomly search by using guesses for keys. Yes I took
> a simpler system that has a longer REAL KEY length and it is easy to break.
But you still haven't explained how you can compute the "REAL KEY"
for IDEA, in such a way that its real key can be compared to
the real key of another cipher. Some fiddling with the algorithm
does not make it possible to compare IDEA keys with RSA keys or
substitution cipher keys.
> Actually I might write a program this summer that breaks IDEA. If every
I'm prepared to pay you US$100 if you manage to write a program that
can decrypt an IDEA-encrypted message without prior knowledge of
the IDEA key used to encrypt it.
Galactus
- --
To find out more about PGP, send mail with HELP PGP in the SUBJECT line to me.
NEW ADDRESS: --> gala...@stack.nl <-- Please PGP encrypt your mail.
Finger gala...@turtle.stack.nl for public key (key ID 0x416A1A35).
Anonymity and privacy site: http://www.stack.nl/~galactus/remailers/
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: cp850
iQCVAgUBMuu46DyeOyxBaho1AQF+bgQArRsfHoIjOstCEUP85vnWjIuwhY5kbRjn
8dhokQr5ZWCCMT2X6sDW5mYA/yyrNscGWzwLmPOGCG7NqdXHPNYdKQeR7ENrFB0u
KvipRBDV+QHJuTuVAPEE/RjWUbk253k29BJWVqOtfEOtGhwqHrmOClIYc6Q1XdTU
BjUkbtlKFw4=
=J0KJ
-----END PGP SIGNATURE-----
David Scott
Charles N. Johnson <char...@mail.idt.net> wrote in article
<01bc0b41$758d3720$acc0...@i-charlej9.interramp.com>...
> David: I don't know if the following is what you are looking for as a
test
> of your challenge, but here is what you can work on. There are two sets
> where the unencrypted text is the same, and the key is different, and
> trivial. In the second set, the key remains unchanged and trivial, but
the
> unencrypted text is changed in a trivial manner.
>
This is not what I had in mind but it has some features I like. Your
first set would allow one to check the implimention of idea because
my first two attempts of using idea worked different on a SUN versus
a PC. The so called big indian little indian problem.
> Finally, I supply a single example of the unencrypted text, and the
> encrypted text, and your challenge is to find the key.
I do not like this because I am not sure key is unique. Even thought it
maybe.
What I would like to see in your second set is the raw data in and
encrypted
data out for several blocks like you have but do not show key. Then
for last few blocks show only the encrytped out with problem being to
solve
for the input data. This is not really the same as soving for the key but
reather
solving for the relationship used between the plain data in versus the
encrypted
data out. Granted if one solves for key that would break code. However any
one
who actually spends hobby time breaking codes knows that since a lot of
encryption
schemes actually use a false real key length the "true meaning of breaking"
is to
solve for the plain text from encrypted data using the "KEY" of method used
to
generate the code is not always needed to break the method. I hope my sucky
written English can make that clear. I am sure Parker who knows how to
regurate
what he has read so that people can understand could right this point
better if
he wanted too. Engish is my worst subject. I got 99% in math and science to
get into college but only 17% in english so am very handy capped in that
area.
So have trouble typing but no touble teaching my kids how to score high on
Calculus AP tests to get into college. Hell I would make a great math
teacher
now that I am retired if anyone knows a good job. But I doublt if English
good
enough to get a teaching certifacte in CA.
I will code up a version of IDEA to match your first set. That way we will
have
some common ground. I have to reabuild my tools as I had a hard disk crash
and lost everything. So I have to rebuild my tools again. But I usually do
a better
job second or third time around. Will save tools on floppys next time. I
already
down loaded lastest version of DJGPP GNU and got that up so am on my way.
I failed at getteing a job at EGG in Nevada so I guess at this point I
will never
need a government clearance again so I think I can spend some time braeking
this for people. Yes I would take a job at NSA if I could get on as a
Contractor
since I can not work for the Feds again for 5 years with out a penality
would
not directly works as a government employee.
One last point not sure(but it may be)if enough of the right combinations
used
as input for encryption. One nice thing about channing that may actually
help
in breaking code is that it mixes up input bits so that given a strech of
unencrytped
text whit output one can unchain the code to get what acatually went into
the
cipher block. You could taken some real written text use a key and use
your
common believed chainning method but print out input in hex , output in
hex,
and key in hex. then print sevral of the input and out puts to the cipher
block.
this may span the input space better. then take a new text file or whatever
do same thing again only print out input and out put to cipher block for
several
blocks. then for last few blocks only print out last few outputs and have
others
guess what the inputs are.
parker_rob
David Scott (dsc...@ridgecrest.ca.us) wrote:
I (Rob Parker) wrote this next secion, and Dave again deleted the attribution:
>> They aren't talking about security that is "close" to breakable. Dave
>> Scott erroneously believes that IDEA is "breakable" because the number
>> of possible keys (2^128) is considerably smaller than the number of
>> possible keys of known-breakable 6-bit simple substitution ciphers
>> (which have 64! or about 2^296 "keys").
>>
> No I gave an example of a simpler method that is easier to break than
>IDEA. An example of something trivial to break and stated IDEA is not
>safe just because someone says hay it has a key lenghth of 128 bits.
>I stated others with true key lengths much longer are considered weak.
>So one should not go around saying it is safe just because it appears
>to be 128 bits in length. I farther stated that I was not sure it has a
>real
>key length of 128 bits but will admit that it is at least 64 bits.
Isn't that very similar to what I said you were claiming? The simple
fact is you are wrong about several things. The weakness of a 6-bit
simple substitution cipher has NOTHING to do with the size of the key;
it comes from the pitifully small *block size* of 6 bits (one character).
I already pointed this out, but you apparently didn't pay enough
attention.
Second, the belief in the strength of IDEA is not based only on the
size of the key. The fact that the keyspace of IDEA is so large (2^128)
that a brute-force keyspace search is impossible is only one part.
Unfortunately, the rest of it is far to complex to cover here. IDEA
is fairly new, but there has been some research looking at it which
has so far found it to be entirely secure (except for a small set of
"weak" keys). I suggest you look up the research into IDEA's strength
(or lack thereof) and try reading it before you suggest that all those
experienced experts know less about it than you.
> As i also pointed out IDEA is nothing but an algebra. Granted it is a
>mixture of 3. but every where a sub key is used it of form:
>a op subkey = b where op could be addtion or multiply or whatever
>then
>knowing just one a,b pair along with the op
>directly yelids the subkey.
>example :
>10101010 + subkey = 1111111
>this implies subkey is 01010101
>now given ANY "a" since one has subkey you get the "b"
>portion
Unfortunately for you, you don't have access to any such pairs, even
in a known-plaintext attack. The values you would need are all temporary
values inside the 8-round IDEA algorithm.
Also, the combination of addition mod 2^16 and multiplication mod 2^16+1
does not allow analysis through linear methods. If the multiplication
used the same modulus (2^16) it would be linear. It would also not work
properly because 2^16 is not prime; not all values would have inverses.
>if a table look up used this is not possible since only one entry to
>table is known
When you include quoted text in a followup you need to include the
attribution line (who wrote it). You also need to work on keeping
your lines shorter. This post wasn't too bad, but you can see where
your software (I assume) has automatically wrapped "real" to a line
by itself because it extended too far to the right (this is in your
first paragraph included above). Some of your other posts look
downright crappy because nearly every line has one or two words that
have wrapped to the next line. Things like this further detract from
your posts, and make it hard to take you seriously.
-Rob Parker
Ron Heiby
dsc...@ridgecrest.ca.us (dave scott) wrote:
>Hay at work
>I did not have to impress anyone how i spoke or what I wore. But may be
>impressions and bull shit more important than reality.
>>you are trying to say.
Well, maybe on the farm where you work ("Hay at work"?) you don't need
to impress anyone. Good for you. Anyone who wants to get a good
recommendation as a result of interviewing with me for a job who is
rude, obnoxious, crude, does not care about spelling or grammer, and
cannot get his/her ideas across to other people, is just wasting
his/her time. You may think that this is "bull shit". However, your
belief does not make it any less true. If, in order to communicate
"reality" to others, you find it necessary to offend them, then I can
do without your reality. Good luck when you decide you have to enter
what most people think of as the "real world".
Ron.
Jill Baker
"David Scott" <dsc...@ridgecrest.ca.us> wrote:
> Look guys I proposed a contest where data given in form as below
>in hex
> input output
>0001 DEAD FACE 1000 ABCD EF01 2345 678
>several such lines of input and output maybe 60 or so each based on
>nonchained
>data each made with the same IDEA 128 bit key.
>then have a few lines like
>xxxx xxxx xxxx xxxx 0345 6789 8734 ACE1
>and solve for the misssing input. Why don't the IDEA people or some one
>that people trust make such a contest. is this to much to ask or is it best
>to pretend IDEA is secure.
Of what relevence is the above question - even if it were solvable - to PGP?
PGP uses a *different* IDEA key for each message, and so *even if* you had
both the cyphertext and the plaintext of (say) yesterday's PGP-encrypted
message, and *even if* you could break IDEA in the sense defined above, you
*still* would not be able to translate the cyphertext of _today's_
PGP-encrypted message into plaintext.
Paul L. Allen
In article <01bc0af4$c85f0660$889678c7@dscott>
"David Scott" <dsc...@ridgecrest.ca.us> writes:
> Paul L. Allen <p...@sktb.demon.co.uk> wrote in article
> <cD-4w...@sktb.demon.co.uk>...
> >
> > RSA is designed for a different purpose, public key rather than secret
> > key operation. Its nature means that it is vulnerable to factoring
> > attacks rather than brute-force attacks and therefore you need (IIRC)
> > about 3,000 bits of RSA to be as strong as 128 bits of IDEA. That
> > doesn't meant that all other ciphers are weaker than RSA because they
> > use fewer bits but that the nature of RSA means that it is open to
> > specific forms of attack that the others are not.
>
> You are right. But I never attacked RSA. I was talking about IDEA.
I know, and you said it had too few bits because you could crack a
substitution cipher easily. IDEA is no more similar to a substitution
cipher than it is to RSA. IDEA may have what is effectively a substitution
cipher as one subcomponent, and you might *just* have found some attack
that gives you a few bits advantage in cracking that subcomponent. But
IDEA doesn't have the non-chaining mode that you propose to attack because
that would be too weak. CFB turns IDEA into an entirely different class
of problem than a substitution cipher.
> I guess if I get enough of you idoits pissed off maybe some one will really
> make a contest like I suggested.
Why should I go to that trouble? You're the one that says it's easy to
crack, so prove it. You don't need a contest. Modify the IDEA code to
drop the CFB. You can then generate all the plain and cyphertext pairs
yourself just by using PGP - it will pick a random key that you won't be
able to see (unless you do some extra messing). Then see if you can solve
it.
You don't need us to do all that for you.
> Unless there is a fear that it is to easy to crack.
In an ECB mode that it doesn't have, it will be easy to crack because in ECB
mode you have effectively two 64-bit keys that are used alternately and
repeatedly. If I understand correctly, in effect you have a 128-bit
one-time pad used repeatedly, which is fairly trivial to deal with. Which
is why IDEA doesn't have an ECB mode and you're going to have to play with
the sources to get one. DES has an ECB mode so that people who don't
know better can make life much easier for the NSA.
> > That's big of you. But others (who know the difference between a
> > substitution cipher and a block cipher running in CFB mode) have examined
> > the source and description and are happy there is 128 bits. Maybe
> > they're lying, but I doubt it.
>
> I use unrolled IDEA in some of me own personnel encryption programs that
> I have written but use far stronger chainning methods than CFB mode.
So it's no problem for you to play with the sources to get an ECB mode.
You don't need us to set up your competition for you then. You can do it
all by yourself. And once you've got it all working I'll send you some
data that will convince me whether or not it works.
BTW, the only chaining method I know that is *far* stronger than CFB is
PCBC. But that has problems if you're transmitting over a channel where
comms errors are possible.
> But this thread was not discussing chainning but IDEA as a block cipher
> method alone. Many weak ciphers can be strenghtened by proper chainning.
> I am talking only about IDEA itself.
IDEA *includes* the chaining method. There's no ECB mode. If you find
a slight weakness in the block encryption that doesn't mean you can use
the same attack when IDEA uses chaining.
[cut because I can't be bothered to reformat his badly-formatted lines]
> I agree the pass phrase is a very weak link in encryption. But what I was
> addressing is that hopefully for most uses. The main exposure of you
> encrpted stuff is what flows on the internet. And there is where the
> majority of interceptions and attacks can occur.
The only people with the money and power to attack something as strong
as IDEA find it much cheaper and easier to mount a TEMPEST attack on your
machine
> So if the program does the encryption and not the usrer it should be a
> secure as possible.
As secure as possible? No way. As secure as *necessary*. If IDEA can't be
cracked before the Sun burns out there's no point going for something that
can't be cracked until the Universe dies. Unless IDEA has a *major* unknown
weakness nobody will be able to brute-force it in any sensible time-scale.
And the thing about unknown weaknesses is they're unknown - a breakthrough
attack on IDEA might well still be workable even with a 128-million digit
key.
> > > Since the user never really needs to know what they are. In other words
> > > we can use long strong keys because computers do the work.
> >
> > We can. And once we have found a crypto algorithm and a key-length that
> > gives us all the security we could conceivably need even if the universe
> > were turned into Crays then we need go no further, particularly if longer
> > keys require disproportionately more computer power to use.
> >
> Only a true idiot would belive that IDEA gives such a high degree of
> security.
Uh-huh. Nobody has yet come up with a better attack than brute force.
You claim to have found one, but only if you're allowed to turn off CFB.
> Granted if an idiot such as you randomly tried to guess it you would never
> get it done. Why are people like you so narrow minded that you FASLELY
> assume one has to randomly search by using guesses for keys.
Because that's the only publicly-known approach. The NSA might know better,
but I don't think you do.
> Yes I took a simpler system that has a longer REAL KEY length and it is
> easy to break.
Oh dear, you took a *simpler* system with a longer key length and it's
easy to break. Anybody else would come to the conclusion that it's not
just the key length that contributes to the strength but also the overall
design of the cipher. They might even conclude that good cipher design
is better than simply using the longest key possible with a bad cipher.
> Yes IDEA with shorter key is at present public knowledge not that easy to
> break
Not that easy? Present public knowledge is that it's not possible at all.
> however due to the nature of algebra I feel it can be done.
Only if you deliberately weaken it by turning off CFB.
> Or at least I feel most matematicians would honestly admit that it appears
> that it could be broken even if they don't sit down and try to break it.
Do you have any idea how many mathematicians have analysed it and concluded
that they cannot think of any possible attack other than brute force? But
if you find a *competent* mathematician who agrees with you let us know.
> You are right in that why use algorithims that take a long time to run.
> After all encryption should be for the ease of one using it. But it would
> take only a small amount of time to encrypt with much stronger methods that
> happen to use a larger key space.
Methods that *you* think are stronger. Trouble is, I don't really trust
your opinion on that.
> I also feel as computers get faster the need to make stronger and stronger
> methods with longer and longer keys will continue.
Unless you already have something that cannot be brute-forced if you could
turn every grain of sand on the planet into a Cray, in which case it is
already strong *enough*.
> If RSA history is an example earlier works suggested very short key
> lengths would be safe for hundreds of years. But now it seems that longer
> and longer keys are falling.
RSA is a completely different matter since there are better attacks than
brute-force. Improvements in factoring algorithms were the main
contribution to this. The nature of RSA has *always* made a novel
breakthrough a possibility. But unless you can find an attack on IDEA that
gives the same sort of improvement you can forget about it.
> As computers get faster and the use of pipe line hardware and
> techniques in factering improve it may be a short time 10 years at most
> or so before 3000 bit keys fall.
But RSA is susceptible to factoring attacks. IDEA isn't. You claim to
have an attack that may speed up an attack on a subcomponent of IDEA but
with CFB that method of attack is not open to you.
> > Alternatively, because all that is a lot of hard work and you're
> > convinced IDEA is weak, write us a program that cracks IDEA keys using
> > your theories. Take as much time as you need...
>
> Actually I might write a program this summer that breaks IDEA. If every
> one else is to damn lazy.
Go for it. But make sure you do it on real IDEA and not that cut-down,
castrated version you want to use it on.
> And by break I don't mean find a KEY since I am not sure at this point
> there are 100% unique. You would have to read other posts to see what
> I mean.
Whatever. You take plaintext and ciphertext and give us the key and we'll
be impressed. Or take just ciphertext and give us plaintext and we'll be
even more impressed. Less difficult is if you have several (thousand, if
need be) plaintext files and corresponding IDEA-encrypted files using the
same key and can use those to manage to decrypt another file encrypted with
the same key. But just make sure it's real IDEA and not your watered-down
version.
--Paul
parker_rob
David Scott (dsc...@ridgecrest.ca.us) wrote:
> Look guys I proposed a contest where data given in form as below
>in hex
You want to try to crack a random IDEA key from a known-plaintext attack?
Sounds good, let's try it. I just got an implementation of IDEA working,
though I'm not positive it exactly follows the standard; something in
the description I'm working from seems fishy with respect to swapping
after the last round(s), and I made a slight alteration that seems to
make more sense in the resulting decryption key schedule. I'm pretty
sure the difference won't significantly affect the security, though
of course interoperability would be shot if it's not correct. I need
to check some other descriptions of IDEA and see if I can find some
test vectors for the standard algorithm. In any case, I'll be sure to
provide the exact algorithm used to construct the challenge.
> input output
>0001 DEAD FACE 1000 ABCD EF01 2345 678
>several such lines of input and output maybe 60 or so each based on
>nonchained
>data each made with the same IDEA 128 bit key.
Ok. Why don't we make it easier for you. Why don't you (David) send
me a list of plaintext blocks (in email), formatted as above, and I'll
chose a secret key and encrypt each of the blocks with that key, and
post the challenge here. That gives you essentially a chosen-plaintext
attack (though a chosen-plaintext attack might typically give you examples
of ciphertext--for which the plaintext is unknown--before you chose the
plaintext). Pick as many as you like, within reason.
The challenge will be to either identify the key or to determine some
other algorithm for decrypting provided ciphertext blocks for which
you do not know the plaintext (which is also the check for the correct
key).
If you like, you can even send me a list of your choice of ciphertext
blocks, and we'll use them in the challenge (I'll decrypt them and keep
the plaintext secret, then we can check your results against what the
plaintext would actually have been.) Or you can chose some ciphertext
blocks that you want the plaintext given for as part of the challenge
(which become part of the list of pairs as with the chosen-plaintext).
Or, care to try a related-key attack? You specify a set of separate
changes to make to the key (you don't know the key, but you can alter
the key that is used and see the effects), and I'll reencrypt a given
plaintext block (or a different one, if you want) and give you the
resulting ciphertext. We can work it pretty much any way you like,
as long as it's a legitimate challenge and as long as the amount of
"free" info provided in the challenge is reasonably bounded (I can't
spend the time to encrypt a million of them, obviously, nor could I
post that much data).
I am confident you won't be able to "crack" it no matter what form of
attack we agree to allow (known-plaintext, chosen-plaintext, related-key,
or whatever), so take your pick. (Note, differential fault analysis is
excluded, because it is an attack on a device/implementation, not on
the algorithm itself. It is known that DFA can be reasonably applied
to any of the common modern block algorithms--it was shown for DES, and
argued that a similar attack algorithm could be devised for triple-DES
and IDEA, though the exact numbers involved would change. Also, I
wouldn't be able to provide a proper challenge for DFA, since the faults
must be introduced completely at random, not chosen by either one of us.
If you'd like to work out the method for attacking IDEA using DFA, you
can set that up on your own.)
>then have a few lines like
>
>xxxx xxxx xxxx xxxx 0345 6789 8734 ACE1
>
>and solve for the misssing input. Why don't the IDEA people or some one
>that people trust make such a contest. is this to much to ask or is it best
>to pretend IDEA is secure.
They have probably already done so. There may even be outstanding
challenges with monetary reward (though I haven't heard of any for
IDEA specifically).
Someone else was offering you $100 if you came up with a program to
crack IDEA. I won't offer any money; I figure proving your point should
be worth it to you without any token reward, especially since you get
to pick most of the challenge. And I'm not asking for a general-purpose
IDEA-cracking program (though that would certainly suffice), just that
you demonstrate how "weak" IDEA by cracking a reasonable challenge.
-Rob Parker
I'll be waiting to hear from you, Dave (for the chosen plaintext).
William Unruh
In <01bc0af4$c85f0660$889678c7@dscott> "David Scott" <dsc...@ridgecrest.ca.us> writes:
*> Only a true idiot would belive that IDEA gives such a high degree of
*>security.
*>Granted if an idiot such as you randomly tried to guess it you would never
*>get it done. Why are people like you so narrow minded that you FASLELY
*>assume one has to randomly search by using guesses for keys. Yes I took
*>a simpler system that has a longer REAL KEY length and it is easy to break.
*>Yes IDEA with shorter key is at present public knowledge not that easy to
*>break
*>however due to the nature of algebra I feel it can be done. Or at least I
*>feel most
*>matematicians would honestly admit that it appears that it could be broken
*>even
*>if they don't sit down and try to break it.
This discussionis getting pointless. We all know what you mean by
breaking IDEA. HOwever noone has ever published an attack on IDEA which
is not an "exhaustive serach" attack. If you have an attack, please
publish it. If not your posts simply amount to unsubstantiated
speculation. You need to do more than say "there may be an attack" to
saying" here is an attack which is much more efficient than exhaustive
search. Please do so.
*> Actually I might write a program this summer that breaks IDEA. If every
*>one else is to damn lazy. And by break I don't mean find a KEY since I
*>am not sure at this point there are 100% unique. You would have to read
*>other posts to see what I mean.
Please do so. Before you do so, your speculations are not worth
anything. Since noone else has any ideas of how to do it, it is hardly
laziness. Breaking publiclly accepted cyphers is one way people make
reputations for themselves and they would be only too glad to do so if
they could.
--
Bill Unruh
un...@physics.ubc.ca
David Scott
Jill Baker <jba...@pobox.com> wrote in article
<5cien0$4...@madge2.dev.madge.com>...
> "David Scott" <dsc...@ridgecrest.ca.us> wrote:
>
>
> > Look guys I proposed a contest where data given in form as below
> >in hex
>
> > input output
> >0001 DEAD FACE 1000 ABCD EF01 2345 678
> >several such lines of input and output maybe 60 or so each based on
> >nonchained
> >data each made with the same IDEA 128 bit key.
>
> >then have a few lines like
>
> >xxxx xxxx xxxx xxxx 0345 6789 8734 ACE1
>
> >and solve for the misssing input. Why don't the IDEA people or some one
> >that people trust make such a contest. is this to much to ask or is it
best
> >to pretend IDEA is secure.
>
>
> Of what relevence is the above question - even if it were solvable - to
PGP?
I supose the relevence would be to show how it is possible to break on a
very
slow and weak machine like my 486. It opens a crack in the armor of IDEA if
a few ameturs can do this. Extrapalte to what real professionals could do.
I am
not sayiing 100% I can do it. But information theroy suggests that it can.
If I or
some other amatur can succeed then companies most likely can suceed on the
larger
level. One common example is that governments and such like the Japanse in
the last war that we kicked there ass in are so dam formal they tend to
repeat
identically the same crap in parts of a message. Getting a few of these the
person
trying to break a message may have a place where he can guess what the
plantext
of a portion of the unencrytped message is and this may lead to the
breaking of it.
Look I am not saying this is only way I just saying I feel there are cracks
that some
one wiht a cheap machine can break into.
>
> PGP uses a *different* IDEA key for each message, and so *even if* you
had
> both the cyphertext and the plaintext of (say) yesterday's PGP-encrypted
> message, and *even if* you could break IDEA in the sense defined above,
you
> *still* would not be able to translate the cyphertext of _today's_
> PGP-encrypted message into plaintext.
I might be able to if the message is very close to yesterday just ask the
Japanese
they were as aragant as you. I they lost the war. OH i asked before is
there a Jack.
David Scott
Arnoud "Galactus" Engelfriet <gala...@stack.nl> wrote in article
<0r66y4uY...@stack.nl>...
> -----BEGIN PGP SIGNED MESSAGE-----
>
> In article <01bc0af4$c85f0660$889678c7@dscott>,
> "David Scott" <dsc...@ridgecrest.ca.us> wrote:
> > I guess if I get enough of you idoits pissed off maybe some one will
really
>
> If you keep responding like that, then I would be surprised if
> anyone took you seriously.
>
> > Only a true idiot would belive that IDEA gives such a high degree of
> > security.
>
> Well, if the experts say so.. I have no reason to distrust them.
>
I guess of the many ways to attempt to classify people one is to
assign them to the leaders or sheep catagorey. You would make
a nice sheep. P. T. Barnom said guys like you are born every minute
I belive him.
Let me put it this way having worked for the U. S. Government for 25 years
an expert is a guy with a suit and tie and breif case and usually is full
of shit
but can talk well. They are experts becasue the managers know even less
than the guys in suits. We purposely hire mannagers that have no expertice
to run things. Why I don't know but I fear our country will pay a dear
price for
it in the long run. Another defintion of an expert is a has been drip.
> > assume one has to randomly search by using guesses for keys. Yes I took
> > a simpler system that has a longer REAL KEY length and it is easy to
break.
>
> But you still haven't explained how you can compute the "REAL KEY"
> for IDEA, in such a way that its real key can be compared to
> the real key of another cipher. Some fiddling with the algorithm
> does not make it possible to compare IDEA keys with RSA keys or
> substitution cipher keys.
>
> > Actually I might write a program this summer that breaks IDEA. If
every
>
> I'm prepared to pay you US$100 if you manage to write a program that
> can decrypt an IDEA-encrypted message without prior knowledge of
> the IDEA key used to encrypt it.
>
I gave you guys what I thought was a fair contest. I wish to try to do it
before
someone else does. And if you guys post a real challenge some one may beat
me to it. The 100 dollars is an insult. If I write such a program I would
give it
a way free. Unless I am working for a company at the time and am doing it
for them, But there is little chance of that since I am over 40 and
umemployed.
I am not going back to college I already have a masters degree in
electornic
engineering contorl theory. I would of had my degreee in mathematics but
then
I would have had fewer math classes and more english crap at which I suck.
David Scott
parker_rob <rpa...@loc3.tandem.com> wrote in article
>
> Sounds good, let's try it. I just got an implementation of IDEA working,
> though I'm not positive it exactly follows the standard; something in
> the description I'm working from seems fishy with respect to swapping
> after the last round(s), and I made a slight alteration that seems to
> make more sense in the resulting decryption key schedule. I'm pretty
> sure the difference won't significantly affect the security, though
> of course interoperability would be shot if it's not correct. I need
> to check some other descriptions of IDEA and see if I can find some
> test vectors for the standard algorithm. In any case, I'll be sure to
> provide the exact algorithm used to construct the challenge.
>
> > input output
> >0001 DEAD FACE 1000 ABCD EF01 2345 678
> >several such lines of input and output maybe 60 or so each based on
> >nonchained
> >data each made with the same IDEA 128 bit key.
>
> Ok. Why don't we make it easier for you. Why don't you (David) send
> me a list of plaintext blocks (in email), formatted as above, and I'll
> chose a secret key and encrypt each of the blocks with that key, and
> post the challenge here. That gives you essentially a chosen-plaintext
> attack (though a chosen-plaintext attack might typically give you
examples
> of ciphertext--for which the plaintext is unknown--before you chose the
> plaintext). Pick as many as you like, within reason.
>
I have to rebuild my set of tools to do that give me some time.
Also I like Charles idea of having a set of blocks in and out with
a key so that everyone can be sure of actually using the same IDEA
it would be nice to get that Candian guy (Unrush?) to check that we
match. Again I have to get my tools set up so it will take some time.
At this point I was not asking to use a chosen plaintext attack. I might
if I find a slick way of doing that is found but was hoping that not
necessary.
> The challenge will be to either identify the key or to determine some
> other algorithm for decrypting provided ciphertext blocks for which
> you do not know the plaintext (which is also the check for the correct
> key)
.
I still would rather not expose any devloped algorithm at this point but
in effect use it by decrypting more blocks of an encrypted message.
That was encrypted with same key. Is this not in the bounds of reason.
I know it is close to what your are asking but not exactly the same.
>
> If you like, you can even send me a list of your choice of ciphertext
> blocks, and we'll use them in the challenge (I'll decrypt them and keep
> the plaintext secret, then we can check your results against what the
> plaintext would actually have been.) Or you can chose some ciphertext
> blocks that you want the plaintext given for as part of the challenge
> (which become part of the list of pairs as with the chosen-plaintext).
>
>
Look I want to be involved in breaking it. But not directly involved
setting
up example to be used. I doubt any one would trust me at this point. They
would expect us to be in colusion of some kind.
> Someone else was offering you $100 if you came up with a program to
> crack IDEA. I won't offer any money; I figure proving your point should
2 things. I would not do this for 100 dollars, Maybe for free or 100,000
dollars
but not 100. Second I don't trust him to pay anyway. The only good it might
do is to stimulate some one else to do it. But I feel price is to low for
that.
> be worth it to you without any token reward, especially since you get
> to pick most of the challenge. And I'm not asking for a general-purpose
> IDEA-cracking program (though that would certainly suffice), just that
> you demonstrate how "weak" IDEA by cracking a reasonable challenge.
>
I understand. But I hope you realize it will take some time. I am
guessing
August. But then I have to anwser fewer messages so I can get this done.
I will even tell you my first approach. I might cahge mind tomorrow I never
know what I am going to do untill i do it. But I will look first at
attacking
an unrollled IDEA of form where the first 6 subblocks used. Since It is
obvious
that if one cut it off at first 4 subblocks only one block of data in and
out is needed
to solve for each subblock. I will let you know if I succeed. But it seems
the 6
subblocks would fall with only 2 blocks of input and output data. If this
is successful
I will go next level to 12 sublocks. Note this approach is based eventually
solving
all 832 bits in subblocks. I am note sure they are unique but if they are
then I will
have demonstrated IDEA fails since a subset of this. If I solve for the
first 6 subblocks
by this method I will let you know. If I fail at this then maybe IDEA
stronger than
I feel. But if I am successful on just this small portion. I will few
stronger than ever
it is just an algebra let can be reversered even if I fail to undo it at
next set of subblocks.
The first thing I will send is some hex words of encrytped data in and out
with key
so we can see if we all using same IDEA. I will see first if I can
reproduce set 1
of charles stuff.
later dave
David Scott
Ron Heiby <he...@falkor.chi.il.us> wrote in article
<32e4149c...@news.mcs.com>...
> Well, maybe on the farm where you work ("Hay at work"?) you don't need
> to impress anyone. Good for you. Anyone who wants to get a good
> recommendation as a result of interviewing with me for a job who is
> rude, obnoxious, crude, does not care about spelling or grammer, and
> cannot get his/her ideas across to other people, is just wasting
> his/her time. You may think that this is "bull shit". However, your
> belief does not make it any less true. If, in order to communicate
> "reality" to others, you find it necessary to offend them, then I can
> do without your reality. Good luck when you decide you have to enter
> what most people think of as the "real world".
Thank God I don't have to kiss your ass. You can have your real world with
suits and ties (clown costumes to me). I don't want to work for you any
way.
I have worked for some very good managers in the 70's because there main
concern was to make the dam airplane stay in the sky. They kept me in back
room where I liked it. But I didn't have to wear a tie or talk to his
customers.
But in those days a lot of mannagers were actually concerned about getting
the best product out and not petty office politics. I am retired and make
enough
to play on pc over the net. Program what I want in C. And still have enough
for
beer and chips with a trip to the local legeall cat house in Nevada know
and then.
What more could one want out of life. My main fear in life is that some day
well
meaning idiots may actually close the cat houses down. Then I will be stuck
looken for church ladies where the chance of catching aids goes up.
So far in life the most honest people I have meet are whores and farmers.
I come from farm stock and am proud of it. With out them you would be
dying of hunger.
William Unruh
In <854398...@mist.demon.co.uk> io...@mist.demon.co.uk (Iolo Davidson) writes:
*>In article <01bc0af4$c85f0660$889678c7@dscott>
*> dsc...@ridgecrest.ca.us "David Scott" writes:
*>> And by break I don't mean find a KEY since I
*>> am not sure at this point there are 100% unique. You would have to read
*>> other posts to see what I mean.
*>Can't be bothered. Just send me a program that can decypher a
*>PGP conventionally encrypted message without prior knowledge of
*>the key/passphrase and I will give you the hundred. I bet you
*>will be able to sell thousands more copies of it, too.
His definition of break is
Give him 100 plain text(8 bytes)/cyphertext pairs encrypted with the same key.
Give him another plain text. He will deliver the cyphertext encrypted
with that key to you. He will not tell you what the key is however.
In particular, since the inverse of IDEA is really just a slightly
different encryption, I would think that given a cypertext under the
above conditions, he could also deliver the plaintext, but he has never
said that he could.
While a slightly different definition of "break" than usual, it would
certainly be considered a form of breaking. (NOte that I am also very
skeptical that he can do what he claims>)
--
Bill Unruh
un...@physics.ubc.ca
David Scott
Paul L. Allen <p...@sktb.demon.co.uk> wrote in article
<cdbYd...@sktb.demon.co.uk>...
>
> Why should I go to that trouble? You're the one that says it's easy to
> crack, so prove it. You don't need a contest. Modify the IDEA code to
> drop the CFB. You can then generate all the plain and cyphertext pairs
> yourself just by using PGP - it will pick a random key that you won't be
> able to see (unless you do some extra messing). Then see if you can
solve
> it.
>
That is the approach I am taking give me time sir.
>
> In an ECB mode that it doesn't have, it will be easy to crack because in
ECB
> mode you have effectively two 64-bit keys that are used alternately and
> repeatedly. If I understand correctly, in effect you have a 128-bit
> one-time pad used repeatedly, which is fairly trivial to deal with.
Which
> is why IDEA doesn't have an ECB mode and you're going to have to play
with
> the sources to get one. DES has an ECB mode so that people who don't
> know better can make life much easier for the NSA.
>
I think you are a little confused. I never heard of 2 alternating 64 bit
keys.
What are you talking about. Also ECB mode is used for contest to just
look at IDEA block cipher. Sure PGP uses a forn of CFB but again
any block cipher could. And if you think it is weak in ECB mode then
fine. But it is not the chainning we are talking about. The chaining is not
IDEA it is an add on.
> So it's no problem for you to play with the sources to get an ECB mode.
> You don't need us to set up your competition for you then. You can do it
> all by yourself. And once you've got it all working I'll send you some
> data that will convince me whether or not it works.
>
Fine
> BTW, the only chaining method I know that is *far* stronger than CFB is
> PCBC. But that has problems if you're transmitting over a channel where
> comms errors are possible.
>
Sir i like to use Ziped files if there are any errors I like a fresh copy
but you
can file free to use corrupted files on your machine if you wish.
> IDEA *includes* the chaining method. There's no ECB mode. If you find
> a slight weakness in the block encryption that doesn't mean you can use
> the same attack when IDEA uses chaining.
>
I beg to differ with you it is a little more work but I am sure even
Parker
realizes that it is not to big of a step to undo the chaining. In the
contest
I suggest some one could use ascii text data to play the chainning games
then do the XORs to undue it and then give us the hex data in and out.
But maybe this concept it beyond your mental thinking range.
> The only people with the money and power to attack something as strong
> as IDEA find it much cheaper and easier to mount a TEMPEST attack on your
> machine.
Or they could just beat me sense less or fix me up with that Hawaiian
prostitute that works at Kitty's near Carson City.
> Because that's the only publicly-known approach. The NSA might know
better,
> but I don't think you do.
I am glad you share my leaning tords the possibility that the NSA may
already
know
>
> Oh dear, you took a *simpler* system with a longer key length and it's
> easy to break. Anybody else would come to the conclusion that it's not
> just the key length that contributes to the strength but also the overall
> design of the cipher. They might even conclude that good cipher design
> is better than simply using the longest key possible with a bad cipher.
>
That is so dam true it is not just the key length. That is my point
silly.
So stop with the fact it is 128 bits that is damn short in the computer
age.
> Do you have any idea how many mathematicians have analysed it and
concluded
> that they cannot think of any possible attack other than brute force?
But
> if you find a *competent* mathematician who agrees with you let us know.
>
Friend then let me analsye it. I will give you an example. When I was a
kid my
dad bought me a chess set. I learn to play by myself. The first man I
played I beat.
He told me dad I was good he thought I played for years which I had not.
Then
a year later the Colorada state champion came to Grand Lake Co. The owner
of the place where he was staying called my dad I went over I beat the shit
chess wise out of him he just took off shaking his head he could not
believe it.
I later in high school moved to Phoenix and went to watch An international
Grand Master play a bunch of people at same time. I got to paly him to I
was
the only one to beat him. He offered a draw and I told him to get fucked.
He said he would teach me a lession well he resigned one move from
being check mated. I like sucky openings. Hell at work I've worked on
projects peole say can not be done. Well I get them done so until I look
at it I don't give a rats ass what so called other Mathematicians say. Most
of them if they have PhD are full of shit anyway. And before you ask I lost
interest in chess. I much prefer poker. It is a far superior game.
> Whatever. You take plaintext and ciphertext and give us the key and
we'll
> be impressed. Or take just ciphertext and give us plaintext and we'll be
> even more impressed. Less difficult is if you have several (thousand, if
> need be) plaintext files and corresponding IDEA-encrypted files using the
> same key and can use those to manage to decrypt another file encrypted
with
> the same key. But just make sure it's real IDEA and not your
watered-down
> version.
>
Well Paul if i suceed will you become one of my 12? I like your 4 letter
name
you can't be all bad.
David Scott
William Unruh <un...@physics.ubc.ca> wrote in article
<5cj7d2$901$1...@nntp.ucs.ubc.ca>...
>
> This discussionis getting pointless. We all know what you mean by
> breaking IDEA. HOwever noone has ever published an attack on IDEA which
> is not an "exhaustive serach" attack. If you have an attack, please
> publish it. If not your posts simply amount to unsubstantiated
> speculation. You need to do more than say "there may be an attack" to
> saying" here is an attack which is much more efficient than exhaustive
> search. Please do so.
>
Fine then I will get with it and report back.
>
> Please do so. Before you do so, your speculations are not worth
> anything. Since noone else has any ideas of how to do it, it is hardly
> laziness. Breaking publiclly accepted cyphers is one way people make
> reputations for themselves and they would be only too glad to do so if
> they could.
>
I still think many people can break it. And I feel the NSA surely has
I will stop answering most people letters on this as it is cutting into
my time. I will try to work out a way so that you can be sure I am
actually using IDEA. I will strip out PGP version of IDEA and first check
if I can match input output hex blocks of code wiht the Hex key so that
I am using a blessed version of IDEA. I will let you know when that is
done, Hopefuly before the weekend. I have rebuilt most of my tools
since the hard drive crash and am checking them out. Any one notice
how bad the new dos in windows 95 is. Dos 6.2 and Dos 5 where better
How does one even get a list of the Dos commands in windows 95.
What is Bill trying to do to us.
Arnoud Galactus Engelfriet
-----BEGIN PGP SIGNED MESSAGE-----
In article <01bc0c8a$c1a57ec0$149678c7@dscott>,
"David Scott" <dsc...@ridgecrest.ca.us> wrote:
> I am
> not sayiing 100% I can do it. But information theroy suggests that it can.
Fine. I hereby increase my offer from $100 to $1000, and you can
also add Iolo's 100 UK pounds.
If you can refrain from making cheap jokes and insults to people
who respond to you, then I'll double it if you can do it.
Galactus
- --
To find out more about PGP, send mail with HELP PGP in the SUBJECT line to me.
NEW ADDRESS: --> gala...@stack.nl <-- Please PGP encrypt your mail.
Finger gala...@turtle.stack.nl for public key (key ID 0x416A1A35).
Anonymity and privacy site: http://www.stack.nl/~galactus/remailers/
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: cp850
iQCVAgUBMu+jlDyeOyxBaho1AQH1lQQAw/l5vZxglOTjRG9FyQ2EYCZFibR71M29
ZGidxUsMebM8GXoS0s66X5JSohk/PvlGfAHm64kObDZhcryYSGubP2z04yCz3CWD
Z8fxNLcHxLVapEBOsGozwMACd4sL1rnIjF8lHvCtwNNcbCM4NPFL8+DEQRlF/C82
r6aPOnwuwj4=
=YyXB
-----END PGP SIGNATURE-----
Arnoud Galactus Engelfriet
-----BEGIN PGP SIGNED MESSAGE-----
In article <01bc0c8d$99a54b00$149678c7@dscott>,
"David Scott" <dsc...@ridgecrest.ca.us> wrote:
> I guess of the many ways to attempt to classify people one is to
> assign them to the leaders or sheep catagorey. You would make
> a nice sheep. P. T. Barnom said guys like you are born every minute
And again, you feel it necessary to start with insulting someone
who criticizes you. If you know it can be done, then why don't
you do it? We have a few monetary offers, and a volunteer who is
willing to set up a contest.
Galactus
- --
To find out more about PGP, send mail with HELP PGP in the SUBJECT line to me.
NEW ADDRESS: --> gala...@stack.nl <-- Please PGP encrypt your mail.
Finger gala...@turtle.stack.nl for public key (key ID 0x416A1A35).
Anonymity and privacy site: http://www.stack.nl/~galactus/remailers/
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: cp850
iQCVAgUBMu+jmTyeOyxBaho1AQEQswP+IwNG4sdK7zdorRXB477zb/nuZqgH0QNR
HZgE1Z2pg0dY1tcmgxlJ/Pa68N73SCCQJE2i2zKEJruGoB+d7G7YTN2SekKvMg7u
jETuu2aTmW/CwpGHh4Rx/XO1DjHSiEzrSmUfW9YwsOMDEiynectC0zcWYPKQDQ8I
nVEMwrz7nUI=
=Eu51
-----END PGP SIGNATURE-----
Paul L. Allen
In article <01bc0cc9$52e17b80$e39678c7@dscott>
"David Scott" <dsc...@ridgecrest.ca.us> writes:
> Paul L. Allen <p...@sktb.demon.co.uk> wrote in article
> <cdbYd...@sktb.demon.co.uk>...
>
> >
> > Why should I go to that trouble? You're the one that says it's easy to
> > crack, so prove it. You don't need a contest. Modify the IDEA code to
> > drop the CFB. You can then generate all the plain and cyphertext pairs
> > yourself just by using PGP - it will pick a random key that you won't be
> > able to see (unless you do some extra messing). Then see if you can
> > solve it.
>
> That is the approach I am taking give me time sir.
That reply is not consistent with your other posts on the thread where you
ask for somebody else to generate test data because people wouldn't trust
you if you generated it yourself. This misses the point that at this stage
the only person you have to convince is yourself. Use your own data and
see if you get anywhere. Then, if you *do* get somewhere, you can tell
us and prove it by asking us to provide test data.
> > In an ECB mode that it doesn't have, it will be easy to crack because
> > in ECB mode you have effectively two 64-bit keys that are used
> > alternately and repeatedly. If I understand correctly, in effect you
> > have a 128-bit one-time pad used repeatedly, which is fairly trivial to
> > deal with. Which is why IDEA doesn't have an ECB mode and you're going
> > to have to play with the sources to get one. DES has an ECB mode so
> > that people who don't know better can make life much easier for the NSA.
>
> I think you are a little confused. I never heard of 2 alternating 64 bit
> keys. What are you talking about.
Since I couldn't find any nice description of what's going on inside IDEA
I assumed (from things *you* said earlier) that it's using half the key to
encrypt alternate blocks. Maybe it's using the whole key for each block,
which makes it all the harder for you.
> Also ECB mode is used for contest to just look at IDEA block cipher.
But CFB covers a hell of a lot of weaknesses. Saying that you can crack
ECB mode so IDEA is weak is like saying that you IDEA uses addition and
multiplication and you can do those in your head so IDEA is weak. The only
thing you can evaluate for weakness is the IDEA algorithm in its entirety.
> Sure PGP uses a forn of CFB but again any block cipher could.
All the strong ones do. Very few offer ECB mode. The only reason DES does
is that most people are stupid enough to use ECB mode and make the NSA's
life very easy.
> And if you think it is weak in ECB mode then fine.
I think it is a lot weakER in ECB mode.
> But it is not the chainning we are talking about. The chaining is not
> IDEA it is an add on.
Bollocks. The chaining is an *intrinsic* part of IDEA. From the way the
source is commented it's not clear if CFB was added when IPES mutated into
IDEA or whether it is exclusive to PGP. But IDEA (and IPES) always did
support CBC.
You cannot split the chaining off and say it's not a part of IDEA.
Otherwise you could split off other parts of the algorithm and say they're
not part of IDEA until you end up with some simple 64-bit operation that
anyone can break. IDEA is the whole thing, not just the part you claim.
> > BTW, the only chaining method I know that is *far* stronger than CFB is
> > PCBC. But that has problems if you're transmitting over a channel where
> > comms errors are possible.
>
> Sir i like to use Ziped files if there are any errors I like a fresh copy
> but you can file free to use corrupted files on your machine if you wish.
As has been repeatedly pointed out to you, PGP is used to transfer messages.
When timeliness is a problem then getting a textual message with the first
block corrupted but the other 2000 intact may well be preferable to getting
one with all 2000 blocks corrupted. Either way you need a resend to get the
first block, but one way you have 1999 blocks a little sooner and that *may*
be advantageous, particularly if the content of the first block can be
guessed or is trivial.
> > IDEA *includes* the chaining method. There's no ECB mode. If you find
> > a slight weakness in the block encryption that doesn't mean you can use
> > the same attack when IDEA uses chaining.
>
> I beg to differ with you it is a little more work but I am sure even
> Parker realizes that it is not to big of a step to undo the chaining.
I think undoing the chaining is rather hard. In fact, I think the chaining
is what gives IDEA its strength. It's easy to undo the chaining if you
already know the cyphertext that is chained. It's easy to get the cleartext
if you don't have any chaining to undo. A is weak if you know B. B is weak
if you know A. If you have neither A nor B then things get much harder.
> In the contest I suggest some one could use ascii text data to play the
> chainning games then do the XORs to undue it and then give us the hex data
> in and out. But maybe this concept it beyond your mental thinking range.
I know what you're saying. I just don't think it has any practical
application to breaking IDEA as it is implemented. It's easy to break
the subcomponents but not the whole.
> > Because that's the only publicly-known approach. The NSA might know
> > better, but I don't think you do.
>
> I am glad you share my leaning tords the possibility that the NSA may
> already know
They *may*. I tend to doubt it. They've put too much effort into pushing
Clipper, which they wouldn't need if they could crack PGP. It could be
double-bluff, but they really don't need to do that - people will use PGP
anyway.
> > Oh dear, you took a *simpler* system with a longer key length and it's
> > easy to break. Anybody else would come to the conclusion that it's not
> > just the key length that contributes to the strength but also the overall
> > design of the cipher. They might even conclude that good cipher design
> > is better than simply using the longest key possible with a bad cipher.
> >
>
> That is so dam true it is not just the key length. That is my point
> silly. So stop with the fact it is 128 bits that is damn short in the
> computer age.
Do you often manage to contradict yourself in the space of two sentences?
It is not *just* the key length. That means that 128 bits is damn short
if you have a ludicrously weak algorithm and plenty strong enough if you
have a strong one. A strong algorithm is one where brute-forcing the key is
the only known attack. Do you have any idea how long it would take to try
2^127 keys, even on a Cray?
I'm sure you can work it out if you try. Even if you make some ridiculously
high assumptions about how fast a Cray can try a key compared to your PC and
assume that the message-length is relatively short and ignore the time taken
to do even a rudimentary analysis about whether or not the decrypted
material might actually be text or not (oh yes, and assume that there is no
pre-compression because that's a PGP add-on).
128 bits is hard if the only attack is brute-forcing the key because 2^127
trials takes a hell of a long time to do. Age-of-universe types of time.
128 bits is weak if your algorithm is susceptible to other forms of attack.
Other than your unsubstantiated claims (which turn out merely to be a hunch)
there is no proof that IDEA has any significant weakness.
[Scott cuts, without any indication that he has done so, his original
material saying that mathematicians would agree with him that IDEA is weak
in order to make it look like I raised the point of what mathematicians
would make of IDEA.]
> > Do you have any idea how many mathematicians have analysed it and
> > concluded that they cannot think of any possible attack other than
> > brute force? But if you find a *competent* mathematician who agrees
> > with you let us know.
>
> Friend then let me analsye it.
I will let you analyse it with pleasure. Let us know the results. What I
won't do is let you make unsubstantiated claims to this group without
evidence.
> I will give you an example. When I was a kid my dad bought me a chess set.
> I learn to play by myself. The first man I played I beat. He told me dad
> I was good he thought I played for years which I had not.
[etc.]
Great, so you were a child genius and maybe still are. Or maybe you just
think you are.
> Well I get them done so until I look at it I don't give a rats ass what
> so called other Mathematicians say.
Is there no end to your deceitful ways? I have marked, 5 paragraphs above,
where YOU raised the point about what mathematicians would make of IDEA.
You were the one who claimed (but cut in this response) that they would
agree with you that IDEA is weak. Now you claim that you don't care what
they say and attempt, with your unmarked cut, to make it look like I raised
the point about mathematicians.
This appears to me to be an attempt to dismiss me for raising the point
about mathematicians when you in fact raised it yourself. You pull tricks
like that and expect us to believe your other claims?
--Paul
William Unruh
In <cEC6B...@sktb.demon.co.uk> "Paul L. Allen" <p...@sktb.demon.co.uk> writes:
*>> Also ECB mode is used for contest to just look at IDEA block cipher.
*>But CFB covers a hell of a lot of weaknesses. Saying that you can crack
*>ECB mode so IDEA is weak is like saying that you IDEA uses addition and
*>multiplication and you can do those in your head so IDEA is weak. The only
*>thing you can evaluate for weakness is the IDEA algorithm in its entirety.
IDEA is a block cypher, which can be chained or otherwise. Any block
cypher can be chained. You seem to claim that chaining can make a weak
block cypher inot a strong cypher. I have read the contrary. Could
someone more knowldgeable comment? Eg, can I use a simple alphabetic
substitution cypher (Rot 13?) and make it strong by chaining it? I doubt
it, but that is a feeling based on ignorace.
--
Bill Unruh
un...@physics.ubc.ca
David Scott
Below is out put of file compare of IDEA.C of PGP2.6.2 is ideaold.c
and my modifed to match Charales in idea1.c
This is so anyone with a GNU DJGPP C complier can
duplicate what is done. I hope the big indian little
indian problem is done right. Since it is opposit my old
Idea from DR. DOBBS. I hope Charles was right in his test
case post. I hope Bill and Parker and Jill double check
this so I or any one else on this thing can use it for
a bases of comparision. The only real Change is in
time of loop it will be longer cause to prints and
there was an error in original code that casues a divide
by zero if CLOCKS_PER_SEC is less than 1000 which it is
on my version of C. I think this may have been an error
on part of original code.
Comparing files ideaold.c and idea1.c
****** ideaold.c
*/
#include "idea.h"
****** idea1.c
*/
#include <stdio.h>
#include <stdlib.h>
#include "idea.h"
******
****** ideaold.c
#include "randpool.h"
#ifdef IDEA32 /* Use >16-bit temporaries */
****** idea1.c
#include "randpool.h"
struct l_h {
unsigned char l, h;
};
typedef union das {
short unsigned int i;
struct l_h c;
unsigned char si[2];
} das;
das dast, dask[8], dasi[4], daso[4];
int dasf = 1;
#ifdef IDEA32 /* Use >16-bit temporaries */
******
****** ideaold.c
MUL(x4, *key++);
s3 = x3;
****** idea1.c
MUL(x4, *key++);
if (dasf)
printf("ROUND %2d sub blocks %04x %04x %04x
%04x\n", 6 * dasf-2, x1, x2, x3, x4);
s3 = x3;
******
****** ideaold.c
x3 ^= s2;
} while (--r);
****** idea1.c
x3 ^= s2;
if (dasf) {
printf("ROUND %2d sub blocks %04x %04x %04x
%04x\n", 6 * dasf++, x1, x2, x3, x4);
if (r == 1)
dasf = 0;
}
} while (--r);
******
****** ideaold.c
/*-------------------------------------------------------------*/
#ifdef TEST
****** idea1.c
/*-------------------------------------------------------------*/
#define TEST
#ifdef TEST
******
****** ideaold.c
byte userkey[16];
word16 EK[IDEAKEYLEN], DK[IDEAKEYLEN];
byte XX[8], YY[8], ZZ[8];
****** idea1.c
byte userkey[16];
word16 EK[IDEAKEYLEN], DK[IDEAKEYLEN], das[IDEAKEYLEN];
byte XX[8], YY[8], ZZ[8];
******
****** ideaold.c
/* Make a sample user key for testing... */
for (i = 0; i < 16; i++)
****** idea1.c
/* Make a sample user key for testing... */
dast.si[0] = 1;
dast.si[1] = 5;
printf("\n **%4x** \n", dast.i);
dast.c.h = 2;
dast.c.l = 7;
printf("\n **%4x** \n", dast.i);
for (i = 0; i < 16; i++)
******
****** ideaold.c
userkey[i] = i + 1;
/* Compute encryption subkeys from user key... */
****** idea1.c
userkey[i] = i + 1;
/* my mod for hex key in */
printf("\n enter hex value of key in 8, 4 character hex words\n");
for (i = 0; i < 8; i++) {
scanf("%4x", &dask[i].i);
userkey[2 * i] = dask[i].c.h;
userkey[2 * i + 1] = dask[i].c.l;
/*
* printf("\n %04x %04x %04x
* \n",dask[i].i,userkey[2*i],userkey[2*i+1]);
*/
}
/* Compute encryption subkeys from user key... */
******
****** ideaold.c
ideaInvertKey(EK, DK);
printf("\nDecryption key subblocks: ");
for (j = 0; j < IDEAROUNDS + 1; j++) {
printf("\nround %d: ", j + 1);
if (j < IDEAROUNDS)
for (i = 0; i < 6; i++)
printf(" %6u", DK[j * 6 + i]);
else
****** idea1.c
ideaInvertKey(EK, DK);
/* temp to see if reverse reverse is corroct */
ideaInvertKey(DK, das);
for (j = 0; j < IDEAKEYLEN; j++)
if (EK[j] == das[j])
continue;
else
******
****** ideaold.c
else
for (i = 0; i < 4; i++)
printf(" %6u", DK[j * 6 + i]);
}
****** idea1.c
else
break;
if (IDEAKEYLEN != j) {
printf("\n**error** sub key %d before %d after %d \n", j,
EK[j], das[j]);
exit(1);
}
******
****** ideaold.c
}
/* Make a sample plaintext pattern for testing... */
****** idea1.c
}
printf("\nDecryption key subblocks: ");
for (j = 0; j < IDEAROUNDS + 1; j++) {
printf("\nround %d: ", j + 1);
if (j < IDEAROUNDS)
for (i = 0; i < 6; i++)
printf(" %6u", DK[j * 6 + i]);
else
for (i = 0; i < 4; i++)
printf(" %6u", DK[j * 6 + i]);
}
/* Make a sample plaintext pattern for testing... */
******
****** ideaold.c
XX[k] = k;
printf("\n Encrypting %d bytes (%ld blocks)...", BLOCKS * 16,
BLOCKS);
fflush(stdout);
****** idea1.c
XX[k] = k;
printf("\n inter hex values for input block\n");
printf("\n enter hex value of input in 4, 4 character hex
words\n");
for (k = 0; k < 4; k++) {
scanf("%4x", &dasi[k].i);
XX[2 * k] = dasi[k].c.h;
XX[2 * k + 1] = dasi[k].c.l;
}
printf("THE KEY USED IS ");
for (k = 0; k < 8; k++)
printf(" %04x", dask[k].i);
printf("\n");
printf("THE INPUT USED IS ");
for (k = 0; k < 4; k++)
printf(" %04x", dasi[k].i);
printf("\n");
printf("\n Encrypting %d bytes (%ld blocks)...\n", BLOCKS * 16,
BLOCKS);
fflush(stdout);
******
****** ideaold.c
memcpy(YY, XX, 8);
for (l = 0; l < BLOCKS; l++)
ideaCipher(YY, YY, EK); /* repeated encryption */
****** idea1.c
memcpy(YY, XX, 8);
ideaCipher(YY, YY, EK);
for (l = 9; l--;)
daso[l / 2].si[1 ^ (l % 2)] = YY[l];
for (l = 0; l < BLOCKS - 1; l++)
ideaCipher(YY, YY, EK); /* repeated encryption */
******
****** ideaold.c
end = clock() - start;
l = end / (CLOCKS_PER_SEC / 1000) + 1;
i = l / 1000;
j = l % 1000;
l = (16 * BLOCKS * (CLOCKS_PER_SEC / 1000)) / (end / 1000);
printf("%d.%03d seconds = %ld bytes per second\n", i, j, l);
printf("\nX %3u %3u %3u %3u %3u %3u %3u %3u\n",
XX[0], XX[1], XX[2], XX[3], XX[4], XX[5], XX[6], XX[7]);
****** idea1.c
end = clock() - start;
printf(" **made it here *** %d \n", CLOCKS_PER_SEC);
printf("THE OUTPUT USED IS");
for (k = 0; k < 4; k++)
printf(" %04x", daso[k].i);
printf("\n");
i = end / CLOCKS_PER_SEC;
j = ((end % CLOCKS_PER_SEC) * 1000) / CLOCKS_PER_SEC;
l = (16 * BLOCKS * CLOCKS_PER_SEC) / end;
printf("%d.%03d seconds = %d bytes per second\n", i, j, l);
printf("X %04x %04x %04x %04x %04x %04x %04x %04x\n",
XX[0], XX[1], XX[2], XX[3], XX[4], XX[5], XX[6], XX[7]);
******
****** ideaold.c
XX[0], XX[1], XX[2], XX[3], XX[4], XX[5], XX[6], XX[7]);
printf("\nY %3u %3u %3u %3u %3u %3u %3u %3u\n",
YY[0], YY[1], YY[2], YY[3], YY[4], YY[5], YY[6], YY[7]);
****** idea1.c
XX[0], XX[1], XX[2], XX[3], XX[4], XX[5], XX[6], XX[7]);
printf("Y %04x %04x %04x %04x %04x %04x %04x %04x\n",
YY[0], YY[1], YY[2], YY[3], YY[4], YY[5], YY[6], YY[7]);
******
****** ideaold.c
YY[0], YY[1], YY[2], YY[3], YY[4], YY[5], YY[6], YY[7]);
printf("\nZ %3u %3u %3u %3u %3u %3u %3u %3u\n",
ZZ[0], ZZ[1], ZZ[2], ZZ[3], ZZ[4], ZZ[5], ZZ[6], ZZ[7]);
****** idea1.c
YY[0], YY[1], YY[2], YY[3], YY[4], YY[5], YY[6], YY[7]);
printf("Z %04x %04x %04x %04x %04x %04x %04x %04x\n",
ZZ[0], ZZ[1], ZZ[2], ZZ[3], ZZ[4], ZZ[5], ZZ[6], ZZ[7]);
******
****** ideaold.c
}
printf("\nNormal exit.\n");
return 0; /* normal exit */
****** idea1.c
}
printf("Normal exit.\n");
return 0; /* normal exit */
******
****** ideaold.c
}
/*
* Cryptographic pseudo-random-number generator, used for generating
* session keys.
*/
byte
ideaRandByte(struct IdeaRandContext * c)
{
.....I left this whole subroutine out ....
}
/* end of idea.c */
****** idea1.c
}
/* end of idea.c */
******
***what follows is a case to match charles***
** 501**
** 207**
enter hex value of key in 8, 4 character hex words
Encryption key subblocks:
round 1: 258 772 1286 1800 2314 2828
round 2: 3342 3856 2058 3086 4114 5142
round 3: 6170 7198 8194 1030 7200 9256
round 4: 11312 13368 15424 1032 3088 5144
round 5: 20568 24680 28792 32776 4120 8232
round 6: 12344 16456 53472 61696 4128 12352
round 7: 20576 28800 37024 45248 32 16480
round 8: 32928 49377 289 16737 33185 49634
round 9: 49409 16769 49666 17026
Decryption key subblocks:
round 1: 22890 48767 15870 1251 33185 49634
round 2: 63688 65247 16159 29912 32 16480
round 3: 37199 28512 36736 63867 4128 12352
round 4: 28622 12064 49080 65264 4120 8232
round 5: 53859 36744 40856 61168 3088 5144
round 6: 58857 50112 52168 6541 7200 9256
round 7: 45536 57342 58338 17625 4114 5142
round 8: 12021 63478 61680 48951 2314 2828
round 9: 26164 64764 64250 4624
inter hex values for input block
enter hex value of input in 4, 4 character hex words
THE KEY USED IS 0102 0304 0506 0708 090a 0b0c 0d0e 0f10
THE INPUT USED IS 0001 0203 0405 0607
Encrypting 1048576 bytes (65536 blocks)...
ROUND 4 sub blocks 0102 0507 090b 610e
ROUND 6 sub blocks 670e 6f07 0219 6610
ROUND 10 sub blocks 5383 7e17 0a23 5012
ROUND 12 sub blocks a577 fcd7 4083 6e86
ROUND 16 sub blocks e683 18f5 6085 ad68
ROUND 18 sub blocks 99e8 1fee c187 741a
ROUND 22 sub blocks a0f0 5426 fdc7 06fc
ROUND 24 sub blocks 57ba 0a8d 0e70 5caa
ROUND 28 sub blocks 2c68 6af5 7ee8 b6f9
ROUND 30 sub blocks ac7e fefe 5c12 801e
ROUND 34 sub blocks 3b13 3f46 2cf2 c565
ROUND 36 sub blocks b488 a369 a57c 5f5f
ROUND 40 sub blocks fa53 13e9 361c 9568
ROUND 42 sub blocks ecbb 20f4 b346 35c7
ROUND 46 sub blocks fdf0 e1d5 b467 d9ac
ROUND 48 sub blocks 9fb2 d625 7a23 425a
**made it here *** 91
THE OUTPUT USED IS 594d bba4 9827 d478
15.989 seconds = 65581 bytes per second
X 0000 0001 0002 0003 0004 0005 0006 0007
Y 00c0 0069 0055 007b 0095 0011 00c4 004f
Z 0000 0001 0002 0003 0004 0005 0006 0007
Normal exit.
***now here is on with zero key to show it encrytps****
** 501**
** 207**
enter hex value of key in 8, 4 character hex words
Encryption key subblocks:
round 1: 0 0 0 0 0 0
round 2: 0 0 0 0 0 0
round 3: 0 0 0 0 0 0
round 4: 0 0 0 0 0 0
round 5: 0 0 0 0 0 0
round 6: 0 0 0 0 0 0
round 7: 0 0 0 0 0 0
round 8: 0 0 0 0 0 0
round 9: 0 0 0 0
Decryption key subblocks:
round 1: 0 0 0 0 0 0
round 2: 0 0 0 0 0 0
round 3: 0 0 0 0 0 0
round 4: 0 0 0 0 0 0
round 5: 0 0 0 0 0 0
round 6: 0 0 0 0 0 0
round 7: 0 0 0 0 0 0
round 8: 0 0 0 0 0 0
round 9: 0 0 0 0
inter hex values for input block
enter hex value of input in 4, 4 character hex words
THE KEY USED IS 0000 0000 0000 0000 0000 0000 0000 0000
THE INPUT USED IS 0001 0203 0405 0607
Encrypting 1048576 bytes (65536 blocks)...
ROUND 4 sub blocks 0000 0203 0405 f9fa
ROUND 6 sub blocks 080c 0c09 060b fdf2
ROUND 10 sub blocks f7f5 0c09 060b 020f
ROUND 12 sub blocks 140d e5f3 fdf2 f3f4
ROUND 16 sub blocks ebf4 e5f3 fdf2 0c0d
ROUND 18 sub blocks c7fc d1fa f3f0 1a0e
ROUND 22 sub blocks 3805 d1fa f3f0 e5f3
ROUND 24 sub blocks afe9 641c 1a02 2e0b
ROUND 28 sub blocks 5018 641c 1a02 d1f6
ROUND 30 sub blocks c428 8e32 2e0b 9be1
ROUND 34 sub blocks 3bd9 8e32 2e0b 6420
ROUND 36 sub blocks 1019 05cb 9bdd 71cf
ROUND 40 sub blocks efe8 05cb 9bdd 8e32
ROUND 42 sub blocks 07d4 73e1 71c3 fa3a
ROUND 46 sub blocks f82d 73e1 71c3 05c7
ROUND 48 sub blocks ebe5 620b fa3a 8c1c
**made it here *** 91
THE OUTPUT USED IS 141c fa3a 620b 73e5
6.703 seconds = 156426 bytes per second
X 0000 0001 0002 0003 0004 0005 0006 0007
Y 0000 0001 0002 0003 0004 0005 0006 0007
Z 0000 0001 0002 0003 0004 0005 0006 0007
Normal exit.
*** the 501 207 just debug stuff left in***
David Scott
Arnoud "Galactus" Engelfriet <gala...@stack.nl> wrote in article
<Km57y4uY...@stack.nl>...
> -----BEGIN PGP SIGNED MESSAGE-----
>
> In article <01bc0c8a$c1a57ec0$149678c7@dscott>,
> "David Scott" <dsc...@ridgecrest.ca.us> wrote:
> > I am
> > not sayiing 100% I can do it. But information theroy suggests that it
can.
>
> Fine. I hereby increase my offer from $100 to $1000, and you can
> also add Iolo's 100 UK pounds.
>
> If you can refrain from making cheap jokes and insults to people
> who respond to you, then I'll double it if you can do it.
>
Ok but I really don't know when I am insulting people. Most of the
time it is a natural gift. I would make a hell of a diplamat. I am
first trying to get people to agree just what a valid implimentaion
of IDEA is. I used the version in PGP and posted changes to get it
to work. If people agree that is valid. And it seems to match Charles
stuff. Then I will proceed from there. However I see Parker is posting
on another News Group to see if there is some official test cases.
It may be that PGP does not even use the officail blessed implimentation
of IDEA. In which case the question may become do I first attack the
PGP version of IDEA or what. I really think that what ever PGP is using
is what is really of concern. Even if it is not ture IDEA but you can wait
and
see if Parker gets any feedback. For know I will play with a version that
matches Charles unless someone see in error in what i posted I can
make mistakes. That is why I posted it. If i made an error in delta changes
or what I posted let me know. Once we show (if we show) the IDEA is
weak it is a short step to write a program as above. However at that point
you may have to fly my to Holland or where you are at so I can write the
last few routines there or some place so as not to violate any U.S.
export laws.
> Galactus
>
> - --
> To find out more about PGP, send mail with HELP PGP in the SUBJECT line
to me.
> NEW ADDRESS: --> gala...@stack.nl <-- Please PGP encrypt your
mail.
> Finger gala...@turtle.stack.nl for public key (key ID 0x416A1A35).
> Anonymity and privacy site: http://www.stack.nl/~galactus/remailers/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: cp850
>
David Scott
parker_rob <rpa...@loc3.tandem.com> wrote in article
Yeah I mostly cut out what you thought impoertant sorry
but I thoguth we are going some where.
> Second, the belief in the strength of IDEA is not based only on the
> size of the key. The fact that the keyspace of IDEA is so large (2^128)
> that a brute-force keyspace search is impossible is only one part.
> Unfortunately, the rest of it is far to complex to cover here. IDEA
> is fairly new, but there has been some research looking at it which
> has so far found it to be entirely secure (except for a small set of
> "weak" keys). I suggest you look up the research into IDEA's strength
> (or lack thereof) and try reading it before you suggest that all those
> experienced experts know less about it than you.
>
I would like to see what the so called experts have to say other than
some had waving but I doubt i will get the chance. I will show you the
progress that I make or fail as i go.
> > As i also pointed out IDEA is nothing but an algebra. Granted it is a
> >mixture of 3. but every where a sub key is used it of form:
> >a op subkey = b where op could be addtion or multiply or
whatever
> >then
> >knowing just one a,b pair along with the op
> >directly yelids the subkey.
> >example :
> >10101010 + subkey = 1111111
> >this implies subkey is 01010101
> >now given ANY "a" since one has subkey you get the "b"
> >portion
>
> Unfortunately for you, you don't have access to any such pairs, even
one does not in a standard algebra to. yet once you solve such a
system symbolically only once you have solution forever.
> in a known-plaintext attack. The values you would need are all temporary
> values inside the 8-round IDEA algorithm.
>
> Also, the combination of addition mod 2^16 and multiplication mod 2^16+1
> does not allow analysis through linear methods. If the multiplication
> used the same modulus (2^16) it would be linear. It would also not work
> properly because 2^16 is not prime; not all values would have inverses.
>
I feel the word linear as applied to this kind of algebra is highly over
rated.
so what. It makes the problem more fun.
Good we are starting to get some where I hope. you are correct one does
not have access to such pairs but one can write a symbolic equation algebra
like equation that one can use to describe the system. Lets get to the
heart of it. Only three operators used xor add and mul and there inverses.
I do not have symbolic algebra processors but please for sake of argument
using only basic proerties
a op b = b op a
and the inverse operators are used.
I wish another word was used besides multiply
so as not to confuse you. but using the fact above
and that the XOR operater such that the even number of
occurance of a term drop out i mean a x b x c x c x b x a x b =b
when I use "opm" for multiply i mean the mul of idea not normal binary
mutiply. I realize this is what is con fusing people but it shoud not.
do you agree to the following from heart of IDEA
let x1 x2 x3 x4 be the message
after the first 4 sub blocks used
then do the nolinear mixing(your words somewhere) of the 4 x's
and get
xa xb xc xd
out tell me if you agree that not using vi editor so for give me
let + have lowest prcesidence to save on ()
xa=x1 opx ( k5 opm ((k6 opm (x1 opx x3)+(x2 opx x4)) ))
xb=x3 opx ( k5 opm ((k6 opm (x1 opx x3)+(x2 opx x4)) ))
xc=x2 opx (( k5 opm ((k6 opm (x1 opx x3)+(x2 opx x4)) )) + (k6 opm (x1 opx
x3) )
xd=x4 opx (( k5 opm ((k6 opm (x1 opx x3)+(x2 opx x4)) )) + (k6 opm (x1 opx
x3) )
i have solved for k5 and k6 symbolically from just xa xb xc xd x1 x2 x3 x4
where opx is XOR and opm is the IDEA multiply
the algebra gets messy fast but this is from heart of IDEA I would like to
see
if Paker or some one else can verify the above equations first.
> >if a table look up used this is not possible since only one entry to
> >table is known
>
> When you include quoted text in a followup you need to include the
> attribution line (who wrote it). You also need to work on keeping
> your lines shorter. This post wasn't too bad, but you can see where
> your software (I assume) has automatically wrapped "real" to a line
Your lucky i didn't cut your top line off. Actually I see no wrap
your lines only go about 2/3 od way across page. But I will try to
keep lines short. But as ex wife found out it is hard to remember
all the rules.
> by itself because it extended too far to the right (this is in your
> first paragraph included above). Some of your other posts look
> downright crappy because nearly every line has one or two words that
Well I am a crappy person to most people anywhy. So thanks.
Ed Falk
In article <Km57y4uY...@stack.nl>,
Arnoud "Galactus" Engelfriet <gala...@stack.nl> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>In article <01bc0c8a$c1a57ec0$149678c7@dscott>,
>"David Scott" <dsc...@ridgecrest.ca.us> wrote:
>> I am
>> not sayiing 100% I can do it. But information theroy suggests that it can.
>
>Fine. I hereby increase my offer from $100 to $1000, and you can
>also add Iolo's 100 UK pounds.
-----BEGIN PGP SIGNED MESSAGE-----
I'm in for $1000.
-ed falk
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQBVAwUBMu/m6DLd6HIbO1jdAQF2nwH/WldITEkfJwLbT4gCovrENWKB+KFVzPua
XdAjjdQv4wqYROg/tgnSfygbylpeRZhCtL5bNOqNgtcJZGBHlaXT4A==
=LiHK
-----END PGP SIGNATURE-----
--
-ed falk, sun microsystems -- fa...@sun.com
If there's ever a nuclear holocaust, the only things left
alive afterward will be cockroaches and spammers
-- Dan Gillmor, Mercury News
Ed Falk
[Hi; could you try to format your messages in the future? They're
really hard to read]
In article <01bc0af4$c85f0660$889678c7@dscott>,
David Scott <dsc...@ridgecrest.ca.us> wrote:
>
>
>Paul L. Allen <p...@sktb.demon.co.uk> wrote in article
><cD-4w...@sktb.demon.co.uk>...
>>
>
> You are right. But I never attacked RSA. I was talking about IDEA.
>I guess if I get enough of you idoits pissed off maybe some one will really
>make a contest like I suggested. Unless there is a fear that it is to easy
>to crack.
Actually, the owners of the IDEA algorithm did just that thing. The
prize was a trip for two to Switzerland. See
www.ascom.ch/Web/systec/contest1.htm
However it ended last month. Nobody even entered. Still, I'm sure
the folks here in this newsgroup can kick in enough money to make
it worth your while to show us how. Feel free to propose some
rules. Known plaintext, chosen plaintext, you name it.
> You remind me of the PhD idiots who said we never would get to the moon
>or the ones who said noble gas componds are impossible. ...
Yeah, yeah, yeah. Old argument. "Other people said something else was
impossible, and they were wrong!"
If you have reason to believe that there are weaknesses in IDEA, you
should share them with us. Arguments along the lines of "Other crypto
systems are weak" or "They said we'd never walk on the moon" or "you
can't prove it's impossible" don't really carry a lot of weight.
> Only a true idiot would belive that IDEA gives such a high degree of
>security. Granted if an idiot such as you randomly tried to guess it
>you would never get it done. ...
If you would like to suggest another approach, I'm sure we'd all like
to hear it.
>Why are people like you so narrow minded
>that you FASLELY assume one has to randomly search by using guesses for
>keys. Yes I took a simpler system that has a longer REAL KEY length and
>it is easy to break.
Big, fat, hairy deal. I recently broke a system with a key of over a
hundred characters myself, just to see if I could do it. So what? It
was a lousy system. It wasn't IDEA. The existance of lousy algorithms
serves only to prove that lousy algorithms exist. We already knew
that.
sal
Stand up now David!
Put yourself on the line and accept the challenge.
If you are an honorable and capable man you will pick up
the gauntlet and accept the challenge that you now
confront.
Otherwise we will all consider you to be a buffoon,
spouting off nonsense, and then hiding behind
pathetic delays and excuses.
I will add $100 (US) to the kitty because I know that you
are incapable of winning this bet.
You have 3 choices: 1)Withdraw your proposal and admit
your errors.
2)Submit your proposal to the objective trial
which is proposed.
3) "Weasel" out by whining about your inadequate
computing resources.
I suspect you will do #3.
As in all scientific endeavor it is incumbent on you to
prove your theory. It is not the responsibility
of IDEA's proponents to continually redemonstrate its
widely accepted strength. IDEA has withstood it's trials
very well and is now accepted. If you wish to demonstrate
its weakness then you must proceed.
Further comments by you will be laughed at if you do not
produce some convincing proof or hard data.
sal-
David Scott
Iolo Davidson <io...@mist.demon.co.uk> wrote in article
<854563...@mist.demon.co.uk>...
> In article <01bc0c8d$99a54b00$149678c7@dscott>
> dsc...@ridgecrest.ca.us "David Scott" writes:
>
> > The 100 dollars is an insult.
>
> The hundred pounds I offered is of course worth a lot more.
> Quality currency, the pound sterling.
>
Can I spend it in Ireland?
What is with Burma Shave you have stock in it or something?
> --
> 'TWOULD BE IF WE COULD PUT
> MORE FUN THESE SIGNS UP THERE
> TO GO BY AIR Burma-Shave
>
>
David Scott
2 things follow. I decided to show how the so called
nonlinear part of IDEA can be undone by algebra
yes it is only a start but have you read about anyone
else even getting this far. The first is output of idea2.exe
while second is a mod of the idea1.c which I printed
the diferences from PGP supplied IDEA and idea2.c.
It proves even more to me that IDEA can be broken
by a symbolic algraba of 52 unknows versus 52 inputs
once someone just sloves equation once. It does not
have to be solved again. IF you think NSA is not that
bright maybe you are right. But then maybe the guys
in the UK or IRAQ have it broken.
** 501**
** 207**
enter hex value of key in 8, 4 character hex words
Encryption key subblocks:
round 1: 4660 9029 26505 9028 22324 17714
round 2: 22149 61404 35535 4678 34990 26762
round 3: 25773 3039 47140 26694 36113 23761
round 4: 5321 23063 49008 18640 36117 40484
round 5: 41513 37556 12158 57489 41242 11068
round 6: 18714 8889 26718 64961 9026 13398
round 7: 30866 13381 29508 21285 33350 33896
round 8: 44273 9320 35558 34982 19152 48635
round 9: 53593 57928 53525 52497
Decryption key subblocks:
round 1: 61943 7608 12011 7001 19152 48635
round 2: 39848 29978 56216 64782 33350 33896
round 3: 29384 36028 52155 22560 9026 13398
round 4: 47428 38818 56647 51087 41242 11068
round 5: 6659 53378 27980 42744 36117 40484
round 6: 64798 16528 42473 42919 36113 23761
round 7: 32813 18396 62497 24043 34990 26762
round 8: 23118 30001 4132 32040 22324 17714
round 9: 40602 56507 39031 11898
inter hex values for input block
enter hex value of input in 4, 4 character hex words
THE KEY USED IS 1234 2345 6789 2344 5734 4532 5685 efdc
THE INPUT USED IS 1234 6642 5492 3869
Encrypting 1048576 bytes (65536 blocks)...
ROUND 4 sub blocks 5945 8987 bc1b 4f1f
ROUND 6 sub blocks 81c6 6498 9afd 5c65
key1= 5734 key2 =4532
cal1= 5734 cal2 =4532
ROUND 10 sub blocks c403 5474 25cc 5706
ROUND 12 sub blocks ff4c 1e83 6107 6275
key1= 88ae key2 =688a
cal1= 88ae cal2 =688a
ROUND 16 sub blocks d1f7 2a62 192b 4be4
ROUND 18 sub blocks b8e8 7034 576f 36e9
key1= 8d11 key2 =5cd1
cal1= 8d11 cal2 =5cd1
ROUND 22 sub blocks 3f25 ca4b 16df 15b2
ROUND 24 sub blocks a7a0 8e5a 6eae b157
key1= 8d15 key2 =9e24
cal1= 8d15 cal2 =9e24
ROUND 28 sub blocks ae73 210e 9e2c f6b8
ROUND 30 sub blocks 28b4 18eb 31f3 e645
key1= a11a key2 =2b3c
cal1= a11a cal2 =2b3c
ROUND 34 sub blocks 6aa9 3ba4 9a51 e6c7
ROUND 36 sub blocks 6156 91ae c964 1407
key1= 2342 key2 =3456
cal1= 2342 cal2 =3456
ROUND 40 sub blocks a535 c5f3 3ca8 2382
ROUND 42 sub blocks d72d 4eb0 1b28 fd59
key1= 8246 key2 =8468
cal1= 8246 cal2 =8468
ROUND 46 sub blocks 3c01 7318 a60e 087b
ROUND 48 sub blocks 8a77 1078 78b9 03da
key1= 4ad0 key2 =bdfb
cal1= 4ad0 cal2 =bdfb
**made it here *** 91
THE OUTPUT USED IS d925 5b01 e18d d065
16.208 seconds = 64691 bytes per second
X 0012 0034 0066 0042 0054 0092 0038 0069
Y 00bd 0075 0078 002c 000d 00c0 00be 00d0
Z 0012 0034 0066 0042 0054 0092 0038 0069
Normal exit.
Comparing files idea1.c and idea2.c
****** idea1.c
#ifdef _GNUC_
****** idea2.c
word16 x1r2, x2r2, x3r2, x4r2;
word16 x1r6, x2r6, x3r6, x4r6;
word16 tds1, tds2, tds3;
#ifdef _GNUC_
******
****** idea1.c
if (dasf)
printf("ROUND %2d sub blocks %04x %04x %04x
%04x\n", 6 * dasf-2, x1, x2, x3, x4);
s3 = x3;
****** idea2.c
if (dasf) {
x1r2 = x1;
x2r2 = x2;
x3r2 = x3;
x4r2 = x4;
printf("ROUND %2d sub blocks %04x %04x %04x
%04x\n", 6 * dasf - 2, x1, x2, x3, x4);
}
s3 = x3;
******
****** idea1.c
if (dasf) {
printf("ROUND %2d sub blocks %04x %04x %04x
%04x\n", 6 * dasf++, x1, x2, x3, x4);
if (r == 1)
****** idea2.c
if (dasf) {
x1r6 = x1;
x2r6 = x2;
x3r6 = x3;
x4r6 = x4;
printf("ROUND %2d sub blocks %04x %04x %04x
%04x\n", 6 * dasf++, x1, x2, x3, x4);
printf(" key1= %04x key2 =%04x\n", key[-2],
key[-1]);
tds1 = x1r2 ^ x1r6;
tds2 = x2r2 ^ x3r6;
tds3 = x1r2 ^ x3r2;
tds2 -= tds1;
tds1 = mulInv(tds3);
MUL(tds2, tds1); /* key back 2 spots */
MUL(tds3, tds2);
tds3 += x2r2 ^ x4r2;
tds1 = x1r2 ^ x1r6;
MUL(tds1, mulInv(tds3));
printf(" cal1= %04x cal2 =%04x\n", tds2, tds1);
if (r == 1)
******
this was done so others can follow. I am sure some one out there
knows enought algebra to flat solve this. I will work farther but
would hope that there is someone wiht a little brain power that
can add something useful to this thread.
David Scott
Paul L. Allen <p...@sktb.demon.co.uk> wrote in article
> Since I couldn't find any nice description of what's going on inside IDEA
> I assumed (from things *you* said earlier) that it's using half the key
to
> encrypt alternate blocks. Maybe it's using the whole key for each block,
> which makes it all the harder for you.
>
Well I am hard to follow but my programs work. This above part tells me
you know little of the IDEA algorithm. If you can't read the source c code
in the source files of PGP then why are you attacking me. Just what the
hell do you now about encryption anyway.
> Bollocks. The chaining is an *intrinsic* part of IDEA. From the way the
> source is commented it's not clear if CFB was added when IPES mutated
into
> IDEA or whether it is exclusive to PGP. But IDEA (and IPES) always did
> support CBC.
>
What the hell is Bollocks is that a department store or is it the
Brits can't say Bull Shit.
>
> They *may*. I tend to doubt it. They've put too much effort into
pushing
> Clipper, which they wouldn't need if they could crack PGP. It could be
> double-bluff, but they really don't need to do that - people will use PGP
> anyway.
>
Yeah they do need to do that to keep idiots like you hooked.
> Do you often manage to contradict yourself in the space of two sentences?
> It is not *just* the key length. That means that 128 bits is damn short
> if you have a ludicrously weak algorithm and plenty strong enough if you
> have a strong one. A strong algorithm is one where brute-forcing the key
is
> the only known attack. Do you have any idea how long it would take to
try
> 2^127 keys, even on a Cray?
Have you ever even written code for a cray I have so what is your
problem. Hell I suppose my English sucks so bad I can contradict
my self several times in same sentence to bad we didn't adopt a
better language to use than English.
> [Scott cuts, without any indication that he has done so, his original
Why not you admit you don't understand IDEA anyway
>
> I will let you analyse it with pleasure. Let us know the results. What
I
> won't do is let you make unsubstantiated claims to this group without
> evidence.
>
I have a feeling any guy in a suit could make unsub... claims and
you would not know shit from shine ola. God hope them if you
actually think you could even subs.. anything.
>
> Great, so you were a child genius and maybe still are. Or maybe you just
> think you are.
>
Well I hope it is both.
> Is there no end to your deceitful ways? I have marked, 5 paragraphs
above,
> where YOU raised the point about what mathematicians would make of IDEA.
> You were the one who claimed (but cut in this response) that they would
> agree with you that IDEA is weak. Now you claim that you don't care what
> they say and attempt, with your unmarked cut, to make it look like I
raised
> the point about mathematicians.
>
You are correct. I am sorry I feel any true mathematican woud at
least feel there is the possibility of attacking IDEA. But Newton
died a long time ago. Not sure there any English that good at math
since then. But will resevere judgement.
Like I said before my English sucks and am trying to answer
quickly so my cutting is rather poor I wish we spoke a better
language.