Cryptography-Digest Digest #64, Volume #11 Mon, 7 Feb 00 15:13:01 EST
Contents:
Re: is signing a signature with RSA risky? (Anton Stiglic)
Re: question about PKI... (Anne & Lynn Wheeler)
Decryption info/sites ("*.Kukard")
How secure is IDEA ? ([EMAIL PROTECTED])
Re: How secure is IDEA ? (Bob Silverman)
Re: Factorization (Bob Silverman)
Re: Factorization (Mark VandeWettering)
Re: NSA opens up to US News (wtshaw)
How secure is this method? (Erik)
Re: How secure is this method? (Sandy Harris)
Re: Does the NSA have ALL Possible PGP keys? (Michael Wojcik)
Re: Suitable hash for this application - in the public domain? ("Michael Scott")
Re: NSA opens up to US News (wtshaw)
Re: Prior art in science (Paul Koning)
Re: Random-Width Transposition Tables? (wtshaw)
Re: permission to do crypto research (wtshaw)
Re: Strip Security (Michael Wojcik)
Re: Maybe a simple question (wtshaw)
Re: NIST, AES at RSA conference (David Wagner)
----------------------------------------------------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: is signing a signature with RSA risky?
Date: Mon, 07 Feb 2000 12:04:27 -0500
==============4E55E9709DA89044417633C1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tim Tyler wrote:
> Anton Stiglic <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote:
>
> :> A compressor with an accurate model of the data will not just make it more
> :> difficult to detect a correct message from an incorrect one, it can make
> :> it *massively* more difficult.
>
> : Not true at all. If a compressor is used, the attacker will probably have
> : his hands on it, it won't complicate stuff much for him at all!
> : This is what people tend to forget...
>
> No - this is wrong.
>
> If the compressor has a sufficiently accurate model of the target
> messages, *all* possible decrypted files will be likely to decompress to
> plausible-looking messages.
>
> When I write this people often seem to object that such a compressor
> is not known for text messages. However, compression schemes based on
> numbering common messages can work pretty well for some applications.
>
> It matters not one iota that the attacker also has access to the
> decompressor.
>
> Compression *can* make finding halting criteria harder.
>
No, it does not make it any harder. The attacker just tries to decrypt to some
plaintext p', then decompresses that, call the result p, and checks if p has the
headeras he is looking for.
>
> With a good enough compressor a halting criteria - short of testing the
> integrity of the message in the real world - becomes well nigh impossible.
> --
>
It makes no difference if the compresser is good or not!
Anton
==============4E55E9709DA89044417633C1
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Tim Tyler wrote:
<blockquote TYPE=CITE>Anton Stiglic <[EMAIL PROTECTED]> wrote:
<br>: Tim Tyler wrote:
<p>:> A compressor with an accurate model of the data will not just make
it more
<br>:> difficult to detect a correct message from an incorrect one, it
can make
<br>:> it *massively* more difficult.
<p>: Not true at all. If a compressor is used, the attacker will
probably have
<br>: his hands on it, it won't complicate stuff much for him at all!
<br>: This is what people tend to forget...
<p>No - this is wrong.
<p>If the compressor has a sufficiently accurate model of the target
<br>messages, *all* possible decrypted files will be likely to decompress
to
<br>plausible-looking messages.
<p>When I write this people often seem to object that such a compressor
<br>is not known for text messages. However, compression schemes
based on
<br>numbering common messages can work pretty well for some applications.
<p>It matters not one iota that the attacker also has access to the
<br>decompressor.
<p>Compression *can* make finding halting criteria harder.
<br> </blockquote>
No, it does not make it any harder. The attacker just tries to decrypt
to some
<br>plaintext p', then decompresses that, call the result p, and checks
if p has the
<br>headeras he is looking for.
<br>
<blockquote TYPE=CITE>
<br>With a good enough compressor a halting criteria - short of testing
the
<br>integrity of the message in the real world - becomes well nigh impossible.
<br>--
<br> </blockquote>
It makes no difference if the compresser is good or not!
<p>Anton
<pre></pre>
</html>
==============4E55E9709DA89044417633C1==
------------------------------
Subject: Re: question about PKI...
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Mon, 07 Feb 2000 17:13:16 GMT
[EMAIL PROTECTED] (Palmpalmpalm) writes:
> Hi, does anybody kindly answer my question?
>
> What method does the PKI product provide for mobile users?
> When users move to another computer, do they have to bring their own private
> key and certificate always?
>
> Thanks in advance.
mobile software versions can be as simple as a floppy disk that can
copies private keys from one PC to another PC.
some forms of digital signatures strive for showing only a single
person has access to the use of the private key. demonstrating this
can require showing that nobody else had access &/or could have copied
the private key. One way for achieving this goal is an environment
where the private key is encapsulated inside a hardware token and it
is extremely difficult for anybody (even the hardware token owner) to
directly access the private key (the hardware token uses the private
key for digital signing ... but there is no function for reading the
private key; showing that nobody has direct access to the private key
is superset of showing nobody else has access).
Showing that nobody can directly access the private key ... then it
reduces to trying to show that all digital signatures can only be
performed when the hardware token is in their possession (modulo
tricking people into using their hardware token).
A hardware token can also be mobile & interchangeable (like a card)
that is moveable from one device to another (like between different
PCs, PDAs, & cellphones). A hardware token could also be physically
housed in a PDA or cellphone ... and when used in conjunction with a
PC ... the PC and the hardware token communicate via the PDA/cellphone
(using proximity contactless protocol, infrared, something like
"bluetooth", more traditional wireless, or even some physical adapter
connection).
One objective of the AADS (sometimes referred to as PKNI ... or public
key, no certificates) parameterized risk management is establishing
the integrity of digital signing mechanism (minimizing some of the
risk unknowns when performing authorization functions ... and/or being
able to scale the integrity compareable to the authorization
requirements). Rather than just saying that the digital signature
could have come from a hardware token ... having a high level of
confidence that the digital signature could have only originated from
a specific hardware token with verifiable integrity characteristics
(like an audit trail between the time the hardware token chip was
manufactored and the time the public/private keys were generated & the
public key was recorded).
misc. bluetooth reference:
http://www.gartner.com/public/static/hotc/hc00082960.html
http://www.bluetooth.com/
misc. aads reference:
http://www.garlic.com/~lynn/
--
Anne & Lynn Wheeler | [EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
------------------------------
From: "*.Kukard" <[EMAIL PROTECTED]>
Subject: Decryption info/sites
Date: Mon, 7 Feb 2000 19:35:29 +0200
Hey people,
I'm new to the cryptography thing and would like to know if anyone can point
me in the direction of any good encryption and decryption info or files or
docs etc.
Thanks.
------------------------------
From: [EMAIL PROTECTED]
Subject: How secure is IDEA ?
Date: Mon, 07 Feb 2000 17:25:16 GMT
Hi!
I am looking for some information which could help
me figure out the level of security IDEA provides.It
would helpful if someone can provide me with some
figures in terms of efforts needed to break the algorithm.
The information is highly needed and could be of great help.
Thanks and regards
maneesh
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: How secure is IDEA ?
Date: Mon, 07 Feb 2000 17:44:39 GMT
In article <87mv5j$rks$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hi!
>
> I am looking for some information which could help
> me figure out the level of security IDEA provides.It
> would helpful if someone can provide me with some
> figures in terms of efforts needed to break the algorithm.
> The information is highly needed and could be of great help.
It is a 128-bit symmetric algorithm designed to be resistant to
differential and linear cryptanalysis [which would require too
many plain/ciphertext pairs to be practical anyway]. Thus, the
method of attack is direct search of the keyspace.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Factorization
Date: Mon, 07 Feb 2000 17:49:15 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (NFN NMI L.) wrote:
> Hello. Would someone please run 5154228018862208512867 through a math
package
> and tell me:
> - its factors (2 primes roughly the same size - RSA, you guessed it)
I ran it 20 times using my own ECM implementation on the PII/450
on my desk.
Mean time to succeed: .32 seconds, the variance was .078
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mark VandeWettering <[EMAIL PROTECTED]>
Subject: Re: Factorization
Date: Mon, 07 Feb 2000 09:44:57 -0800
JPeschel wrote:
>
> [EMAIL PROTECTED] writes:
>
> >Would someone please run 5154228018862208512867 through a math package
> >and tell me:
> >- its factors (2 primes roughly the same size - RSA, you guessed it)
> >- the name of the math package (any will do, Mathematica, whatever)
> >- how long the factorization took
> >- what system, roughly, it was run on (P2 400Mhz, say)
>
> PRIME FACTOR 287895462580028491
> PRIME FACTOR 5832864341798915401
>
> Took about a second on P-450 using MPQS
The first thing I noticed was that the number to be factored ended in 7,
while
both your numbers end in a 1. Also, the two numbers you gave are well
over
half as long as the number to be factored. Seems like that can't be
right... :-)
"It got the wrong answer, but REALLY fast!"
>
> Joe
>
> __________________________________________
>
> Joe Peschel
> D.O.E. SysWorks
> http://members.aol.com/jpeschel/index.htm
> __________________________________________
--
Mark T. VandeWettering Telescope Information (and more)
Email: <[EMAIL PROTECTED]> http://www.idle.com/~markv/
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: NSA opens up to US News
Date: Mon, 07 Feb 2000 11:40:19 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> On Sun, 06 Feb 2000 22:46:50 -0600, [EMAIL PROTECTED] (wtshaw) wrote,
> in part:
>
> >Converting binary data to letters is not particularily difficult; I
> >already have anounced examples of Onega, 64 to 38, and Santa Maria, 64 to
> >27.
>
> Of course, if your cipher machine has only 26 keys...
>
> However, one doesn't need to use my full-blown 47 bit to 10 letter
> conversion plan; converting 14 bits to three letters is simpler, and
> efficient enough for most practical use.
>
The process of encoding for many into fewer characters is be exemplefied
by the method of entering letters through a diigital touchtone pad; you
get the most out of such by using two storkes per letter to identify the
base key for each letter and the position in that group of letters;
missing characters are easily handled as well.
For that matter, there is nothing to keep data from any source, which
could be ciphertext, from being reduced to 10 digits, which could entered
by hand or automatically.
--
A big-endian and a little-endian have been spotted sitting at a
campfire nibling on bytes and pointing at each other as they
argued about who got hit with the most errors.
------------------------------
From: Erik <[EMAIL PROTECTED]>
Subject: How secure is this method?
Date: Mon, 07 Feb 2000 13:26:15 -0500
I'm writing an application that needs to send an encrypted stream of
data using a shared key. My idea was to have the key be a seed to a
random number generator, and simply xor the data stream with a stream of
pseudo-random bytes. How secure is this method, and is the linear
congruence algorithm sufficient for this purpose? If not, what's a
better pseudo-random number algorithm? Thanks.
Erik
------------------------------
From: [EMAIL PROTECTED] (Sandy Harris)
Subject: Re: How secure is this method?
Date: 7 Feb 2000 18:49:05 GMT
[EMAIL PROTECTED] (Erik) spake thus:
>I'm writing an application that needs to send an encrypted stream of
>data using a shared key. My idea was to have the key be a seed to a
>random number generator, and simply xor the data stream with a stream of
>pseudo-random bytes.
This is a standard technique called stream cipher.
>How secure is this method,
Depends on the strength of your random number generator. It could be
breakable with pencil and paper, or effectively unbreakable, or anywhere
between.
>and is the linear congruence algorithm sufficient for this purpose?
Absolutely not, even if you combine outputs from several of them.
>If not, what's a better pseudo-random number algorithm? Thanks.
Schneier's "Applied Cryptography" discusses stream cipher design in
some detail. Look there.
------------------------------
From: [EMAIL PROTECTED] (Michael Wojcik)
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: 7 Feb 2000 17:57:56 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Dan Day) writes:
> On 02 Feb 2000 09:19:28 EST, [EMAIL PROTECTED] (Guy Macon) wrote:
> >Clearly I can do the same with the number that I make
> >out of the sum of all PGP keys. Let's call it "PBN"
> >(Pretty Big Number). The universe is too small to
> >write down PBN in binary, decimal, or hex, but you
> >can write down PBN in base PBN with ease. it's "10".
> And what do you do when someone comes along and
> asks, "what number base was that, again?"
Determining PBN is left as an exercise for the reader. All the hard
conceptual work has been done; this is just an implementation issue.
(Of course, if the question is posted on Usenet, you can just call
the questioner a clueless newbie and move on.)
--
Michael Wojcik [EMAIL PROTECTED]
AAI Development, MERANT (block capitals are a company mandate)
Department of English, Miami University
Shakespeare writes bombast and knows it; Mr Thomas writes bombast and
doesn't. That is the difference. -- Geoffrey Johnson
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: Suitable hash for this application - in the public domain?
Date: Mon, 7 Feb 2000 18:51:59 -0000
"David A Molnar" <[EMAIL PROTECTED]> wrote in message
news:87dbc8$8aq$[EMAIL PROTECTED]...
> Michael Scott <[EMAIL PROTECTED]> wrote:
> > Funny you should say that. I was just browsing yesterday through the
journal
> > Electronic Letters in the library, and there was an article describing
what
> > seemd to be a quite damaging attack on Haval. No more details to hand.
>
> When you can, would you please post the issue the attack was in?
>
"Cryptanalysis of Reduced Version of HAVAL", Kasselman & Penzhorn,
Electronics letters, Vol. 36, No. 1, January 2000, pp30-31
The attack is analagous to that which "did for" MD4. The three-round version
is particularly vulnerable.
Like many successfully attacked crypto-algorithms you couldn't really say it
was "broken" as such, rather holed just above the water-line. Its enough I
think to kill it though.
Mike Scott
> Thanks,
> -David
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: NSA opens up to US News
Date: Mon, 07 Feb 2000 12:07:34 -0600
In article <[EMAIL PROTECTED]>, Terje Mathisen
<[EMAIL PROTECTED]> wrote:
> If you feel this is wasting too much bandwidth, 12 chars gives 56.4053
> bits, i.e. 7 bytes, with less than 0.06 bits wasted per character.
>
When seeking computational efficiency, bits may not be the best option at
all, even as your suggestions are worth noting.
I also note that I did pick a wrong example, not noting that Santa Maria
is 27 to 64, not the other way around. Of course, there are examples that
do fit, but haven't gotten around to implementing them yet; I prefer to
talk about things I have already made to work, real ciphers that work
seem....well, real. BTW, Santa Maria is via doits, base twelve
information units, no bits involved.
--
A big-endian and a little-endian have been spotted sitting at a
campfire nibling on bytes and pointing at each other as they
argued about who got hit with the most errors.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Prior art in science
Date: Mon, 07 Feb 2000 13:12:11 -0500
Mok-Kong Shen wrote:
>
> The issue of 'prior art' is not only relevant in patent applications
> but also of interest by itself in general in science, I suppose.
> Recently in a thread it has been pointed out that what has been
> published in newsgroups and similar forums possibly may not
> qualify as 'prior art' because of limited possibilities of being
> found in searches.
That's nonsense.
First of all, of course you can find it in searches. But
whether or not it's easy to find doesn't change whether it
is "prior art".
The patent office may not spot it, of course; these days,
almost anything seems to be accepted as a valid patent application,
in spite of the "non-obvious and novel" requirement. :-(
paul
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Random-Width Transposition Tables?
Date: Mon, 07 Feb 2000 12:45:06 -0600
In article <87lrra$u7h$[EMAIL PROTECTED]>, "r.e.s."
<[EMAIL PROTECTED]> wrote:
> "John Savard" <[EMAIL PROTECTED]> wrote ...
...
> : Yes. If one knows, for a simple columnar transposition, the length of
> : the key, then one can immediately know the size of the "chunks" to
> : divide the plaintext into to form the columns which were read out of
> : the block (the only thing one doesn't know is which chunks contain one
> : extra odd letter).
>
> The case of a simple "row-wise fill" seems clear enough, but if more
> complex transposition is used (e.g. "patterned fills" etc) it's not
> so obvious to me. But if such cases do benefit from randomizing the
> number of columns over a range [lo,hi], I still wonder how one might
> go about determining the most advantageous values for lo & hi. (?)
>
It is simply a manner of method. I recently did something simple which
demonstrates this regarding columnar transposition: The ACA differentiates
between complete columnar transposition and incomplete columnar
transposition. In programong the encryption side, things are equivalent,
when you are done you are done. However, decryption seems to require
guessing column lengths, but if you know the key, there is no real
guessing, so the same program will handle either situation.
To overcome the incompleted column problem, you must try to work somewhat
like that program which does not care, only seeing the logical few
additional possibilities as just something else to be logically
considered.
--
Life is full of upturns and downturns, with varying periods of
stabilty mixed in. It is a fool's errand to assume that what is
happening any one day predicts the same as a constant future.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: talk.politics.crypto,misc.int-property,misc.legal.computing
Subject: Re: permission to do crypto research
Date: Mon, 07 Feb 2000 12:23:12 -0600
In article <87lkba$hn4$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Xcott Craver) wrote:
> wtshaw <[EMAIL PROTECTED]> wrote:
> >
> >You simply structure the quiery appropriately, like "Let me know if you
> >have any objection my studying how such and such program works."
> >
> >No comment, then you have the freedom to study how everything works,
> >including using any tools to assist you in that pursuit.
> ^^^^^^^^^^^^^^^
>
> Not quite. *Distributing* programs to circumvent a copyright
> protection measure is flat-out against this law, with no
> research exemptions. Thus, you might have permission to *use*
> tools that try to crack copy protection mechanisms, but will you
> be able to download or buy those tools?
Your presumption is that it is wrong to study any code. I herein bestow
all right to study anything mechanism I use to make any algorithm work to
any one who whats to to. Now, don't say that people are forbidden to
acquire useful tools to do what I said that, at least in my case, is legit
for them to do.
>
> I'm sure you'll be able to obtain debuggers, or other general
> purpose tools which _could_ be used for circumvention, but there
> are also very special-purpose attack programs used by researchers,
> like Fabien Petitcolas's StirMark, a program which subtly warps
> an image with the intended purpose of misaligning any digital
> watermarks hidden inside.
>
> I should check to see if there are any standard tools for
> jiggling watermarks out of video files; I'm sure that any such
> tools would be seriously frowned upon by the MPAA.
>
The problem with banning software is essentially the same as banning
pictures for whatever reason, that you pretend that whatever people will
do is harmful to you in all respects, whether it is to them or not. This
is miserably backwards thinking.
For instance, your last case, a person might wish to destroy their own
watermarks so as to render an image *virgin.* The MPAA might not like
it, but it is none of their business.
--
Life is full of upturns and downturns, with varying periods of
stabilty mixed in. It is a fool's errand to assume that what is
happening any one day predicts the same as a constant future.
------------------------------
From: [EMAIL PROTECTED] (Michael Wojcik)
Crossposted-To: comp.sys.palmtops.pilot,alt.comp.sys.palmtops.pilot,comp.sys.handhelds
Subject: Re: Strip Security
Date: 7 Feb 2000 18:41:50 GMT
Reply-To: [EMAIL PROTECTED]
[Followups set to sci.crypt]
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Gordon Walker) writes:
> On Fri, 04 Feb 2000 11:09:28 GMT, [EMAIL PROTECTED]
> (Highdesertman) wrote:
>
> >One of the things that has always nagged at me in my quicken online
> >banking, is the fact that the RSA encryption used to secure the
> >internet connection with the quicken processing center limits the
> >password to a four digit numeric combination. In my way of thinking,
> >very easy to crack. Unless of course, there is some magic that quicken
> >is doing to exponenetially increase the security of that PIN number.
The length of the passphrase, and other conditions on it (such as
the minimal character set employed), are actually up to the Quicken
server. It's your bank that's limiting you to a four-digit code.
I've seen Quicken online banking accounts that restricted the passcode
to four digits, and others that required at least eight characters
with at least some letters and some non-letters. Complain to your
bank - they're the idiots. (Of course, Intuit isn't guiltless either,
since they allow banks to configure their servers to use weak pass-
phrases.) Maybe Bruce would like to send Intuit to the Crypto-Gram
Doghouse?
Ironically, in one of the four-digit cases the bank in question used
six-digit PINs for its ATM cards. Put a marginally heavier latch on
the barn door, then cut a big hole in the wall.
> Frankly I would consider that worrying. Mathemically there is no way
> to get more than 10,000 combinations out of four digits. Just cannot
> be done. Unless that four digit PIN just unlocks a locally stored key
> created by a cryptographically secure random number generator I
> personally would not let that thing anywhere near my money.
There doesn't appear to be any locally stored key, and there's no
evidence during account creation that Quicken is gathering entropy
for a crypto-secure PRNG. Actually, I can't see any way there could
be a hidden key: Quicken can be installed on another computer and
the account access enabled from there with only the four-digit
passphrase. There's no mechanism for transporting a hidden key.
To rephrase Gordon's (correct) response: no "magic" is possible. If
the client (Quicken) only requires four digits from the user, then an
attacker only has to try 10000 combinations to brute-force it. Any
attacker can get a copy of Quicken, so it makes no difference what it
might be doing under the covers (barring passphrase-unlocks-longer-
key protocols, which don't appear to be in use). Alice creates her
on-line access; Bob fires up his copy of Quicken, enters Alice's
account information (trivial to obtain in many circumstances), then
automates connecting to the bank (not difficult even under Windows)
and brute-forcing the PIN.
Hopefully, Quicken servers lock account access after a certain (small)
number of access failures, which makes this kind of brute forcing
impractical.
--
Michael Wojcik [EMAIL PROTECTED]
AAI Development, MERANT (block capitals are a company mandate)
Department of English, Miami University
But I still wouldn't count out the monkey - modern novelists being as
unpredictable as they are at times. -- Marilyn J. Miller
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Maybe a simple question
Date: Mon, 07 Feb 2000 12:34:24 -0600
In article <3Gsn4.16103$[EMAIL PROTECTED]>, "Dave VanHorn"
<[EMAIL PROTECTED]> wrote:
> > How secure do you need it?
>
> Well, I was thinkging on that.
>
> Credit card numbers all have relatively few digits, and the account range
> tables (which limit your choices) are publicly known, so I guess it's plenty
> secure. Someone could conceivably run every possible number against the
> hash, and come up with a match eventually..
>
> In my application, they would then have the genuine credit card number used
> by someone to secure a dialup account where they sent a ton of spam, or
> otherwise abused the net. IOW, the card number (probably stolen or forged)
> of a scumbag.
>
Here is a classic case, and I know from a participant that it was an
actual case, where a number scheme was solved. LE frowned on the ability
which was developed as part of a formal research project at an institution
of higher learning to discover if the algorithm for generating credit card
numbers, in that case, was any good...which it wasn't. They were more
afraid that the fairly hollow scheme would be made available than
punishing those that had learned more than they should have.
The truth is that efficient schemes are possible that do not rely on
threats for their innate strength, so why not do things that way to start
with. The skinny on that is that some fear that the technology to do
things really securely will also affect their abilities to defeat it,
which they might not.
--
Life is full of upturns and downturns, with varying periods of
stabilty mixed in. It is a fool's errand to assume that what is
happening any one day predicts the same as a constant future.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: NIST, AES at RSA conference
Date: 7 Feb 2000 11:31:16 -0800
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
> since no cipher can be proven secure, this is enough reason to want to
> take all the precautions one can, and to be particularly suspicious of
> a single cipher based on a single round structure.
But this line of reasoning still does not provide a satisfactory answer
to Brian Olson's question: How do you know when to stop? If lack of proof
were the only reason to triple a cipher, then there would be no end to the
tripling. After all, tripling doesn't help one whit with the problem
that we lack proofs -- there is no tripled cipher that we can prove secure,
nor can we prove that tripling increases security even the slightest bit.
In practice, I expect that the reason why we to triple ciphers is because
of subjective concerns about the security of our ciphers, not because of
the lack of proofs. (That's a fine reason, by the way -- but let's be clear
about our reasons.) The lack of proofs, IMHO, seems to be a red herring.
------------------------------
** 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
******************************
