Cryptography-Digest Digest #678, Volume #10 Fri, 3 Dec 99 22:13:01 EST
Contents:
Re: Why Aren't Virtual Dice Adequate? (Tim Tyler)
Re: ENIGMA verification ([EMAIL PROTECTED])
Re: How can you tell? (Milo Yanker)
Re: Any negative comments about Peekboo free win95/98 message encryptor (David A
Molnar)
Re: Any negative comments about Peekboo free win95/98 message encryptor (Tony L.
Svanstrom)
Re: Why Aren't Virtual Dice Adequate? (Scott Nelson)
Re: NSA should do a cryptoanalysis of AES ("Douglas A. Gwyn")
Re: NSA should do a cryptoanalysis of AES (Vernon Schryver)
Re: What part of 'You need the key to know' don't you people get? (Johnny Bravo)
Re: cookies (Yoni Kramel)
Re: NSA should do a cryptoanalysis of AES (John Savard)
Re: NSA should do a cryptoanalysis of AES, What Pi has taught us (albert)
Re: High Speed (1GBit/s) 3DES Processor (Paul Koning)
----------------------------------------------------------------------------
Crossposted-To: sci.math
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Why Aren't Virtual Dice Adequate?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 3 Dec 1999 23:41:26 GMT
In sci.crypt Johnny Bravo <[EMAIL PROTECTED]> wrote:
: On Fri, 3 Dec 1999 20:02:59 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
[snip removal of bias]
:>Other types of deviation from random behaviour are quite possible:
: As are other methods for eliminating various types of bias. You can
: get x unbiased bits from y flips if you distill them enough [...]
It does not look like we are going to reach agreement. I doubt that
you can ever get even one unbiased bit. It does not matter how many
bits you combine, or what techniques you use. Even if you were given a
large stream of bits with entropy 1.0, you would have no way of
verifying the fact.
I fear if the discussion continues in this vein, we will wander from the
relevance to cryptography.
What practical people are concerned with is whether or not it is possible
to build an OTP that's secure enough for the messages they're trying
to convey, against their real-world opponents.
While I don't think this is necessarily an easy target, I would generally
grant that it may be an attainable one, if enough energy is expended
on the problem.
Whether you can get "perfect randomness" in reality is a bit of a
philosophical issue.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Department of Redundancy Department.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: ENIGMA verification
Date: Fri, 03 Dec 1999 23:44:52 GMT
David Hamer <[EMAIL PROTECTED]> wrote:
> One well know example is to be found in the article: "The
> Turing Bombe: Was it Enough", Deavours, C.A. & Louis
> Kruh, Cryptologia XIV(4), pp 331-349, 1990.
Thanks!
I originally asked the question because I could not solve "The Code
Book"'s "Stage 8" cryptogram ... yet when I made up my own cryptograms,
I could solve them easily and quickly. So I was wondering if my
"engine" was doing the Right Thing.
However, it turns out that a few hours after I posted my original query,
I figured out the problem [my simulation was, in fact, correct], and
solved the cryptogram.
>[graphical simulators]
Yeah, I found alot of those on the web. Unfortunately, all of them
lacked a certain convenience for my application, even if they were fast
enough. The most useful information I found was, in fact, on your
web-page, filed under "Notes for people who want to make their own
simulators".
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Milo Yanker)
Subject: Re: How can you tell?
Date: Fri, 03 Dec 1999 23:52:33 GMT
John <[EMAIL PROTECTED]> wrote:
>Say you had an encrypter and no source. How would you go about
>verifying it?
I wouldn't bother. I would delete it and get one with open source.
--
"Milo Yanker" is actually [EMAIL PROTECTED] (0178 654239).
0123 456789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: Any negative comments about Peekboo free win95/98 message encryptor
Date: 3 Dec 1999 23:56:01 GMT
In sci.crypt Keith A Monahan <[EMAIL PROTECTED]> wrote:
> David,
> Thanks for the response.
No problem. Just wanted to point out that there are various axes of
"trust". and some of them are orthogonal. :-)
> problems. I always read companies' privacy/security policies online and
> they always talk about SSL encryption and blah blah. But you KNOW alot
> of these companies store your credit card info in plaintext on some
> networked NT server, or even worse, plaintext on a unix box.
Yeah. This is why SET still seems interesting to me; the idea of doing
credit card transactions (if you _must_ do credit cards) without
storing the card # anywhere is a Good Idea. Too bad that a previous
thread here suggests that it's unworkable in practice...
Re: a "security audit seal" -- who would you trust to do something
like that? and how are they going to get paid? It doesn't seem to make
sense for the vendors to pay the auditors directly...that's a nasty
conflict of interest. :-(
-David
------------------------------
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Crossposted-To: alt.security.pgp
Subject: Re: Any negative comments about Peekboo free win95/98 message encryptor
Date: Sat, 4 Dec 1999 01:12:07 +0100
David A Molnar <[EMAIL PROTECTED]> wrote:
> Yeah. This is why SET still seems interesting to me; the idea of doing
> credit card transactions (if you _must_ do credit cards) without
> storing the card # anywhere is a Good Idea. Too bad that a previous
> thread here suggests that it's unworkable in practice...
It really is useless, the idea is good, but SET sucks.
/Tony
--
/\___/\ Who would you like to read your messages today? /\___/\
\_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
--oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
DSS: 0x9363F1DB, Fp: 6EA2 618F 6D21 91D3 2D82 78A6 647F F247 9363 F1DB
---ôôô---ôôô-----------------------------------------------ôôô---ôôô---
\O/ \O/ ©1999 <http://www.svanstrom.com/?ref=news> \O/ \O/
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 04 Dec 1999 00:24:47 GMT
On 2 Dec 1999 [EMAIL PROTECTED] (Mickey McInnis) wrote:
[big snip]
>
>This is a well known and much discussed "weakness" of a one-time-pad.
>
>A properly used OTP "absolutely" prevents the enemy from determining
>the cleartext from the cyphertext by cryptographic means. It doesn't
>"absolutely" prevent him from sending a false message that looks
>real.
>
>It can also happen if the enemy can somehow "guess" the cleartext, even
>if it's only sent to one correspondent. If the enemy thinks he might
>know the text, he could try to substitute text this way and would
>send a "proper" message if he guessed right. If he gets it wrong,
>the correspondent would get garbage.
>
>There is another well-known cryptographic "weakness" in OTP and many
>other cryptosystems. Unless you pad the messages, the enemy knows the
>length of the message.
>
>I wonder if there's something analagous to an OTP that will provide
>the same degree of "absolute" protection from "spoofing" as OTP
>does from "breaking".
>
>
Spoofing can be made arbitrarily difficult, but I don't think
it can be absolute. There's always a chance that the enemy
can insert a valid but wrong message into the stream at random.
If you can send more than one valid message, so can the enemy.
If bits are sent in blocks of <large size> mixed with
a reasonable substitution cipher and padded with
known but random bits, then the odds of an enemy correctly
modifying the block is approximately 1/2^<number of pad bits>
For example, take the plain-text one bit at a time,
XOR with 1 OTP bit, pad it with 63 OTP bits, run it through
DES with a known key and then XOR the output with 64 more
OTP bits. When decoding, if any of the pad bits don't match,
discard the entire message.
Alternatively, a check value can be appended, but
note that a conventional check value of the message isn't
enough. If the enemy knows the plain-text he can recover
the OTP bits used for the check value and send any message
he likes. You need to hash the message + <enough OTP bits>
and XOR the result with more OTP bits to prevent this.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Sat, 04 Dec 1999 00:31:43 GMT
"SCOTT19U.ZIP_GUY" wrote:
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> >This points up a supremely important fact: Real computer security
> >has to be built in from the ground up, with no loopholes anywhere.
> Its amazing how often people make this statement that real
> security has to be built in from the ground up. But why when it
> comes to compression before encyption most people ignore the
> information added by most compression methods? And they
> tend to use chaining that goes out of its way not to difuse information
> through out the file. It is as if people turn there brains off in these
> areas. Any one have theorys as to why? You already know by
> theories on the subject.
That is a different issue from the one I was addressing, but:
Why don't people use iron drop-bars to secure their front doors?
The answer is, the locks they are already using are more secure
than the rest of their house, e.g. windows, so beefing up security
there doesn't really accomplish anything. Very few burglaries
occur by the door lock being picked. Once the rest of the
security system is made so good that the door lock becomes the
weakest point, *then* it make sense to augment or change the door
lock.
The "information added by compression methods" has not been
shown to facilitate cryptanalysis in *practice*, since at worst
it would be no worse than known plaintext, which every good
system needs to be immune to anyway. There is no published
description of a feasible known-plaintext attack against modern
block ciphers. Similarly for one-on-one compression, which at
best foils brute-force key searching, which should not be
feasible for any good system anyway.
The chaining modes are not *meant* to evenly disperse PT
information throughout a message; to do so would require the
entire message to be available at one time, which is often not
the case for real encrypted communication channels. The main
intention of a chaining mode like CBC is to prevent several
kinds of attack that are possible against plain ECB. You have
not shown any feasible attack against a system consisting of
an inherently strong block cipher and CBC; unless people think
there is a problem that needs solving, they won't listen to
proposed solutions.
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: NSA should do a cryptoanalysis of AES
Date: 3 Dec 1999 17:51:03 -0700
In article <[EMAIL PROTECTED]>,
Shawn Willden <[EMAIL PROTECTED]> wrote:
> ...
>Could you explain what you mean by a "capability-based" architecture? I've puzzled
>over the term a bit and I can't figure out what you mean by it. Whose capability
>and for what? And how does it relate to architecture?
It's standard computer jargon.
It's age and some early papers about it include the references listed
under "CAL TSS" in http://www.research.microsoft.com/lampson/Systems.html
When I asked www.google.com about "capability system", the seventh
hit was obviously relevant, http://www.cis.upenn.edu/~shap/EROS/hp-talk/
See in particular http://www.cis.upenn.edu/~shap/EROS/hp-talk/sld007.htm
(My shock and horror at discovering that Lampson had gone over to the
Dark Side was mitigated by observing that he seems to be physically more
than 3000 miles away from Redmond. Also, maybe he'll do some good, such
as teaching the people responsible for ActivX that authentication is not
the same as authorization....no, never mind.)
--
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Fri, 03 Dec 1999 20:32:55 GMT
On Sat, 04 Dec 1999 00:01:21 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> Actually it was one of my strionges suits mr ASSHOLE the proof
>is there but your to fukching dumb to see it.
Anyone else notice that the more he froths at the mouth the worse
his spelling becomes?
I see he put the 'g' in "fucking" like I mentioned in a prior post,
but he put the 'k' and 'c' in the incorrect order. And "fucking" does
not contain the letter 'h'.
Best Wishes,
Johnny Bravo
"I'm not even going to try to teach him to spell "strongest"."
------------------------------
From: [EMAIL PROTECTED] (Yoni Kramel)
Subject: Re: cookies
Date: Sat, 04 Dec 1999 01:48:49 GMT
[EMAIL PROTECTED] (Steve K) wrote:
>The one decent use for cookies (that I know of):
>When registered users log in to a company's site, a cookie is set that
>identifies that user as being currently logged on. Then, when moving
>from page to page inside the site-- or even from server to server in
>some cases-- a cgi program can read the cookie and grant access.
Check out my Five by Five Poker game. I use cookies to retain the state of
the game while you play, and they in no way invade anyone's privacy. It's
when cookies are stored on your hard drive and retained after you close
your browser that are the real concern. The cookies from my site never do
that.
--
"Yoni Kramel" is actually [EMAIL PROTECTED] (7348 260915).
0123 456789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Sat, 04 Dec 1999 01:34:11 GMT
On Thu, 2 Dec 1999 20:32:51 -0000, "Brian Gladman"
<[EMAIL PROTECTED]> wrote:
>NSA did reduce the key length of DES from 64 to 56 bits and many thought
>that this was so that they could break it but I very much doubt this. Given
>the technology available at the time, and their 'volume' cracking needs, I
>cannot see that this conclusion stands up under retrospective scrutiny.
>Although I do not know the answer here, I suspect what it might be. My
>guess is that NSA were breaking much poorer algorithms than DES at the time
>and desperately needed a way of convincing their targets not to move to DES.
>The key length reduction, leaving people to draw the (wrong) conclusions,
>was a masterful bit of psychological warfare that did exactly this.
>As a result of this brilliant deception I suspect that NSA targets went on
>using broken algorithms for years even though a great algorithm - DES - was
>right in front of their very eyes. And the fact that DES was strong and yet
>seemed to outsiders to be weak provided a rare occasion in which the good
>guys were able to 'have their cake and eat it' by being able to use DES for
>true protection while ensuring that the bad guys were far too suspicious of
>it to ever contemplate its use.
Although I can partly agree with you, as for some applications (i.e.
confidential medical records) a cipher needs to stay unbroken for a
hundred years, I don't believe we can get away from 56 bits being too
small a key size.
However, this flaw in DES is easily fixed.
Instead of CFB, CBC, OFB mode and so on, the following double-DES mode
would take advantage of the strength of DES, and yet allow a very
large key:
For each block that is enciphered, produce one 64-bit pseudorandom
number by means of a combination of counter mode and OFB mode. (DES
encrypt the previous output XOR the counter.)
Use the 64-bit pseudorandom number in encryption of a block as
follows:
XOR the block with one of 16 whitening vectors. (4 bits)
Perform a substitution on the eight bytes of the block, using one of
eight substitution tables for each byte. (24 bits)
XOR the block with one of 16 whitening vectors. (4 bits)
Encrypt the block using DES with a second key.
XOR the block with one of 16 whitening vectors. (4 bits)
Perform a substitution on the eight bytes of the block, using one of
eight substitution tables for each byte. (24 bits)
XOR the block with one of 16 whitening vectors. (4 bits)
This form of encryption uses the strength of DES, but also allows the
use of a very large key. DES in the middle prevents deductions from
being made about the whitening part. The whitening items being chosen
from tables prevents the pseudorandom DES output from being studied.
That no one considered such trifling strategies to vastly improve DES
must be counted as a victory for this "psychological warfare".
------------------------------
From: albert <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES, What Pi has taught us
Date: Sat, 04 Dec 1999 02:21:10 GMT
<snip>
First, I have to commend all those who made it to the finals in the AES. I
have yet to be able to design a cipher that I cannot break myself; let alone
someone more qualified. So it's not that easy.
But I don't see any of the finalists being broken "badly" if at all, nothing
like Frog or magenta.... But I do expect to see various attacks on certain
ones. But with 128bit lengths, it won't be because of brute force.... BUT I
had a discussion with a professor today, and we talked about Pi. Hardware
speed increases, and we know that and expect that, no big deal. But as seen
in Pi, it's not the hardware that makes the quantum jumps, but the math. If
there is some method of attacking a certain algorithm where the key size
increases runtime to crack it linearly instead of exponentially, then there's
a great chance to crack all these algorithms using exhaustive search. More
than likely, this would apply to all algorithms though, and so once again
sets them all on equal plane. I don't think NSA has made such breakthroughs,
and here's why:
There is something I refer to as "The Knowledge Birthday Paradox". Based on
the Birthday paradox, it goes something like this: As soon as you think of
an idea that is revolutionary, somewhere else in the world, someone at the
same moment has thought of the same thing. It happened with Calculus, with
key whitening etc..... A lot of inventions were thought up, and
independently invented somewhere else by someone else. If this holds true
for crypto, then anytime the NSA thinks up an attack, someone in the public
sector will think of the same attack as well. I know, weak theory to put my
faith in, but I think it holds true for the most part.
If we know that the NSA broke an algorithm, it would be in their best
interest to share that information; because as much resources as they have,
they cannot beat distributed knowledge. Like Linux vs NT, the development
model that will get things done fastest is still a distributed model. So I
think if there is an attack on a certain algorithm, they will share it.
What I am afraid of though is their actions might mimic their past actions
with DES. They might suggest "changes" to certain algorithms, or suggest
"changes" to all the algorithms, but not state why. That's when I get
worried. That's when they say that they have "shared" their knowledge, but
have given no reasons for it.
But somewhere deep in the back of my mind, I can't help but think they are
hiding a Bletchley Park in there...
>From WWII this is what I learned: It took the world banning together to
defeat Germany; it shows that it takes quite a huge amount of resources to
compete with someone who is bent on a certain task; as in Axis vs. Allies.
So it would take quite a bit of public resources combined to equal that of
the NSA. But as shown by WWII, it can be done.
Albert
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Crossposted-To: comp.dcom.vpn,comp.security.firewalls
Subject: Re: High Speed (1GBit/s) 3DES Processor
Date: Thu, 02 Dec 1999 10:57:12 -0500
David Kessner wrote:
>
> Paul Koning wrote:
>
> > > > 3DES at a 1 Gigabit/sec, like anti-gravity, free desalination,
> > > > non-polluting engines, and ADSL, is obviously a billion-dollar
> > > > winner. NSA can do 3DES at 1 Gigabit/WEEK with Cray computers.
> >
> > Where have you been?
> >
> > Gigabit per second was done as an R&D effort at DEC Palo Alto
> > around 1994. Today, commercial off the shelf chips do several
> > hundred megabits/second of 3Des for $100 or so.
>
> You can download a DES core for your FPGA from http://www.free-ip.com.
Thanks!
> Twelve of these cores can fit into the largest Xilinx Virtex-E FPGA,
> achieving
> a single-DES performance of 44.4 gigabits/second. Of course, you can
> wire
> them up serially to get 3DES at 1/3rd the performance-- or a "sluggish"
> 14.8 gigabits/second. All on a single chip!
Twelve? I can see how 16 cores would help if that lets you do the
16 rounds in a pipeline rather than iteratively. Or did you do that
already? If so, additional parallellism doesn't gain you anything
for single stream throughput because you can't parallelize CBC
encryption...
paul
------------------------------
** 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
******************************
