Cryptography-Digest Digest #252, Volume #10 Fri, 17 Sep 99 00:13:02 EDT
Contents:
Re: Ritter's paper (SCOTT19U.ZIP_GUY)
Re: SCOTT19U.ZIP_GUY/Questions Please (SCOTT19U.ZIP_GUY)
Ocotillo paper now online (Eric Lee Green)
Re: crypto export rules changing (Patricia Gibbons)
Re: crypto export rules changing (Patricia Gibbons)
Cyrpto-sell-o ([EMAIL PROTECTED])
Re: Okay "experts," how do you do it? (SCOTT19U.ZIP_GUY)
Re: The good things about "bad" cryptography (Eric Lee Green)
Re: Okay "experts," how do you do it? (David Wagner)
Re: crypto export rules changing (David Wagner)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Ritter's paper
Date: Fri, 17 Sep 1999 03:43:26 GMT
In article <[EMAIL PROTECTED]>, Jerry Leichter <[EMAIL PROTECTED]> wrote:
>"I've made the assumption that the "utility function" we want
>to minimize is the expected amount of compromised traffic. This is
>probably an unrealistic assumption, but let's make it for the moment."
>
>Actually, I believe this is the crux of much of your disagreement with
>Mr. Ritter. You're looking at expectations - average values. For
>expections, I believe your arguments are correct.
>
>However, we must also consider what is effectively "the probability of
>ruin". If AES is broken, every message sent using it is broken, and a
>major - potentially immense - investment must be made to completely
>replace an infrastructure based on it. On the other hand, even if a
>significant fraction of Mr. Ritter's individual ciphers are broken, many
>messages remain secure - and in a reasonable design for the infra-
>structure, it's possible to eliminate the bad ciphers from future use
>without rebuilding the entire infrastructure.
>
>Another way of looking at this is that the cost function is highly
>non-linear: As long a reasonably large fraction of Mr. Ritter's ciphers
>are secure, the costs (in broken messages, in the effort needed to weed
>out ciphers that have proven to be weak) are small. The cost grows very
>rapidly beyond a certain point, where most combinations are breakable.
>The problem with an AES, of course, is that there's only one "combina-
>tion", so you get right to the extremely high cost range.
>
>Ignoring the probability of ruin is at the heart of many bad probabilis-
>tic arguments - e.g., many naive arguments about martingales, and all
>sorts of bad investment strategies in the real world.
>
>On the other hand, I think there are practical difficulties with Mr.
>Ritter's approach. Even the cryptanalytic attacks known in the public
>literature are sufficiently powerful to slice right through most simple
>designs. The ciphers that can survive *even the attacks we know about*
>are pretty rare on the ground. Where will we find a large collection of
I don't belive this. The only one's people like Wagner and Bruce talk
about are those that are bad so they can just make a flat statement about
ameture ciphers. There are many ciphers that can withstand the known
public attacks. You just have to look.
>reasonably secure ciphers to use for Mr. Ritter's scheme?
>
>Mr. Ritter likes to design parameterized families of ciphers - a
>powerful approach, and probably the only way to get a large number of
>reasonable cipher designs in hand quickly. But that opens the door to
>attacks against whole families.
>
>If the collection of ciphers to be used in this scheme is fixed up
>front, it will be subject to attack - and likely many ciphers will be
>picked off. So there will likely have to be a mechanism to add new
>ciphers to the mix. However, that opens a powerful line of attack to a
>knowledgeable opponent: He can contribute (through apparently unrelated
>3rd parties, of course) a large number of apparently very good ciphers
That is just what the AES thing is all about. Do you really think that
if a cipher that might get 90% share of the worlds encrypted traffic would
not get thier attension. With there billion of dollars per year budget do you
really think they don't have a trojan horse candidate that is not going to
win. The whole thing sounds 2 FISHY to me. Who says the NSA guys
don't have a since of humor. I bet that a BS method will win.
>that he knows how to break. Since no one will be in a position to do
>really deep analyses of many different ciphers, it's unlikely that the
>"spiked" ciphers will be found: It took many years to become convinced
>that DES doesn't have a trap door, and even today there are people who
>retain their suspicions. (Actually, an attacker of this sort wouldn't
>even have to wait for updates: He would likely be right there at the
>initiation of the system, offering up a whole load of neat-looking
>ciphers. It would require a big leap beyond the publically-known state
>of the art in cryptography to slip a trap door into a system like AES,
>which will be very closely examined by many people *and is expected to
>be really strong* - so any weakness that *is* found will immediately
>raise a red flag. On the other hand, it would be relatively easy to
>slip many subtly spiked systems into Mr. Ritter's pool, since no one
>would look at them very closely - and, besides, even if one, or many, of
>the "spikes" were found, how could you distinguish that from those
>ciphers just being weak because the person who proposed them wasn't
>quite as good at crypto as he thought?)
Jerry if you think the AES candidate will be hot. What if Ritter used it
in series with one that he thinks is strong. IF you use both methods
correctly mostly just insuring the the length of data put in each method
matches the lenght of data out and that the keys used with each are
independent. Then you can safely assume the combination will be no
weaker than the stronger of the two methods used.
> -- Jerry
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: SCOTT19U.ZIP_GUY/Questions Please
Date: Fri, 17 Sep 1999 03:47:29 GMT
In article <7rrhp6$rv8$[EMAIL PROTECTED]>, Tom St Denis <[EMAIL PROTECTED]> wrote:
>In article <7rqksg$3664$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>> In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
> wrote:
>> >tunafish wrote:
>> >> What they seem to have done is deliberaltely weeken these algorithms
>> >> by asking those who submitted to make certain modification to the
>> >> code...
>> >
>> >Oh, good grief! That's the old conspiracy theory resurrected
>> >from the early DES debate. What EVIDENCE do you have that this
>> >has occurred?
>> I don't even have evidence that the guy Mr L.H. the FBI guy with the
>> license to kill that is so certifed good at killing mothers holding babies
>> was also in Waco. But I have read articles that state he was there since
>> he did so good at Ruby Ridge. Of course the evidence if there was any
>> was destroyed unless the texas rangers can provide a link. But I think
>> he is the kind of guy the FBI uses when it has to kill woman and
>> children. But then again maybe I am all wrong. Don't take me wrong
>> I think V.H. aka D.K was a very very bad sick person.
>> If you are very well read you should be smart enough to realize there
>> was much discussion about how fast custom circuits could be made in
>> the days of DES. Just like most people have no idea how old the SR-171
>> is. Most people have no idea how good the government with its vast supply
>> of money is at building custom equipment in the old days. It is a fact
>> IBM was going to go with a 64 bit system but the NSA stepped in to
>> make it a 56 bit sytem. Why? Because a 56 bit system is can be
>> brute force searched 256 times faster. I think the old book "The Puzzle
>> Palace" covers this somewhat if your interested.
>
>Funny according to Applied Crypto (the book you hate for no reason) The
>original NBS submission from IBM had a 112 bit key ...
>
>Funny that the new AES is 128+ bits... funny stuff.
>
>Tom
Tom a lot has changed since the time DES was invented. I guess those
billions of dollars they spend every year are starting to pay off.
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: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Ocotillo paper now online
Date: Thu, 16 Sep 1999 14:14:58 -0700
Finished latex'ing it today, also ran it through latex2html.
http://www.estinc.com/~eric
To quote from the "Conclusions" portion of the paper:
"It appears that Ocotillo will satisfy our particular criteria. The only
known full compromises require root access on the machine that Ocotillo
is running upon. Since the purpose of the cryptographic
component of which Ocotillo is a part is to prevent root access on the
machine that Ocotillo is running upon, in that regard Ocotillo can be
viewed as a success. As a general-purpose PRNG, on
the other hand, Ocotillo could be considered a success only if augmented
with additional sources of entropy. It is not recommended, for example,
that unmodified Ocotillo be used as the key
generator for a personal encryption product. Augmenting its inputs with
a source of true entropy would be the only appropriate action in that
case.
"The best recommendation is that if your operating system provides
a source of true randomness such as /dev/random on Linux or FreeBSD, you
should either use that directly or use that to seed
and occasionally re-seed Ocotillo. The second-best recommendation is
that if your operating system vendor does not have a true random number
generator such as /dev/random, you should
petition them for one - a generator which burrows deep into the
internals of the OS can take advantage of far more timing events to
generate random bits. If all else fails, Ocotillo may fill your
needs - but you should carefully evaluate the predictability of its
sources of randomness and, whenever possible, feed your own randomness
into it in order to offset the impact of predictive
attacks upon the algorithm. "
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
From: Patricia Gibbons <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: crypto export rules changing
Date: Thu, 16 Sep 1999 20:04:26 -0700
Reply-To: [EMAIL PROTECTED]
Paul Rubin wrote:
>
> A big liberalization of export rules is supposed to be announced
> today, but apparently there will also be some key escrow provisions.
>
> http://www.sjmercury.com/breaking/headline1/024676.htm
Yeah.. I read the article this morning... It doesn't
look like liberalization when the end of article is
also examined, ie key escrow...
Doesn't look like anything has changed yet...
"What part of "secure communications" don't they understand"
Trish
--
Patricia E. Gibbons
Acting Chief Communications Technician
City of San Jose - ITD/communications
<http://www.qrz.com/i2.html?callsign=wa6ube&form_name=callsign>
.......................................
My Public Key is available at:
<http://pgp5.ai.mit.edu:11371/pks/lookup?op=vindex&search=0xEDECB44F>
Key ID: 0xEDECB44F
This key is RSA, NOT Diffie-Hellman !!
------------------------------
From: Patricia Gibbons <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: crypto export rules changing
Date: Thu, 16 Sep 1999 20:06:29 -0700
Reply-To: [EMAIL PROTECTED]
Paul Rubin wrote:
>
> A big liberalization of export rules is supposed to be announced
> today, but apparently there will also be some key escrow provisions.
>
> http://www.sjmercury.com/breaking/headline1/024676.htm
Actually it is like
"Freedom of the Press, as long as the Press
Provides the identity of any sources, upon
demand of the government.."
Kind of puts a "chill" on the word freedom, doesn't it! =:-o
Trish
--
Patricia E. Gibbons
Acting Chief Communications Technician
City of San Jose - ITD/communications
<http://www.qrz.com/i2.html?callsign=wa6ube&form_name=callsign>
.......................................
My Public Key is available at:
<http://pgp5.ai.mit.edu:11371/pks/lookup?op=vindex&search=0xEDECB44F>
Key ID: 0xEDECB44F
This key is RSA, NOT Diffie-Hellman !!
------------------------------
From: [EMAIL PROTECTED]
Subject: Cyrpto-sell-o
Date: Thu, 16 Sep 1999 21:12:27 -0500
I am new to the encryption scene but I was curious. If I were to come
up with a new mathamatical encryption method, how would I go about
selling this? Should I contact the NSA? Just curious.
GazanGA
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Okay "experts," how do you do it?
Date: Fri, 17 Sep 1999 03:14:50 GMT
In article <7rrlo2$830$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
>In article <[EMAIL PROTECTED]>,
>Sundial Services <[EMAIL PROTECTED]> wrote:
>> Or, to
>> put it another way, let's figure out what exactly it is that makes Bruce
>> Scheirer's opinion better than anyone else's besides the fact that he's
>> written a book.
>
>The whole point of the scientific process is that you _don't_ have
>to trust Schneier's opinion any more than anyone else's. If someone
>has a practical attack, it doesn't matter who he is, or whether he
>is an expert; we can immediately conclude that the cipher is insecure.
No that is not ture I think that you guys just publish and pat your selves
on the back. You thought your attack would make mince meat out of my
stuff my it did not. You would think that since you invented it you could test
it but you couldn't. Scott19u is better then the short block ciphers you and
your employee can write for file portection. if NOT PROVE IT unstand of lying
like you have done so in the past Mr Wagner.
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: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: The good things about "bad" cryptography
Date: Thu, 16 Sep 1999 14:44:45 -0700
jerome wrote:
> to my mind the key is not public or not, it is obvious that it is harder
> to crack a cipher without algo than the same cipher with the algo.
One thing to bear in mind is that generally the attacker will have
access to the algorithm, unless the algorithm is firmware inside a
microcontroller (perhaps inside a smartcard) and thus cannot be
accessed. But if it is a program, it must be loaded off of disk in order
to be run. If it can be loaded off of disk, it can be disassembled. If
it can be disassembled, the algorithm can be reconstructed. There are
various methods that can be used to obfuscate this reconstruction, but
in the end all that those methods succeed in doing is to make it more
expensive to do the reconstruction. A detirmined attacker can still do
it, no matter how difficult you attempt to make the job.
For that matter, even microcontrollers generally have "debug pinouts"
and could thus be attacked by someone who has the debug hardware (which,
granted, is very expensive, but which IS available).
Obviously we're not talking about attacks by random hackers here. But do
you truly believe that the NSA would lack the ability to do this kind of
reverse-engineering? If you are in a foreign country and do not want
your critical business information leaked to American companies by the
NSA, do
you truly believe that it's possible to practice "security by
obscurity"?
About all you get by attempting to hide what algorithm you're using is a
false sense of security. Any "real" attacker will a) be able to figure
out what algorithm you're using, and b) be able to find flaws in the
algorithm that you probably did not think about when you wrote it.
Unless you are the NSA and thus have hundreds of expert crypto analysts
on staff, you're much better off publishing the specifications of your
algorithm for public review. At best you will receive free publicity for
your product as it circulates the rounds. At worst, an attack will be
found only after your product is actually released... but at least you
will generally know that an attack has been found, as vs. some
intelligence agency finding an attack and keeping it secret in order to
give its home country's businesses an advantage over yours.
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Okay "experts," how do you do it?
Date: 16 Sep 1999 20:10:19 -0700
In article <7rs7s8$11u8$[EMAIL PROTECTED]>,
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
> They check to see how wrote it. If it is some one they don't know
> they say it is weak and go on since they are afraid of there own
> shadows.
Do you really believe this?
If you truly believe that your ideas are being ignored not because of
lack of technical merit but rather because of your name, there's an
easy way to prove it: submit a paper anonymously (or under a fake name)
to some respected crypto conference. If it gets accepted, you can
boast all you like about how you fooled all those evil cryptographers...
Or, post to sci.crypt via an anonymous remailer. (See www.replay.com.)
If people react differently to your post, you can claim glorious victory.
In the meantime, I fear that these types of remarks only diminish the
chances that anyone will take you seriously.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Crossposted-To: talk.politics.crypto
Subject: Re: crypto export rules changing
Date: 16 Sep 1999 20:19:19 -0700
In article <VqiE3.5630$[EMAIL PROTECTED]>,
Dmitri Alperovitch <[EMAIL PROTECTED]> wrote:
> Um. Question - if they are willing to allow open export of unlimited
> size keys (except when the destination is a terrorist state), why do they
> still want a one-time review of your application? If there is no limit on the
> size of the key you can use anymore, it shouldn't be any of their business
> about the way you algorithm works or how strong it is, right?
I've heard more than one person conjecture that the main goal of the
one-time review process is _not_ to review your product for compliance
with export rules, but rather to gather intelligence about your product.
If they have the source, they can look for buffer overruns, bad RNGs,
and all sorts of other bugs they can exploit, in case anyone ever uses
your crypto for anything interesting. And, they get a chance to ask
you to go change that magic constant in the corner over there before
you ship...
I see no easy way to confirm or refute this conjecture, but it's an
interesting hypothesis.
------------------------------
** 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
******************************
