Cryptography-Digest Digest #3, Volume #10 Fri, 6 Aug 99 23:13:03 EDT
Contents:
Re: key lengths ([EMAIL PROTECTED])
Re: AES finalists to be announced ([EMAIL PROTECTED])
Re: Need letter frequencies ("Douglas A. Gwyn")
Re: Challenge: mental authentication (John Savard)
Re: Academic vs Industrial ("Douglas A. Gwyn")
Re: key lengths ("Douglas A. Gwyn")
Re: : I AM CAVING IN TO JA... ("Thomas J. Boschloo")
Re: What is "the best" file cryptography program out there? ("Thomas J. Boschloo")
Re: About Online Banking Security ("ME")
Re: frequency of prime numbers? (Nicol So)
Re: : I AM CAVING IN TO JA... (SCOTT19U.ZIP_GUY)
Re: : I AM CAVING IN TO JA... (SCOTT19U.ZIP_GUY)
Re: AES finalists to be announced (Bauerda)
is there a Puffer-like system for dos/unix? (CrACKeD)
Re: frequency of prime numbers? (Michael)
Re: AES finalists to be announced ([EMAIL PROTECTED])
Re: Ways to steal cookies in HTTP and HTTPS (Thomas Reinke)
Re: key lengths (Jerry Coffin)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: key lengths
Date: Fri, 06 Aug 1999 23:59:18 GMT
In article <7ofnm5$u88$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> > > Now that this has been said. Can we stop assuming the strength is
> in
> > > the key length? Please?
> > >
> > Just you assumed that. Let us see you crack that message.
>
> What are you talking about? (btw proofread your posts your english is
> bad).
>
You said Can we stop assuming the strength is in the key length?
Please? But it was just you who assume that. My english is bad but so is
yours and it your langage.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: AES finalists to be announced
Date: Fri, 06 Aug 1999 23:53:03 GMT
In article <7ofn4h$tqd$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <7oflm3$sr5$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > Nonsense. If Little Tommy boy is as smarts as he thinks he is he
> would
> > crack it by hand in a few hours. But he is not. He is arrogant
> > condescending and mostly wrong. Did you not notice hes response to
the
> > first post. Look at his other post too.
>
> Did you read my post? I said posting random binaries is stupid but
> gimme the c code and I will take a look. I openly admited I wanted to
> challenge you.
>
I see you think you know more than the FROG team.
You dont need the C code you arrogant LOON. All you need is the one
cipher message. It is not tea. THAT IS WHY I POSTED IT SEPERATELY.
> You just don't get it do you? Posting random binary files does not
> constitute a challenge. How do I know you actually followed the
> algorithm?
The cipher message IS THE CHALLENGE. If you were 1/2 smart as
you think you are you would have cracked it by now. Others probly has
and THEY are LAUGHINN at you. Because its so easy. Maybe you cant un do
the encoding to get to the cipher.
>
> BTW, it's funny to note you write just like Dave Scott....
>
So what. I dont care.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Need letter frequencies
Date: Fri, 6 Aug 1999 22:28:59 GMT
Jim Gillogly wrote:
> Here's a list (least frequent first) from a fairly large corpus that
> happens to include all the digraphs for one reason or another.
If that corpus were Usenet postings, you just made them *not* the
least frequent!
The question that should be asked is, "To what use are these frequencies
to be put?" I find that many novice cryptanalysts place too much
reliance on such frequency tables. A particular piece of plaintext
(unless it is *really* huge, such as your complete Sherlock Holmes)
is unlikely to match the frequencies better than very roughly,
especially the n-gram (for n>1) frequencies.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Challenge: mental authentication
Date: Fri, 06 Aug 1999 15:29:43 GMT
"Lassi Hippel�inen" <[EMAIL PROTECTED]> wrote, in part:
>Of course the system was pretty much based on security by obscurity, but
>it worked.
So, the question remains open: can such a system be designed where a
large number of users, each of whom is not to be able to get into
another user's account, be (mechanically!) assigned a
challenge-response protocol of their own?
If we relax the conditions, and allow the user to have a piece of
paper, where no one is looking over his shoulder, but the line is
tapped, then the problem becomes easier.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Academic vs Industrial
Date: Fri, 6 Aug 1999 22:45:37 GMT
Jim Felling wrote:
> Or those algorithims could be strong. All crypto has the potential to have
> undiscovered weaknesses, but all of the mentioned algorithms have been the
> subjects of intense public scrutiny as to their quality, and no significant
> flaws have been found as of yet -- some have known weaknesses(i.e. weak keys,
> protocol issues-- such as RSA's (multiple keys, same N) ), but they all have
> had rigorous and in-depth analysis. They are as strong as any presently out
> there and the evidence for their strength is strong.
The quantity of unsuccessful analysis is no measure of anything.
Kryptos might have undergone a lot of "intense public scrutiny",
but it turned out not to be an especially strong encryption.
"Absence of knowledge is not knowledge of absence".
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: key lengths
Date: Fri, 6 Aug 1999 22:51:54 GMT
[EMAIL PROTECTED] wrote:
> Basically 64-bit keys provide personal level privacy where simple
> letters are intended as private but not life threatening. 80-bit keys
> are long enough to thwart any real dedicated attack ...
> Now that this has been said. Can we stop assuming the strength is in
> the key length? Please?
In two separate posts today, you did essentially the same thing --
categorized cryptosystem strength as a function of key length,
while also maintaining that the strength is not in the key length.
How could you possibly imagine that that settles anything about
strength and key length?
The simple fact is, having a very long key is no guarantee of
cryptosystem security. I've cracked systems with keys far
longer than any you mentioned, and I suspect Gillogly has, too.
It is true that having an excessively *short* key *is* a guarantee
of cryptosystem *in*security. But the converse of a truth isn't
always another truth.
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Subject: Re: : I AM CAVING IN TO JA...
Date: Fri, 06 Aug 1999 16:45:17 +0200
"SCOTT19U.ZIP_GUY" wrote:
>
> So I give up. I have added some useful SCRIPT to my main webpage so
> that those that have a Browser that is JavaScript capable can get some
> useful info from my site. Sorry but if you Browser is not JavaScript capable
> you may not get to see this specail advice it is for JavaSrcipt enabled
> viewers only.
Javascript seems like a bad choice.
<http://www.w3.org/Security/Faq/wwwsf7.html#Q64> You will force users to
enable a dangeous 'feature' in their browsers, possibly resulting in
installed trojans that can defeat the whole security of scottu19.zip!
Better stick with standard HTML (don't know which version). Support the
Anybrowser Campaign! <http://www.anybrowser.org/campaign/>
> Also if you stuck with microshaft browser the page will not appear the same
> as witha good Netscape version. Sorry but Netscape is better in my humble
> opinion.
Less worse would be more accurate. It has no ActiveX, but then again IE5
has no privacy invading "what's related" button.. (sorry to be off
topic)
Thomas
--
NO J(ava)Script, *NO ActiveX*. Support
<http://www.anybrowser.org/campaign>!
PGP key: http://x11.dejanews.com/getdoc.xp?AN=453727376
Email: boschloo_at_multiweb_dot_nl
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Subject: Re: What is "the best" file cryptography program out there?
Date: Fri, 06 Aug 1999 17:11:59 +0200
Bob Silverman wrote:
>
> The question is meangless without some metrics.
> Are you willing to trade easy use for better security or vice versa?
> Are you willing to trade speed of encryption for more security? At
> what point does the code become too slow? etc. etc. Clealry
> RSA with a 10000 bit key would provide impressive security.
> But it would be slow. Contrawise, RC5 with a 40-bit key would
> be very fast. But it would be insecure.
>
> How long do you need your data to be secure? How much is it
> worth? etc. etc.
Oh please, can I ask that very same question? I would be more than happy
with a rough estimate! (And perhaps a few other lurkers) ;-)
> What do you mean by "BEST"?? Define your parameters!
I want the data to be secure for a lifetime (106 years = maximum
lifespan of a human, maybe 200, taking into acount some great medical
advances).
I want it to be secure starting at some random point in the near or far
future in a universe with about the same rules as scientists understand
for our universe now.
My data is worth my life, the buget for a computer would only be limited
by the number of particals in our solar system (without upsetting the
orbits of our planets to much) and this machine may take any number of
eons to construct and plug in.
I think 170 bits would definitely be enough (calculated that myself with
some highschool math in
<http://x23.deja.com/[ST_rn=ps]/getdoc.xp?AN=397603286>, don't bother to
read it), whilst I could perhaps imagine a machine that would crack 128
bits (not too sure about this).
Do you guys have any believes on these key lenghts? (yes, *strong*
crypto that can only be brute forced, or whatever)
Thanks, I hope this is no stupid question.. (but I feel it may be)
Thomas
--
Email: boschloo_at_multiweb_dot_nl
------------------------------
From: "ME" <[EMAIL PROTECTED]>
Subject: Re: About Online Banking Security
Date: Sat, 7 Aug 1999 10:10:30 +1000
Because of the back doors, little effective security exists.
During the transmisstion of a transaction, password _after_ leaving your
machine (or the originating server), reasonably security exists.
Now, all you have to do is know what was the originating server, and were
there intermediate servers reading the plain text due to SSL spoofing.
SSL is getting worse at that all the time, and anecdotal evidence this has
been exploited for financial gain.
Lyal
KidMo84 wrote in message <[EMAIL PROTECTED]>...
>I am not trying to compare it to atm's, i am just asking, does it have
>resonable security for reviewing checking information and that type of
stuff.
>
>I know atm's are more security, though like anythin there is an easy
bypass,
>steeling the pin and card. Just like somebody mentioned with the computer
>cookies. And the hardest thing is somebody reproducing the site with a
storage
>on the username and id.
>
>I know there are backdoors to alot of stuff. I just want to know if it is
>reasonable secure.
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: frequency of prime numbers?
Date: Fri, 06 Aug 1999 20:57:47 -0400
Bob Silverman wrote:
>
> [Commentary by several individuals, including Bob Silverman, on the
> correctness of Jim Gillogly's presentation of a proof that there are
> infinitely many prime numbers]
Jim Gillogly's proof is correct, if you fill in several steps, which
many may consider too obvious to have to spell out.
When I mentally filled in the missing steps, I obtained a different line
of reasoning than what Bob Silverman was objecting to.
Among the obvious statements omitted:
1. If a number is not prime, it is divisible by some prime other than
itself.
2. The hypothesis that we want to disproof asserts that there are only
finitely many prime numbers, if a number N is not divisible by any of
the (finitely many) prime numbers, it is not divisible by ANY prime
number. (By our hypothesis, the finite collection is all the prime
numbers there is).
Note that the proof technique used was reductio ad absurdum, so it is
only to be expected that some of the (intermediate or final) statements
in the proof are false.
Nicol
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: : I AM CAVING IN TO JA...
Date: Sat, 07 Aug 1999 02:19:26 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>"Thomas J. Boschloo" wrote:
>>Support the Anybrowser Campaign! <http://www.anybrowser.org/campaign/>
>
>I second the motion.
>
>Unless the purpose of your Web page is significantly furthered
>by using multimedia, programmable applets, etc. the best thing
>is to keep it clean and simple. There are even some Lynx users
>out there, for example blind persons, or just people who can't
>stand how long it takes to download all the graphics, audio,
>etc. one finds on many Web pages.
>
>If you want television, you know where to find it.
Actually I am a Lynx user so don't throe a hissy it can
handle my code. It just doesn't get the nice graphics. As
a matter of fact MicroShaft does not get the same video
affects either.
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: : I AM CAVING IN TO JA...
Date: Sat, 07 Aug 1999 02:15:48 GMT
In article <[EMAIL PROTECTED]>, "Thomas J. Boschloo" <[EMAIL PROTECTED]> wrote:
>"SCOTT19U.ZIP_GUY" wrote:
>>
>> So I give up. I have added some useful SCRIPT to my main webpage so
>> that those that have a Browser that is JavaScript capable can get some
>> useful info from my site. Sorry but if you Browser is not JavaScript capable
>> you may not get to see this specail advice it is for JavaSrcipt enabled
>> viewers only.
>
>Javascript seems like a bad choice.
><http://www.w3.org/Security/Faq/wwwsf7.html#Q64> You will force users to
>enable a dangeous 'feature' in their browsers, possibly resulting in
>installed trojans that can defeat the whole security of scottu19.zip!
>Better stick with standard HTML (don't know which version). Support the
>Anybrowser Campaign! <http://www.anybrowser.org/campaign/>
>
Again I see someone bitching that has not even been to my site
lately. I am sorry I felt compelled to keep up with all the sites that
say "sorry but you must have Java nad/or JavaScript enabled" even
though there seems to be no dam reason for it.
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] (Bauerda)
Subject: Re: AES finalists to be announced
Date: 07 Aug 1999 01:16:51 GMT
>My guess is that MARS won't make it because it has no big wins over
>RC6, and it's more complex and not based on a fielded design, and E2
>won't make it because it doesn't have any big wins over any of them.
>That leaves these three:
>
>RC6: incredible simplicity, blinding performance, impressive mixing
>CAST-256: based on well-understood and widely respected design
>Serpent: conservative design and very attractive security analysis.
>
>There's my guess: Twofish, Rijndael, RC6, CAST-256, Serpent. Any
>other guesses?
>
E2, Mars, RC6, Rijndael, Twofish. Of these, Rijndael is my favorite. While
Mars and E2 may somewhat complicated, they also appear well constructed.
CAST-256 is nice, but slower than the others. Serpent would rank lower than
CAST-256 on my list. For some reason, I appear to be one of the few people not
to include Serpent on my list. While Serpent shows a creative design (to get
speed), it is still more than twice as slow as the speediest ciphers. Lars
Knudsen has listed his three favorite candidates as RC6 with 32 rounds,
Rijndael with 16 rounds, and Serpent. Of these, Serpent is still the slowest
by a significant margin.
David Bauer
------------------------------
From: CrACKeD <[EMAIL PROTECTED]>
Subject: is there a Puffer-like system for dos/unix?
Date: 7 Aug 1999 01:17:38 GMT
i've been searching for a blowfish alternative to PGP, and came accross
the semi-popular Puffer software. but unfortunately this windows-only
software isn't much good for someone running dos and unix (linux). the
author of the software had no suggestions, but recommended i ask here.
so is there a public-key blowfish system for either dos or unix?
--
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
------------------------------
From: Michael <[EMAIL PROTECTED]>
Subject: Re: frequency of prime numbers?
Date: Fri, 06 Aug 1999 21:23:38 -0400
Sniggerfardimungus wrote:
>
> I ask this question here not because it necessarily relates to cryptography,
> but to an interest of cryptographers, prime numbers; is there any reason to
> believe that there are either a finite or an infinite number of primes? Even
> better, is there any proof either way?
>
> thanks...
> rOn
You asked >two< questions, one of which Jim Gillogly answered nicely.
Now, the _frequency_ of primes (your subject line) ... that's quite
something else ....... and very interesting.
--
Michael
---
NOTE: Reply_To has been forged to foil SPAM.
Please reply via this NewsGroup.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: AES finalists to be announced
Date: Fri, 06 Aug 1999 22:00:31 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> [EMAIL PROTECTED] wrote, in part:
>
> > I cares. Read the charter on why.
>
> Oh, and by the way: where does it say in the charter that you can post
> *binaries* to this newsgroup?
>
Where does it say in the charter that you cannot post
*binaries* to this newsgroup? Other posts have.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Thomas Reinke <[EMAIL PROTECTED]>
Crossposted-To: comp.infosystems.www.misc,comp.security.misc
Subject: Re: Ways to steal cookies in HTTP and HTTPS
Date: Sat, 07 Aug 1999 02:22:15 GMT
>
> > The damage from getting the cookies stolen is almost entirely
> > eliminated by encrypting the cookies at the server side.
>
> Why? If a mere presentation of the cookie can be used to buy
> things, then its contents (whether encrypted data or not) are
> mostly irrelevant. It seems to me that server-side encryption
> buys you very little beyond user privacy. Server-side encryption
> by no means forces proof of ownership by the client. Therefore
> stealing such a cookie really can cause damage in an SSL
> connection where the server is strongly authenticated but the user
> is effectively anonymous.
Actually, encryption is effective providing you know how to do
it properly. In your previously discussed attacks, there is
the requirement to still go off-line and decrypt the session
data in captured in a 40 bit SSL session in order to decrypt the
contents. Whenever E-Soft has been involved with secure on-line
transactions where we have used cookies as authentication tokens,
we have
a) timestamped the cookie.
b) encrypted the cookie with triple-des
The time stamp allows us, on receipt of the cookie, to
check if it has expired. To successfully execute your
attack, if you were to listen to a 40 bit SSL session,
you would need to capture the contents, and decrypt
it within 20 minutes. If you don't decrypt it within
20 minutes, your cookie has expired, and the server
rejects it if and when it does receive it.
Unless 40 bit SSL can be broken into faster than 20
minutes, the attack fails.
Cheers, Thomas.
============================================================
Thomas Reinke Tel: (416) 460-7021
Director of Technology Fax: (416) 598-2319
E-Soft Inc. http://www.e-softinc.com
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: key lengths
Date: Fri, 6 Aug 1999 21:00:19 -0600
In article <7ofeqk$ngg$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> People like quoting big key lengths. Here are some numbers to look at
[ statistics on how long a brute-force attack on various keys takes
elided ... ]
> Now that this has been said. Can we stop assuming the strength is in
> the key length? Please?
No, not really. I think you're trying to say that beyond some
relatively key size, a brute-force attack isn't practical, and this is
true. You're probably also trying to imply that in most cases, that
size is a lot smaller than most people think, which is also certainly
true.
Nonetheless, the upper limit on the strength of a cipher depends on
the length of its key. If you use too small of a key, no matter what
else you do, the cipher will be vulnerable to attack. OTOH, it's
certainly true that above a fairly low threshold, the algorithm tends
to make more difference than the key size.
It's also worth noting that many of the better attacks typically
reduce the difficulty of an attack by a more or less fixed factor
compared to a brute-force attack on the same cipher.
This means that an attack that reduced the work involved by a factor
of, for example, 100, might be extremely damaging to a cipher with a
marginal key-size, but mean nothing against an otherwise similar
cipher with a larger key.
Since you used specific key sizes, so will I. With DES, there's
currently no attack (of which I'm aware) that's substantially better
than brute force. If you design, say, a 64-bit cipher, you've got to
ensure that you've got at least VERY close to as good of a design to
ensure that you get any extra security at all. If you got to an 80-
bit key, you can start to worry less -- if somebody finds a weakness
that gives them a 100:1 advantage, it still means little unless the
data has a very long life and the attacker has truly immense
resources.
If we go to a 128-bit key, we get the same effect, multiplied by an
even larger margin -- at this point, a weakness has to be almost
colossal before it really means anything -- unless it reduces the
strength of the cipher by a factor of at least 2^40, it'll be a long
time before it means anything at all.
IOW, assume that you decide that right now you need a cipher with a
strength a bit greater than that of DES. You could us a 64-bit key,
but if anybody finds any kind of weakness at all, chances are pretty
good that you'll have a problem.
If, OTOH, you'd start with an 80 or 128-bit key, you have to screw up
pretty badly (by comparison) before it's going to mean somebody can
decode your data.
To summarize: a larger key gives you a much larger margin for error in
your design. Even a huge key won't cover up for a terrible design,
but it's an easy step to help ensure safety with a design about which
you're less certain.
------------------------------
** 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
******************************
