Cryptography-Digest Digest #49, Volume #10 Sun, 15 Aug 99 01:13:04 EDT
Contents:
Re: Clerification of Crypto Export Laws (Sundial Services)
Re: IDEA in AES (Stephan Eisvogel)
Re: Twain is Part of Shania (OT), was Re: I HOPE AM WRONG ([EMAIL PROTECTED])
Re: Clerification of Crypto Export Laws ([EMAIL PROTECTED])
Re: Cipher-Feedback Mode (Scott Fluhrer)
Re: Cracking the Scott cryptosystems? (SCOTT19U.ZIP_GUY)
Re: Cracking the Scott cryptosystems? (SCOTT19U.ZIP_GUY)
Re: Wrapped PCBC mode (SCOTT19U.ZIP_GUY)
Re: Clerification of Crypto Export Laws (Jerry Coffin)
Re: NIST AES FInalists are.... ("Douglas A. Gwyn")
Re: Cracking the Scott cryptosystems? ("Douglas A. Gwyn")
Re: NIST AES FInalists are.... ("Douglas A. Gwyn")
----------------------------------------------------------------------------
Date: Sat, 14 Aug 1999 19:05:07 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Clerification of Crypto Export Laws
[EMAIL PROTECTED] wrote:
>
> I have a few questions, if anyone could shed some light I would be very
> thankful:
>
> 1) If you reduced the key down to 40 bits (or whatever the US government
> allows), do I still have to clear the program with the US government?
>
> 2) If someone used a half baked encryption scheme (just something that
> they made up), does it still apply to the Laws? (Something like
> shifting, xoring, etc, nothing big)
I believe that the Department of Commerce web-site has definitive
information about the current export control-laws; I'm quite sure that
any web-search will quickly inundate you with pages.
And if you're doing a commercial venture -- hire an attorney who is
well-versed
in the subject and can prove it.
As for "half-baked encryption schemes ..." why bother to even attempt
one, especially if you know it's bad, when there are dozens of good
algorithms that you can legally use? If the data needs to be secured,
it deserves to be secured well.
And furthermore -- don't dismiss even a 40-bit algorithm if it really
does force the user to exhaustively try 2^40 possible keys before
finding the right one!
-> If it really does that, and your attacker isn't the NSA, it's
probably
sufficient. Many messages simply aren't worth the trouble. Many
more
effectively expire (become worthless, pointless to decrypt) before
the
attacker is likely to break them. And if the key is managed well,
so that
the next message poses a problem that's just as big, etc...
-> If it does not do that as actually used (e.g. dictionary attack),
then not
even Triple-DES will improve the actual security.
------------------------------
From: Stephan Eisvogel <[EMAIL PROTECTED]>
Subject: Re: IDEA in AES
Date: Sun, 15 Aug 1999 05:33:04 +0200
Helger Lipmaa wrote:
> This assertion, is however true. I think IDEA seconds only to DES in the
> manpower wasted in analyzing it. Note that the 4.5 round attack for IDEA is
> utterly impractical, less practical than the known attacks for full DES.
Yeah, so there's still 4 _more_ rounds to kill until IDEA can be
considered
'broken'. The beauty of IDEA lies in its simplicity, the low number of
rounds
to achieve security, the fact that there are no weird S-boxes, the sheer
number of attempts to brake it by people who are otherwise impossible to
understand, and in its ability to withstand even new cryptoanalytic
attacks.
Couldn't say that about most AES entries, could you? Speaking of AES,
IDEA
can be implemented on the tinyest microcontroller easily.
Alright it's free for non-commercial use only, but I'm not a rich bank
(they
use 3DES to stay rich) and not Bill Gates (Crypto-what) either, so who
cares.
I've been using IDEA to protect my harddisk partitions, e-mail, EEPROM
data
for microcontrollers, and countless other stuff I built over the years.
No
need to wait for an AES to pop up, I already _got_ a good one.
Cryptographic
algorithms are like fine wines, they get alot better with age!
Laters,
Stephan
( I'm taking off any second here =D )
PS: Everybody stop whining about how slow IDEA is, buy a _real_ CPU with
hardware MUL!
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Twain is Part of Shania (OT), was Re: I HOPE AM WRONG
Date: Sun, 15 Aug 1999 03:43:17 GMT
In article <7p50js$4tf0$[EMAIL PROTECTED]>,
"Richard A. DeCamp" <[EMAIL PROTECTED]> wrote:
> No, Mr. Scott probably did mean Twain (Shania, a beautiful Canadian
country
> and western singer, if you haven't heard of her), and I believe
Clinton
> would say, "sorry, Mr. Chairman, I can't let you all invade her, I
saw her
> first."
Great singer but shes anerexic....
Allanis is from Ontario and Shania is from Montreal right? Jim Carrey
is from Canada as well.
> > What's all this rubbish got to do with crypto?
>
> Frankly, nothing. I think they let him stay as a cautionary example
and
> because even cryptologists like a good joke now and then.
That's about right. Even us 'newbies' like lauging at his posts.
Tom
--
PGP 6.0.2i Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Clerification of Crypto Export Laws
Date: Sat, 14 Aug 1999 23:55:55 -0400
Sundial Services wrote:
> As for "half-baked encryption schemes ..." why bother to even attempt
> one, especially if you know it's bad, when there are dozens of good
> algorithms that you can legally use? If the data needs to be secured,
> it deserves to be secured well.
Erg...I new that this would start a holy war. The point being this is NOT a
crypto project. SIMPLE encryption is going to be used to make data hard to
manipulate data in an application. This is not a security product nor does it
need strong cryptography, AT ALL. That is why I'm trying to get around the
government entirely.
------------------------------
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: Cipher-Feedback Mode
Date: Sun, 15 Aug 1999 03:57:13 GMT
In article <7p3t3s$ml4$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>In article <7p2ccp$nn7$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>>
>> Maybe because CFB was designed to encrypt blocks smaller then the
>block
>> length. It's ok though I am surprised anyone uses CFB anyways...
>>
>> Tom
>> --
> Two advantages of CFB come to mind immediately:
>1) Not needing a separate decrypt routine means shorter
> programs
>2) The inhereht error correction of CFB means less loss
> of data in a noisy environment
Third one:
3) You can encrypt a block of an arbitary length without any
ciphertext expansion
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Cracking the Scott cryptosystems?
Date: Sun, 15 Aug 1999 04:59:23 GMT
In article <7p50pe$dv8$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>Greetings.
>
>I am a relative beginner in Cryptanalysis, with a background in Computer
>Science and Math. Recently, a co-worker pointed me to cryptosystem
>designed by a regular poster to this forum, "David Scott" with an
>associated prize.
>
>The cryptosystem in question appears to be a chained-substitution
>cipher, and I don't see many references to anything similar in the
>cryptographic texts I have access to, most noteably Applied
>Cryptography. Is there a reason why this form of cryptosystem isn't
>generally used (discounting specific weaknesses in the design of the
>system in question)?
>
>Fitting together the pieces of the cryptosystem from both the source
>code and the descriptions by other individuals, it appears that the
>operation is as follows:
>
>
>Create a substitution table S which 2^16 entries
>
>Order the numbers from 0 to 2^16 - 1 in this table, such that no
>number is repeated.
>The system consists of three stages:
> (A) pre-"whitening"
>
> Take value P[1] to be S[ M[0] ] XOR S[ S[ M[0] ]].
> For M[i](i from 1 to N inclusive), M'[i] = M[i] XOR P[i]
> P[i+1] = S[ P[i] ].
>
> (B) encryption
>
> Encryption is performed on 16bit chunks. Given a message
> consisting of 16 bit chunks M[0] .. M[N], the resulting
> encrypted message E will be formed by:
>
> E[0] = S[ ((M[N] XOR M[0]) + M[1]) MOD 2^16 ]
> E[i](i from 1 through N-1 inclusive) =
> S[ ((E[i-1] XOR M[i]) + M[i+1]) MOD 2^16]
> E[N] = S[ ((E[N-1] XOR M[N]) + E[0]) MOD 2^16 ]
>
> Decryption relies on a table S' such that S'[y] = x for every
> S[x] = y, with the operations appropriately reversed.
>
> After each round of encryption, E[0]..E[N] is rotated left by 8.
> (treating all E as a large shift register).
> TMP = E[0]
> E'[i](i in 0 to N-1) = (E[i] SHR 8) OR ((E[i+1] AND 2^8-1) SHL 8)
> E'[N] = (E[N] SHR 8) OR ((TMP AND 2^8-1) SHL 8)
>
> This round function is repeated 15 times.
>
> (C) post-"whitening"
>
> Take the final E' from stage B to be E.
> Take value P[1] to be S[ E[0] ] XOR S[ S[ E[0] ]].
> For E[i](i from 1 to N inclusive), E'[i] = E[i] XOR P[i]
> P[i+1] = S[ P[i] ].
>
>The challenge consists of two files, with a delta of 4 octets different.
>The cipher text and plain text is given for file1, and only the cipher
>text is given for file2. According to the description, the substitution
>table is created from a file with 2^17 bytes (2^16 entries with 2^16
>bits). The plaintext files are roughly 35,000 bytes long.
>
>It appears, although I don't have enough background in information
>theory to prove it, that there is not enough information provided in
>this system, because stages (A) and (C), given the small file size and
>different starting positions this seems effectively to be a one time
>pad. Is this correct?
Your much smarter than most people who post to this site.
Just about everyone here thanks it is foolish to use a long keyed
crypto system. And your might be correct in the sense that more
than one S-table exists that would satisfy the constrants so that
it would be very easy to get a solution but it might not be my
solution. If you notice I said I got my solution by useing some short
phrases less than 80 characters each. I am not sure if other soultions
exist under those conditions. However I give the first phrase I use
at my website. It this point in the CONTEST. I would be happy to give
50 bucks to the first person that just comes up wiht an S-table ( keyraw.key
file) that just statisfys the constrants they have to get the same number of
changes but it does not have to be the same ones. This should make it a
lot easyier for you.
>
> (It does not appear there is enough information to determine if the
> files in question contain 'overlap' of position information? How
> much data would I need to determine this? )
>
> (A major difference between a one-time pad and this arrangement is that
> this 'pad' consists of an ORDERING of the numbers, and the numbers do
> not repeat. It seems that more data would be required to exploit
> this as well? )
>
>To hopefully reduce simple flames, I do realize that this system isn't
>anything like a one-time pad under general circumstances, I am refering
>to the SPECIAL CASE of this challenge?
>
>Is it possible to prove this using information theory?
Yes you can prove at least from starting with a solution
that there is more than one S-table that get exactly the same result.
But I had an advantage I had a solution to begin with.
>
>For the general case there seems to be several weaknesses with this
>algorithm.
>
>(1) Given a large enough number of files encrypted with
>the same s-table, it is likely that there will be multiple files
>starting with the same E[0]. This could be used to get at the previous
>stages - although I'm not experienced enough to understand exactly how?
>
I am not sure that would work.
>(2) Once past stage (C), it appears that stage (B) can be attacked from
>the ends. Since E[N] has only one unknown - the M[N] value, and E[0]
>involves the combination of that M[N] with other M[] values, it appears
>that an attack could proceed from that point?
>
>(3) If enough known plaintext/ciphertext pairs were known, although I
>admit that I can't determine how much would be enough, it would seem
>that this could be approached from 'both ends', and use this to get the
>s-table values? This would require plaintexts where M[0] was identical
>and that result in a ciphertext where E[0] was also identical?
>
>(4) The post-whitening stage (C) will repeat after 128KB of data, and
>for a large enough file, this would also yield a way in?
>
>I conceed that I am stumped as far as the challenge is concerned,
>although I welcome comments, and suggestions as to whether I am
>approaching this in the right way. I would also welcome recommendations
>on resources electronic and otherwise which would assist me in future
>projects.
>
>Thank you.
There defintily is enough information to solve the gloat contest
if no one solves the contest by Nov 11. I am just start with a similar
one for scott19u. But I would do it in the form that it is in know just
becuase the AES weak encyrption methods are to weak to run a
similar contest.
Take Care
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Cracking the Scott cryptosystems?
Date: Sun, 15 Aug 1999 05:04:09 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>[EMAIL PROTECTED] wrote:
>>
>> The plaintext files are roughly 35,000 bytes long.
>>
>> It appears, although I don't have enough background in information
>> theory to prove it, that there is not enough information provided in
>> this system, because stages (A) and (C), given the small file size and
>> different starting positions this seems effectively to be a one time
>> pad. Is this correct?
>>
>> (It does not appear there is enough information to determine if the
>> files in question contain 'overlap' of position information? How
>> much data would I need to determine this? )
>>
>> (A major difference between a one-time pad and this arrangement is that
>> this 'pad' consists of an ORDERING of the numbers, and the numbers do
>> not repeat. It seems that more data would be required to exploit
>> this as well? )
>
>Well, it's not a one-time pad, to be sure, but I think you're correct in
>speculating that Scott is probably pretty safe with his money if he
>provided only two, 35K-byte ciphertexts in his challenge problem. A
>much more realistic challenge would have provided several hundred or
>even several thousand messages, all of them chosen to be "typical
>examples of the algorithm as it might be applied," and to award the
>prize to the first person who broke any one of them.
>
Actually I give more info than the IDEA challange. Also I didn't
see Mr BS do anything remotely similar with his toy AES entry.
>
>> (4) The post-whitening stage (C) will repeat after 128KB of data, and
>> for a large enough file, this would also yield a way in?
>
>Given that many of the files one might want to encrypt are hundreds of
>kilobytes long (ever measured the size of an MS-BloatWord document
>lately?) and also are likely to be generated by word-processors or
>compression-programs with predictable characteristics, I do think that
>"realistic challenge" messages would need to consist of or to include
>these.
>
>And yes, there ought to be known-plaintexts included too. Lots of them,
>because in operational practice someone might send public files along
>the link, and might send the same file with different internal-keys, and
>so on.
>
>
>> I conceed that I am stumped as far as the challenge is concerned,
>> although I welcome comments, and suggestions as to whether I am
>> approaching this in the right way. I would also welcome recommendations
>> on resources electronic and otherwise which would assist me in future
>> projects.
>
>Every cipher-system tries to "bury" the discernible characteristics of
>the text so that the cryptologist has nothing to go on. If you want to
>make money by cracking a grand-total of two 35K documents ... forget
>it. Buy Red Hat instead.
Actually you can get the Red Hat code for free. Or has something changed
that you have to pay money to get it now.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Wrapped PCBC mode
Date: Sun, 15 Aug 1999 05:17:27 GMT
In article <7p4va4$ctq$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>In article <7p4jnt$5l5$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> Can someone name me one benefit of Dave's 'super-duper' W-PCBC mode?
>>
>A benefit of this mode is that if an error occurs in the ciphertext, all
>blocks after the error are corrupted. This will allow you to check the
>integrity of the message by checking the last block of the message.
>There's an apparent problem. If two ciphertext blocks are swapped, you
>get a garbled message, but because of the way XOR works with the
>previous ciphertext and plaintext, the error is canceled out. Because
>of this, there is no real benefit of PCBC. I doubt the wrapping takes
>care of this.
>
>In case your wondering where this came from, check AC2, page 207.
>
What you say about ordinary PCBC is true you can swap 2 blocks
in the message and they are garbled but the rest are not. This is old
news. I think you are acting alot like Wagner saying things about
"wrapped PCBC" with out every having looked at it. This is not a problem
in "wrapped PCBC" if two blocks get swaped in the output and you try
to decrypt the WHOLE FILE is trashed. Why don't you guys check
things out once and awhile before you make such dumb statements.
One big advantage of "wrapped PCBC" is the all or nothing encryption
that results from it. And you can encrypt using large blocks but yet still
have encrypted files the same size as input files. And yet a change
anywhere in the file changes the whole output file front to back.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Clerification of Crypto Export Laws
Date: Sat, 14 Aug 1999 22:37:58 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> I have a few questions, if anyone could shed some light I would be very
> thankful:
>
> 1) If you reduced the key down to 40 bits (or whatever the US government
> allows), do I still have to clear the program with the US government?
Yes. As long as the key is small enough to make the encryption
worthless, the license is supposed to be easy to get, but it's still
needed.
> 2) If someone used a half baked encryption scheme (just something that
> they made up), does it still apply to the Laws? (Something like
> shifting, xoring, etc, nothing big)
At least in theory, yes. Of course, it's unlikely that the rules
would be enforced as long as the "encryption" was sufficiently
trivial, but that's really only a guess -- in theory you could be
prosecuted for even a really trivial form of encryption.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: Sun, 15 Aug 1999 04:23:54 GMT
"Thomas J. Boschloo" wrote:
> "Douglas A. Gwyn" wrote:
> > What has never been explained is the technical design that
> > could allow such a cipher to be exploitable by the Agency
> > but not by our enemies. You would think that would be an
> > unacceptable risk.
> This is not a problem. The Agency could just make the exploit just small
> enough for them to crack with an enormous amount of resources, but not
> for enemies because if would require to much computer time.
Dammit, that's *not* a technical design, that's the same old
unsupported assertion that "it could be done". *How* could
it be done?
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Cracking the Scott cryptosystems?
Date: Sun, 15 Aug 1999 04:47:51 GMT
[EMAIL PROTECTED] wrote:
> Is there a reason why this form of cryptosystem isn't generally used?
David seems to think it is an NSA-led conspiracy, but actually there
are numerous more thoroughly understood systems that people think
work well enough, so there is little motivation to work on a new one.
The most serious problem, though, is the large key size, which makes
key management a much bigger problem than usual.
> It appears, although I don't have enough background in information
> theory to prove it, that there is not enough information provided in
> this system, because stages (A) and (C), given the small file size
> and different starting positions this seems effectively to be a one
> time pad. Is this correct?
If a different key file (S-box generator input) were used for each
message, then it would have similar characteristics to a one-time
pad. Note that one-time pads aren't often used in practice either.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: Sun, 15 Aug 1999 04:30:58 GMT
[EMAIL PROTECTED] wrote:
> Well as for brute force if the keyspace is flat the fastest method is
> parallel linear searches. No matter what algorithm you use it will not
> be faster then testing all keys sequentially (unless the keyspace is
> not flat).
That is an incredible assertion. What is the mathematics behind it?
It sounds like a very important theorem, if true. (As you might
infer, I do not think it is true.)
> BTW I seriously doubt in the 70's they had the ability to search the
> DES keyspace in less then a year.
You would lose your bet.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
