Cryptography-Digest Digest #736, Volume #9 Fri, 18 Jun 99 18:13:03 EDT
Contents:
Re: the student paradox (David A Molnar)
Re: Critique of Street Performer Protocol paper ([EMAIL PROTECTED])
Re: Solitaire optimization (Johnny Bravo)
Re: OTP is it really ugly to use or not? ("Douglas A. Gwyn")
Re: CAST-256 implementation (?) ("Serge")
Re: test (Gergo Barany)
Re: Slide Attack on Scott19u.zip (Horst Ossifrage)
Re: alt.security.scramdisk (Noam E. Rikly)
Re: crack the winzip files with password (JPeschel)
Re: Questions for David A. Scott (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: the student paradox
Date: 18 Jun 1999 18:20:58 GMT
David A Molnar <[EMAIL PROTECTED]> wrote:
> Personally, I would hope for the latter. Just today I found out about
> a paper on "Fast Approximate PCPs". The paper covers techniques by
Whoops - that would be
"Fast Approximate PCPs", Funda Erg\"un, Ravi Kumar, and Ronitt Rubinfeld
from STOC '99 pp. 41-50
and online references appreciated.
(Rubinfeld's home page is at
http://simon.cs.cornell.edu/Info/People/ronitt/homepage.html
but the paper is not yet listed)
Thanks,
-David Molnar
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Critique of Street Performer Protocol paper
Date: Fri, 18 Jun 1999 17:21:45 GMT
Anonymous <[EMAIL PROTECTED]> wrote:
> Comments on http://www.counterpane.com/street_performer.pdf:
>
> Regarding secure perimeter schemes:
>
> > There is also an economic problem. The customer does not see much
economic
> > value in purchasing a secure perimeter. Selling a tamper-resistant
device
> > useful only to play copyrighted content (e.g., a sealed box with
speakers
> > and a video screen) seems dicult.
>
> This is not necessarily true. In fact there is some evidence that
Intel's
> move towards embedding serial numbers and cryptographic functionality
> into their chip set is primarily for this purpose. A customer will
> want to buy a box that can play secured data if that data is much less
> expensive than non-secured. If you have a choice between buying a
> Microsoft product for $495 on a regular PC or $29.95 on a secured PC,
> there will surely be a market for secured PCs. (Of course if you're
> just going to pirate the software you won't be in that market.)
You picked an auspicious time to argue this. The first major
encrypted perimeter content system, Circuit City's "DIVX" has
just gone belly up after they sunk a reported $200 million into
it. See http://www.divx.com
Circuit City is trying to claim that customers liked DIVX
and it was lack of support by studios and other retailers that
sunk the project. They're lying. DIVX failed because the
public overwhelmingly rejected it. Circuit City itself managed
to sell some units by motivating its own sales "counselors" to
push it, which they typically did by mis-stating what the
system offered.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Solitaire optimization
Date: Fri, 18 Jun 1999 15:48:33 GMT
On Fri, 18 Jun 1999 16:40:51 GMT, [EMAIL PROTECTED] wrote:
>When working by hand, you'd probably want to record the deck state
>periodically to make error recovery easier. I think this is true even if
>we use a new key for each message, because redoing even most of one
>message could be a pain.
This wouldn't help, you could easily make a mistake that you didn't
realize. Then you have no way of knowing if your deck is correct or
not at any given time you record the state. There is no built in
error recovery, if you make an encoding mistake your message becomes
gibberish, and the only way to check this is to encode the message
again and compare it to the first draft.
And one of the ideas behind Solitaire is that you don't keep a list
of your deck state lying around. You can use a text phrase to encode
a deck state, thus two people with access to a shared medium can get a
deck state from it on a regular basis (newspaper, tv or radio
broadcast ect.)
>If we can successfully send a new key, then we're already in sync. But
>there may be other reasons for changing keys.
Another of the ideas behind the pass phrases is that you don't carry
around the deck in a ready to code state. This, and carrying around
the state written down, would pretty much nullify any security you
would hope to gain. It would be like keeping your PGP keys on a
floppy right next to your computer with the pass phrase written on the
disk.
You need a new state for every message to be secure, and once you
encode a message there is no easy way to memorize the current state.
It would be best just to pick a new pass phrase for every message.
Johnny Bravo
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: OTP is it really ugly to use or not?
Date: Sun, 13 Jun 1999 08:48:14 GMT
Jerry Coffin wrote:
> ... The attacker doesn't attempt a brute-force
> attack on the final output, but on the generator itself.
That's misleading. "Brute-force searching" normally means
exhaustive search of the *key space*, not the output space.
Also, attacks against a PRNG-based system don't have to
proceed by a brute-force search over the PRNG parameter
space, which after all will be infeasible if there are 64
bits or more in the parameters (e.g. a 64-bit wide LFSR
where the key is used for initial fill). More clever methods
of attack are normally used by the pros; they exploit the
known (or assumed) *structure* of the encrypting system.
------------------------------
From: "Serge" <[EMAIL PROTECTED]>
Subject: Re: CAST-256 implementation (?)
Date: Sat, 19 Jun 1999 00:18:14 +0400
>Why are you using CAST
> anyways? (The only good CAST are the 64-bit block ciphers anyways).
Do you have some reason to doubt in CAST's security? This is interesting for
me.
Regards,
Serge.
------------------------------
From: [EMAIL PROTECTED] (Gergo Barany)
Subject: Re: test
Date: 18 Jun 1999 20:11:36 GMT
In article <7kbn9k$49f$[EMAIL PROTECTED]>, Erik Avat'R wrote:
>And why not post in HTML??
Not all newsreaders decode HTML. Usenet is a text medium, HTML is
considered a binary format which belongs into a binary group. You could
even try to dig up this group's charter, I'm sure it mentions what
formats are recommended for this group.
Also, HTML practically posts your article twice, thus wasting valuable
bandwidth. Those of us using ordinary phone modems lose time and money
downloading redundant information.
>If you cant read it buy yourself a new computer.....
I have a reasonably new computer, I could read HTML posts if I wanted
to. But firing up a GUI just so I can see how creative your newsreader's
programmers were is a waste of time, IMHO.
Gergo
--
New Year's Eve is the time of year when a man most feels his age, and
his wife most often reminds him to act it.
-- Webster's Unafraid Dictionary
GU d- s:+ a--- C++>$ UL+++ P>++ L+++ E>++ W+ N++ o? K- w--- !O !M !V
PS+ PE+ Y+ PGP+ t* 5+ X- R>+ tv++ b+>+++ DI+ D+ G>++ e* h! !r !y+
------------------------------
From: Horst Ossifrage <[EMAIL PROTECTED]>
Subject: Re: Slide Attack on Scott19u.zip
Date: Sun, 13 Jun 1999 02:57:41 -1000
SCOTT19U.ZIP_GUY wrote:
>
> In article <7jumfq$b1m$[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] (David Wagner) wrote:
> >In article <7jue3a$2ci0$[EMAIL PROTECTED]>,
> >SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
> >> Just what do you mean bypass the fact the first and last round
> >> are different. DO you mean your attacking a reduced version
> >> of Scott19u. I think that reduced version attack was kind of what
> >> Paul Onions did a long time ago?
> >
> >I'm not suggesting to attack a reduced version.
>
> Then you have to face the fact of the two other passes
> front and back
Slide Attack Attempt Against Scott19u.zip
The cipher is immune to the Slide Attack because it uses
a non-periodic round structure. In the paper on the Slide
Attack, on page 2, paragraph 2 it says that the attack is
"easy to prevent by destroying self-similarity of an
iterative process".
The Scott19u.zip algorism has 25 rounds: the first one
and last one are the "Paul" function, and the middle
23 rounds are the ones described in the documentation
in great detail. I forgot to put mention of the Paul
function in the documentation, and I hope that David
Scott will edit that page on xoom.com to describe those
rounds. Here is part of the C program for encryption.
(It is made non-functional for export limitations).
Notice that it uses Paul(a, i19) before and after the
loop for the 23 middle rounds:
#define EPE (23)
void
doEnce(p19 * a, un32 x)
{
/* encrypts a file using 19 bit words */
un32 iz, izz;
un32 i, j, ip, ipp, k;
un32 i19, i19s, jj;
p19 *pp19;
po19 *ppo19;
void *v;
if (x < 8) {
printf(" this method for 8 or more characters only \n");
exit(1);
}
jj = ((x%19)*8+18)/19;
i19s = ((x%19)*8)/19;
i19 = ( x/19)*8 + jj; /* length of file in 19 bit units to cover it
all*/
i19s = ( x/19)*8 + i19s; /* length of file in full use 19 bit units */
v = a;
pp19 = a;
/* snipped to make non-functional to foil export usability 6/13/99 */
pf19 = v + x;
pb19 = v + x - 8;
Paul(a, i19);
if( i19 != i19s){
pf19->a00 = 0x7ffff;
iz = geto19(ppo19, i19-1);
pf19->a00 = 0;
izz = geto19(ppo19, i19-1);
i19s += 0 == ( iz ^ izz);
;}
for (i = 0; i < EPE; i++) {
k = pb19->a00;
ip = get19(a, 0);
ipp = get19(a, 1);
k = get19( ft, 0x7ffff &(( k ^ ip) + ipp) );
puto19(k, ppo19, 0);
pf19->a00 = k;
ip = ipp;
ipp = get19( a, 2);
/* snipped to make non-functional to foil export usability 6/13/99 */
puto19(k, ppo19, 1);
pf19->a01 = k;
for( j = 2; j < i19s; j++ ){
ip = ipp;
ipp = get19( a, j+1);
k = get19( ft, 0x7ffff &(( k ^ ip) + ipp) );
puto19(k, ppo19, j);
}
ip = get19( a, j+1);
puto19(ipp, ppo19,j);
puto19(ip, ppo19,j+1);
}
Paul(a, i19);
}
In conclusion, the cryptographic algorithm Scott19u.zip
is immune to the basic Slide Attack because the rounds
are not all the same. The first round is different from
the next 23 rounds. The last round is like the first round.
Thanks to David, David, Paul, Tom, Tim, and others for
participating in this discussion. Good bye.
------------------------------
From: [EMAIL PROTECTED] (Noam E. Rikly)
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss,alt.security.scramdisk
Subject: Re: alt.security.scramdisk
Date: Fri, 18 Jun 1999 21:51:29 GMT
"Andy Jeffries" <[EMAIL PROTECTED]> wrote:
>Just to let you all know, there is now "alt.security.scramdisk" created.
And amazingly, the group is already getting spammed!
--
"Noam E. Rikly" better known as [EMAIL PROTECTED]
0123 4 56789 <- Use this key to decode my email address.
Fun & Free - http://www.5X5poker.com/
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: crack the winzip files with password
Date: 18 Jun 1999 22:07:46 GMT
><[EMAIL PROTECTED]> writes:
>How to crack the winzip files w/ password faster? Or where can find the
>information of zip 2.0 encryption format?
Mount a known-plaintext attack. For info
on the format see the Kocher/Biham paper,
also Conrad's source code for the implementation.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Questions for David A. Scott
Date: Fri, 18 Jun 1999 23:01:15 GMT
In article <7ke2ue$ok4$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>David A. Scott,
>
>Optimal Block Cipher("OBC")=a block cipher for which it is impossible
>to determine the key in less time than it would take for a naive brute
>force search of the key space. An OSBC is specified by two parameters
>form OSBC(key length in bits, block size in bits).
>Secure=it is computationally infeasable to determine the corresponding
>plaintext for a specified ciphertext
I feel honored Mr Lordcow that you would go to the trouble to write
all this. I hope I am guessing that some how by OBC and OSBC that
they are sort of the same thing if not you may have to write again.
But to start off with I am not sure OBC really exist for all the
combinations of block length and key size that you are suggesting
be that as it may. I will try to anwser more.
What thing that is lacking in your yes no questions is that a lot
of the security would actaully be a function of the data envovled
suppose some one want to send a secret message that was in plain
ascii to a friend. (look I am reaching but giving an example) and he
is afraid some one is going to read it so he takes each binary vaule
of the ascii message and changes each 1 to a secret symbol that
only his firend knows this symbol happens to be one block long.
He also does this with the 0 symbol. He then sends it to his
buddy using this wiz bang OBC cipher in ECB mode. A
friendly NSA agent intercepts the message and is smart enough
to notice that there are only 2 symbols in the intercepted message
(I hope this is not over estimating the NSA agents ability) but he
has no idea of the wiz bang OBC cipher that was used for the
encoding but somehow his brain maybe with the help of a super
computer the ascii pattern shows up and he decodes the message.
I hope this example anwsers most of the carfully constructed
questions you asked below.
>
>Is an OBC(128,64) secure against a private individual?
>Is an OBC(128,64) secure against a large corporation?
>Is an OBC(128,64) secure against a major government?
>Is an OBC(128,128) secure against a private individual?
>Is an OBC(128,128) secure against a large corporation?
>Is an OBC(128,128) secure against a major government?
>Is an OBC(256,128) secure against a private individual?
>Is an OBC(256,128) secure against a large corporation?
>Is an OBC(256,128) secure against a major government?
>What OBC parameters do you consider sufficient for protecting a short
>(ie. less than one block piece of information) for an indefinite period
>of time?
I am confused by this last question I feel if one is going to
use a block cipher of n bytes then n bytes should be the shortest
message.
>Assuming that an OBC(x,y) is secure, would the use of the ECB chaining
>mode compromise this security?
>Assuming that an OBC(x,y) is secure, would the use of the CBC chaining
>mode compromise this security?
>Assuming that an OBC(x,y) is secure, would the use of the CFB chaining
>mode compromise this security?
>Assuming that an OBC(x,y) is secure, would the use of the OFB chaining
>mode compromise this security?
Obviously ECB is the weakest after that I don't rember but all of the
ones mentioned above lack the error propagation property. I rembered
when first looking at the chaining methods above I thought CBC was
marginally better than the rest you mention and I was surprised that PGP did
not use this mode.
>Assuming that an OBC(x,y) is secure, would the use of your chaining
>mode compromise this security?
Yes I would use the full chaining that is in scott19u. But since most
people can't read C or at least the compilabe C I use it would be hard
for them to change to subblock sizes different from 19 bits.
I think this chaining would prevent the break that occured in example
I give above. But again I am not sure OBC exist.
>Would the use of an OBC(x,y) that is secure in the place of the Central
>Equation, using your chaining method, degrade the security of scott19u?
>
I am not sure what you mean by this since the question above covered
this but if you mean that an OBC(19,x) I am sure there must be a
value of x that leads to a better selection of S-tables than what I used.
I might have lucked out and used the best if there is a best. But may be
the optimal if one exits consisties of a smaller subset of S-tables and
since some attacks based on cycle size then maybe the best is one
of two or three cycles. For the sake of arugement if OBC(19,x) exits
one could vary x form 1 to number of bits in ((2**19))! then there ought
to be a optimal value such that your original primose of OBC being
secure and hard for the key to calculate.
>Rate each of the following ciphers on a scale of 1(lowest) to 10
>(highest) on these matters: degree of similarity to an OBC of the
>specified parameters, security against the NSA, security against
>everyone else, influence in design by the NSA, and (where applicable)
>likelihood of winning the AES.
>RC6, Rijndael, MARS, Twofish, CRYPTON, CAST, E2, Serpent, DFC, HPC,
>SAFER, LOKI, FROG, DEAL, MAGENTA, DES, 3DES, Blowfish, IDEA, scott16u,
>scott19u, and one of tomstdenis' ciphers.
>
>Thanks for your time.
>
I don't think that I can do what you want not being sure that OCB exist in
the first palce. But if they do I think I have a better shot at it than any
of the methods above since OCB(19, number of bits in ((2**19)-1)!) I hope
is nothing more than a random S-table of a single cycle like I said I don't
know and I don't think any one can show a perfect except OCB( n,(2**n)!)
this would have to be the best in the sense of a random table used then
it would obviously take the longest time to do a reconstuction of the key
but even that may not be secure in the sense you described since the
data itself is a big part of the problem.
Know for a further look at this again assuming OCB exits in the first place
I would assume that OCB( N, K) is better than OCB ( M,K) if N > M
if this is ture then if the messages are of many blocks and one using
an NSA approved AES cipher with no error propagating then one
is still stuck with the original OCB(N,K) that was used for a single
block but if one is using my chaining then one gets closes to a
OCB( file lenght, K) which is better since no plaintext ciphertext
pairs are available for analysus like in the normal chaining. It is best
to chain so that no such pairs can be available to help in an attack
that means treat the whole file as a block something the AES NSA
thing will not do.
Also if I had to guess I would guess the NSA would pick Twofish
since it is American but that is only a guess. But I feel confident
that the winner what it will be will be one the NSA has no trouble
breaking. I am not good enough to know which of them are the
entries that the NSA would allow to win. At this stage of the
game it is quite possible they are all break able by the NSA
since I am not sure they would reach the light of day if the NSA
had any fears. It would be more fun to look at the methods that
where sent it that may have been rejected for bad style or whatever.
But again this is only my guess. But if the comitte could not
understand it or some other minor reason it would get rejected
Oh I am sure some where rejected for being weak and those
they may show off to me fair. But I would be more interested
in the ones they don't want to talk about.
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
------------------------------
** 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
******************************
