Cryptography-Digest Digest #429, Volume #10 Mon, 18 Oct 99 23:13:05 EDT
Contents:
Re: Bruce Schneier Proves That Secure Cryptography is Impossible (Jeff Williams)
Re: Strengthening passwords against dictionary attacks (Mok-Kong Shen)
Re: Blind secure search (Mok-Kong Shen)
Re: Crypto accelerator vendors (Peter Gutmann)
Re: New Cryptography for Tomorrow's Internet (Peter Gutmann)
Re: accurate decryption (Dan Day)
Re: Announcement: Easy DES Encryption for Windows (Peter Gutmann)
Re: Bruce Schneier Proves That Secure Cryptography is Impossible (Mok-Kong Shen)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column ("Brian
Gladman")
Re: Cipher round incorporated key stretching (Mok-Kong Shen)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (John
Savard)
Re: Bruce Schneier Proves That Secure Cryptography is Impossible (Mok-Kong Shen)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Mok-Kong
Shen)
Amazon.com Crypto contest (Bruce Schneier)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Bruce
Schneier)
Re: Cipher round incorporated key stretching ("Gary")
Looking for Stegano programs (Curious Ascender)
RSA Hardware ([EMAIL PROTECTED])
plaintext/cyphertext question ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Jeff Williams)
Subject: Re: Bruce Schneier Proves That Secure Cryptography is Impossible
Date: 18 Oct 1999 20:24:55 GMT
This, I think, highlights the real point. If you really need good
security, and you know that you need it, you will (probably)
take the relevant steps and put up with the annoying administrivia
that goes along with it. If you don't really need it, unless you're
totally paranoid, you probably couldn't be bothered and won't take
the steps required to implement and maintain a decent system.
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Bruce
Schneier) writes:
|> On Mon, 18 Oct 1999 09:59:50 -0600, [EMAIL PROTECTED] (wtshaw) wrote:
|> >>
|> >Most everyone has a phone book, even us in the sticks. Pick five people
|> >that you know; remember them in some order; use their last four digits one
|> >after the other to get twenty digits; you can even insert the name of
|> >their cat or dog ahead somehow in the string. If this sounds odd, it is
|> >not near as odd a ways people can come up with to make passphases on their
|> >own.
|>
|> My mother would never, in a million years, do this. She just won't.
|> It's just too much trouble. Good idea, though.
|>
|> Bruce
|> **********************************************************************
|> Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
|> 101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
|> Free crypto newsletter. See: http://www.counterpane.com
--
Jeff Williams - Alcatel USA.
Did you know that there is enough sand
in North Africa to cover the entire
Sahara desert?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Strengthening passwords against dictionary attacks
Date: Mon, 18 Oct 1999 22:55:00 +0200
[EMAIL PROTECTED] wrote:
>
> 3. Throw away the last N bits of salt. If 16 bits are thrown away,
> 32768 hashes must be computed on the average to check a password.
> Timing tests with the fastest available password checker would give a
> practical value for N.
Allow me a question of ignorance. I assume that the hashed values
of the correct passwords are stored. If you hash with a given constant
salt (for all users), then there appears to be no value and no means
of discarding N bits, for the salt is known, I presume. Isn't it
that you append a given salt with N random bits and after hashing
forget the N random bits? Thanks in advance.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Blind secure search
Date: Mon, 18 Oct 1999 22:54:31 +0200
Jens & Hrefna wrote:
>
> 1. Alice constructs Ek(M) = C1 and sends C1 to Bob.
> 2. Bob stores C1.
> 3. Alice constructs a query for M and asks Bob to execute it (perhaps
> like Ek(Q) = C2 and asks Bob to search for C2 ? )
> 4. Bob searches C1 for the criteria from Alice and returns yes if he
> finds a match, else no.
>
> Bob does not know what Alice is searching for (he is 'blind' because he
> can't decrypt C1) but can still somehow execute the search and return
> meaningful results. I assume that Bob has full access to his computer
> (both memory and disk) so no secrets may be revealed when Bob is doing
> his search.
Would you please explain a little bit how step 4 is done? I presume
that Bob doesn't do like this:
for all Q in data base do
if Ek(Q) = C1 then return('yes') fi;
od;
return('no');
But how does he actually proceed? Thanks in advance.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Re: Crypto accelerator vendors
Date: 18 Oct 1999 20:53:26 GMT
[EMAIL PROTECTED] writes:
>Does anyone know of a web site that lists all of the major cryptography
>accelerator vendors? Or similar list of vendors and their products?
I've got a large collection at http://www.cs.auckland.ac.nz/~pgut001/links.html
(look under Security Products / Data Encryption) and it'll be even larger when
I finally upload the next update.
Peter.
------------------------------
From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Re: New Cryptography for Tomorrow's Internet
Date: 18 Oct 1999 21:12:59 GMT
Gideon Samid <[EMAIL PROTECTED]> writes:
>The message is written on the wall, on the sky, on our screens -- everywhere.
>Knowledge is
>going to be comfortably and efficiently accessible from our person as we go and move
>around. The
>WEB will become our personal data space. No walls, just encryption. It's not as big
>as e-commerce,
>it's as big as e-life.
Hmm, some novel content on those web pages - I'd like to add this to the
snake-oil section of my link farm, but I can't figure out where the oil is,
or even if there's any oil. This is one system where the participants are
going to have more to fear from the DEA than the NSA.
Peter.
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: accurate decryption
Date: Mon, 18 Oct 1999 21:35:23 GMT
On Mon, 18 Oct 1999 09:13:27 -0500, "Matt Juang" <[EMAIL PROTECTED]> wrote:
>If your encrypted message is digitally signed, since they don't know your
>private key, they cannot prove the message is sent from you. This is one of
>the basic service provided by cryptosystem: nonrepudiation of origin - the
>inability to deny the origin of a signed message. In this case, it is the
>ability to deny the origin of a message.
Yes, but the catch is that if they "produce" a plaintext that is not
signed, and claim that it came out of "your" encrypted file, the
fact that the "real" plaintext happens to be digitally signed does
you no good whatsoever!
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Re: Announcement: Easy DES Encryption for Windows
Date: 18 Oct 1999 21:25:30 GMT
Cedomir Igaly <[EMAIL PROTECTED]> writes:
>Steve Preston wrote:
>> Easycrypt offers point and click encryption, utilising the trusted and
>> robust DES algorithm. The product includes many optional features,
>... and what is more important - your data will be protected with full 56
>bits of secret key :-(
>BTW, it will be good idea to bundle your product with some book like
>"Cracking DES".
They may also want to look at some of their product names, 'cryptix' already
belongs to someone else.
Peter.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Bruce Schneier Proves That Secure Cryptography is Impossible
Date: Tue, 19 Oct 1999 00:25:35 +0200
Bill Lynch wrote:
>
> What about this:
> http://www.counterpane.com/personal-entropy.html
>
> That's a link to a paper titled, "Protecting Secret Keys with Personal
> Entropy." (Bruce Schneier is one of the authors)
>
> Here is the abstract:
> ABSTRACT: Conventional encryption technology often requires users to
> protect a secret key by selecting a password or passphrase. While a good
> passphrase will only be known to the user, it also has the flaw that it
> must be remembered exactly in order to recover the secret key. As time
> passes,
> the ability to remember the passphrase fades and the user may eventually
> lose access to the secret key. We propose a scheme whereby a user can
> protect a secret key using the ``personal entropy'' in his own life, by
> encrypting the passphrase using the answers to several personal
> questions. We
> designed the scheme so the user can forget answers to a subset of the
> questions and still recover the secret key, while an attacker must learn
> the answer
> to a large subset of the questions in order to recover the secret key.
>
> I wonder if anyone would care to comment on this type of password
> protection system.
I seems to me that this is (or at least akin to) user identification
based on challenge and response implemented in certain OS, i.e. the
server takes an active role rather than a passive one. I hope that
Mr. Schneier would like to explain.
M. K. Shen
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 18 Oct 1999 23:44:01 +0100
Bruce Schneier <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Thu, 14 Oct 1999 21:50:49 +0100, "Brian Gladman"
> <[EMAIL PROTECTED]> wrote:
> >Nearly all practical standards offer a host of options so it is quite
wrong
> >to suggest that we cannot meet most interoperability needs while also
> >meeting the need for controlled algorithm diversity - I can list a large
> >number of internet protocol standards, all of which are designed to
> >accommodate algorithm diversity.
>
> Yes, but security standards are different. IPsec is much less secure
> because of all the options it has. Complexity is security's worst
> enemy.
I agree in general but a certain amount of complexity is usually unavoidable
in meeting other requirements. Most often the need to minimise complexity
is just one more requirement that has to be balanced against other
conflicting requirements in reaching an acceptable overall solution.
I consider Twofish to be a more complex algorithm than RC6 but I don't judge
this to mean that RC6 is necessarily more secure than Twofish. There is
more to it than that.
Moreover, complexity, like beauty, is often in the eye of the beholder.
Brian Gladman
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Cipher round incorporated key stretching
Date: Tue, 19 Oct 1999 00:41:44 +0200
Gary wrote:
>
> The larger the file the less extra rounds, as the extra time taken for a
> larger file is automatically strengthening the key.
> The number of rounds must always be greater than or equal to the minimum
> recommended for the cipher.
Sorry that I don't yet fully understand. You seem to say that for
a block cipher with variable number of rounds one can asymptotically
use less number of rounds till a lower bound is reached. But
how does one go about to estimate the file size that can deliver that
lower bound? I would rather think that, since analsis could need
only to work with a few blocks, the round number should be based
on an estimate of the analyst's capability to work on one single
block and that round number should be used independent of file size.
M. K. Shen
rounds is presumably one that is enough for guaranteeing the
security of message consisting of one block
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 18 Oct 1999 22:51:15 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote, in part:
>I understand that AES is for secure communication, i.e. for preventing
>the adversary from reading one's message. Could you please elaborate
>a tiny little bit your point of using it for authentication,
>anonymity and confidentiality? Thanks in advance.
Confidentiality _is_ "preventing the adversary from reading one's
message".
Authentication and anonymity might make use of specialized algorithms,
such as public-key algorithms, but the AES could well be involved at
some stage as well.
For example, one a central system has recorded that I know a certain
secret AES key, it could authenticate me by sending me random vectors
which I am to encrypt using that key.
Kerberos provides a considerable amount of authentication, and it is
built around DES, a conventional block cipher, which could easily be
replaced by the AES.
Anonymity is preserved by maintaing the confidentiality of addressing
information, which can be done, for example, by re-encrypting blocks
with different keys as they go from node to node in a network. Again,
conventional encryption, like the AES would provide, plays an
important part in this.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Bruce Schneier Proves That Secure Cryptography is Impossible
Date: Tue, 19 Oct 1999 00:57:13 +0200
Roger Carbol wrote:
>
> My inclination towards a "solution" would be rigourous
> tiger-teaming, which carries other sorts of risks,
> mostly political.
I vaguely remember to have read a report long ago saying that
through rigorous measures of the management improvements ensued.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 19 Oct 1999 01:03:51 +0200
John Savard wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote, in part:
>
> >I understand that AES is for secure communication, i.e. for preventing
> >the adversary from reading one's message. Could you please elaborate
> >a tiny little bit your point of using it for authentication,
> >anonymity and confidentiality? Thanks in advance.
>
> Confidentiality _is_ "preventing the adversary from reading one's
> message".
>
> Authentication and anonymity might make use of specialized algorithms,
> such as public-key algorithms, but the AES could well be involved at
> some stage as well.
>
> For example, one a central system has recorded that I know a certain
> secret AES key, it could authenticate me by sending me random vectors
> which I am to encrypt using that key.
>
> Kerberos provides a considerable amount of authentication, and it is
> built around DES, a conventional block cipher, which could easily be
> replaced by the AES.
>
> Anonymity is preserved by maintaing the confidentiality of addressing
> information, which can be done, for example, by re-encrypting blocks
> with different keys as they go from node to node in a network. Again,
> conventional encryption, like the AES would provide, plays an
> important part in this.
O.K. Then in my opinion the main use of AES is in confidentiality.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Amazon.com Crypto contest
Date: Mon, 18 Oct 1999 23:25:33 GMT
FYI. I know nothing about the contest.
http://www.amazon.com/exec/obidos/subst/promotions/crypto/crypto-contest.html/ref%3Dgw%5Fm%5Fce%5Fbo%5F4/002-8211936-5204257
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 18 Oct 1999 23:38:40 GMT
On Tue, 19 Oct 1999 01:03:51 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>
>O.K. Then in my opinion the main use of AES is in confidentiality.
You will be surprised.
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: Cipher round incorporated key stretching
Date: Tue, 19 Oct 1999 00:47:00 +0100
I think the confusion is my fault by using the term block. In XTEA block it
is kinda chained in such a way that an attacker can't work on a single long
word but needs to decrypt the whole file.
Gary :-)
------------------------------
Date: 19 Oct 1999 00:52:48 -0000
From: [EMAIL PROTECTED] (Curious Ascender)
Subject: Looking for Stegano programs
Crossposted-To: alt.2600
Hi Folks,
I'm trying to locate a few stegnographic programs.
I used to have a bookmark to a repository of stego programs but it has
gone dead.
In particular, I'm trying to find a set of programs that would take a
PGP file and convert it to semi-literate English text. Another that
would strip headers off PGP files, And finally one called SecSplit
which created M-of-N secret sharing. I've tried search engines and
most come up with dead links.
Assistance appreciated. Thanx!!
~~~~~~~~~~~~~~~~~~~~~
This message was posted via one or more anonymous remailing services.
The original sender is unlogged. The address shown in the From header, if any,
is unverified and maybe wrong. - Widow Anonymous Remailer -
------------------------------
From: [EMAIL PROTECTED]
Subject: RSA Hardware
Date: Mon, 18 Oct 1999 23:47:16 GMT
Could anyone please recomend any RSA Hardware related sites, or offer
advice on implemtation of RSA in hardware.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: plaintext/cyphertext question
Date: Tue, 19 Oct 1999 00:38:12 GMT
I hope this is not a dumb question, I apologize if it is.
If I had a stream of SSL packets, and something happened (irrelevant
what) that caused a plaintext packet to go out on the SSL session,
would the plaintext data be of any attack value/aid on the previous
encrypted packets???
encrypted_packet1
encrypted_packet2
encrypted_packet3
plaintext_packet4 (<----oooops!)
I think it would not, but I am unclear on this. If there was an
accompanying "encrypted_packet4" with the "plaintext_packet4", I
understand that problem, but without accompaning cyphertext, I believe
the plaintext is useless as an attack on the encrypted packets.
Does the plaintext in packet4 (reguardless of how it happened to be
plaintext) lend any attack advantage on the previous encrypted packets?
Thanks in advance for any answers, I appreciate it. I know this is
kind of a wierd question, and security is moot at this point because
the plaintext packet is obviously in the clear. I need to understand
any risk on the previous encrypted packets though.
Michael
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
