Cryptography-Digest Digest #421, Volume #10 Sun, 17 Oct 99 01:13:04 EDT
Contents:
Re: Announcement: Easy DES Encryption for Windows ("Trevor Jackson, III")
Newbie Cryptology question : is user 'key unkown' crypting possible? (Chad Hurwitz)
Re: A simple preprocessing scheme for plaintexts ([EMAIL PROTECTED])
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Mok-Kong
Shen)
Re: speed and secure level (Helger Lipmaa)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (David
Wagner)
Re: Newbie Cryptology question : is user 'key unkown' crypting possible? (Steve K)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (John
Savard)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
(DJohn37050)
Bruce Schneier Proves That Secure Cryptography is Impossible (John Savard)
Biometric Keys are Possible
Re: Bruce Schneier Proves That Secure Cryptography is Impossible (Boris Kazak)
Re: Bruce Schneier Proves That Secure Cryptography is Impossible (John Kennedy)
Re: A viable security strategy (and looking for off-the-shelf product) (Aidan
Skinner)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column ("Trevor
Jackson, III")
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column ("Trevor
Jackson, III")
----------------------------------------------------------------------------
Date: Sat, 16 Oct 1999 15:51:35 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Announcement: Easy DES Encryption for Windows
Edward Culver wrote:
> This is snake oil if I ever heard it.
>
> Steve Preston wrote:
>
> > Pcorp Associates are pleased to announce the launch of the ultimate in
> > easy to use DES cryptography for Windows.
>
> DES? Try 20 years ago...get something with a biger keysize.
>
> > Easycrypt offers point and click encryption, utilising the trusted and
>
> Trusted by who?
>
> > robust DES algorithm. The product includes many optional features,
> > including: the ability to 'remember' your last password for a
>
> Remember your last password!?!?! That's absurd...so you just store the
> password in the clear for anyone to come and look at it?
>
> > pre-definable period (saves you re-typing); file or folder encryption;
> > the ability to launch your encrypted files (decryption 'on the fly');
>
> I hope AFTER asking for a password (or do you just cache it?).
>
> > and many more.
>
> Many more what? Security flaws?
>
> > It is intended for use in any environment where confidentiality is an
> > issue (eg: a LAN, shared PC, portable PC, etc). The fact that it is so
>
> LAN??? If you would trust your network to DES encryption (ESPECIALLY in
> this product) you need a serious lashing. Shared PC? Portable PC? Yeah
> sure...if you want to keep your little sister out of your files. If you
> want real security from theifs/crackers you are going to need something A
> BIT STRONGER than this program.
>
> > simple to use should help to make the securing data assets 'business
> > as usual'.
>
> Sure, if you are actually SECURING...but you are not...you are simply
> obscuring the data.
Interesting accusation: Using DES is no longer considered a form of
insufficient security, but like a latter day substitution cipher, more a form
of obscurity due to the increasingly serious threats from advancements in
computational resources.
At what point in technology (speed of brute force search) does using DES
consitute obscurity rather than security? Are we already there?
At what point in technology will using AES candidates constitute obscurity
rather than security? Do we expect to be there within the lifetime of data
encrypted at the end of the lifetime of the cipher? (This probably isn't a
yes/no question).
------------------------------
From: [EMAIL PROTECTED] (Chad Hurwitz)
Subject: Newbie Cryptology question : is user 'key unkown' crypting possible?
Date: 16 Oct 1999 12:56:46 -0700
I have a cryptology question. I'm very new to the science and i perhaps
have a question that doesn't have an answer.
My objective is to have users use a program executable to create a data file.
The file could be sent to an authority who would securely verify that the file
was created at time X and closed at time Y. This would be determined
by two encrypted timestamps located in the file. I do not want
the user to hack their own file which was really created at time X and
closed time Y, by inserting timestamps for starting at time A and closed
at time B.
The data in the file created is always different. So if the
timestamps were encrypted with the checksum, one couldn't simply rerun
the program at another time and exchange the timestamp information into
the hacked file. Unless of course they knew the key to the encryption.
Also The authority wouldn't care about the time itself but the difference
between the times, so we can be ensure the file's creation duration was
securely passed from running the file to the authority. I just had
imagined it being a bit more secure to have two places in the file which
would need to be hacked instead of one time difference field.
I have thought about encrypting the timestamps and checksum in the program,
but it would seem the key or the key generating algorithm would be hardcoded
in the executable. I believe if the user doesn't know the key then the
system would work; But since the user has to create the file with the
program, how can we keep the secret key from the user?
Is there another encryption method used in this case, or is this an accepted
impossible transaction to "secure" since the user must have some
sort of access to the key located in the program it self? If impossible,
is there a way to make the key or key generating algorithm more secret
that is stored in the executable?
If it's easy reply to [EMAIL PROTECTED] as well as reply to this post.
thanks in advance.
--
/-------------------------------------------------------------------\
| spam if you can, spam if you dare, spam if you must, i won't care |
| spam is futile, spam is free, spam is filtered, so i won't see |
\-------------------------------------------------------------------/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: A simple preprocessing scheme for plaintexts
Date: Sat, 16 Oct 1999 21:07:50 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Plaintexts are generally such that they can be easily recognized
> as such and that they often have statistical properties that
> under circumstances could be exploited. If therefore these are
> preprocessed in appropriate ways before being processed by a
> block cipher, then certain security advantages should accrue.
Doesn't 'whitening' fix this problem? DESX style is like
C = K2 XOR (DES(P XOR K1))
Were K1 and K2 are whitening keys. The DES encryption would
use a third key, K3. Now an attack must guess both whitening keys
before any plaintext patterns could be analyzed.
I believe Rivest proposed whitening some years ago. The paper
title was like 'Strenthing DES against exhuastive search' or along
those lines.
I believe all of the AES finalist use whitening. TwoFish, Rijndeal
and RC6 definitely do.
Whitening adds only a few bits of strength with regard to linear
and differential analysis but makes brute force much harder.
The Windows 2000 EFS is using DESX.
--Matt
>
> M. K. Shen
> ---------------------------
> http://home.t-online.de/home/mok-kong.shen
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 17 Oct 1999 00:36:45 +0200
Roger Schlafly wrote:
>
> Exactly. No interoperability.
Why do you care so much about interoperability? For a specific group
of communication partners to communicate securely, it suffices that
they argree on a specific software/hardware to use. If because of
lack of interoperability some three-lettered agencicies can't
intercept their messages, that's even better, isn't it? If someone
participates in two groups with two different software/hardware, he
can acquire the necessary software/hardware, can't he? If there is
sufficient market demand, manufacturers would provide facilities
for handling messages of both groups, much like my electric razor,
which works both in Europe and in US, where the voltages are different.
The language of my mother tongue needs an entirely different computer
input system than for English or the European languages. There isn't
any interoperability possible. Do you see the point?
>
> > To those who
> > are SO SURE about modern (super) high technology being able to
> > absulutely guarantee all their needs (whether crypto or not) I like
> > to recall one single name: Titanic.
>
> Yes, that's what iterated ciphers are. Big, slow, clumsy, and
> misplaced confidence in something just because it is big, slow,
> and clumsy.
As I said, the top three candidates of the final round of AES are
in all probability almost of equal strength. If you are satisfied
with the security of the one AES winner, then use it by all means.
If you need more security, because perhaps you see a higher risk
of your applications like the financial people did in case of
triple DES, then one sensible way seems to be to use multiple
encryption using the top three candidates, because these
all have been well scrutinized by the best of the professionals
during the AES contest and no critical weakness have (yet) been
found. Of course, the multiple encryption scheme needs more
software/hardware, is bigger, slower, clumsier, ...... and what not.
But that's your tradeoff for the higher security required. There
is no free lunch in this world. Or do you happen to know someone
offering such?
M. K. Shen
==============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Helger Lipmaa <[EMAIL PROTECTED]>
Subject: Re: speed and secure level
Date: Sun, 17 Oct 1999 01:58:55 +0300
Jerry Coffin wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> > Is there a encryption faster than DES with the same secure level?
>
> Most of the AES finalists are at least believed to be substantially
> more secure than DES (though nobody can prove it) and I believe all of
> them are substantially faster than DES.
All but Serpent. See http://home.cyber.ee/helger/aes
Helger Lipmaa
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 16 Oct 1999 16:11:57 -0700
In article <[EMAIL PROTECTED]>,
Jerry Coffin <[EMAIL PROTECTED]> wrote:
> I doubt it takes more than 100 lines of code on average to implement
> the AES finalist algorithms.
In software, it's easy; in hardware, it's a huge added cost.
------------------------------
From: [EMAIL PROTECTED] (Steve K)
Subject: Re: Newbie Cryptology question : is user 'key unkown' crypting possible?
Date: Sat, 16 Oct 1999 23:32:48 GMT
On 16 Oct 1999 12:56:46 -0700, [EMAIL PROTECTED] (Chad Hurwitz)
wrote:
I'm fairly new to all this myself, but how about having your two
parties connected in near-realtime via an SSL session, during the key
generation & time stamping process?
Of course this leaves the possibility of spoofing and man in the
middle attacks open, but these are addressed extensively in the
literature, and you will probably need to include countermeasures to
them no matter what you do.
The peanut gallery has spoken.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 17 Oct 1999 01:08:34 GMT
"Roger Schlafly" <[EMAIL PROTECTED]> wrote, in part:
>DJohn37050 <[EMAIL PROTECTED]> wrote in message
>> Talk to the Irish about potato monoculture.
>You've lost me here. Is there some Irish position on potato
>standardization that I should know about? <g>
Now, now. You _should_ know your history, and about the Irish Potato
Famine caused by a potato blight, which had catastrophic results.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 17 Oct 1999 01:14:20 GMT
I think <g> means "grin" so I did not reply.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Bruce Schneier Proves That Secure Cryptography is Impossible
Date: Sun, 17 Oct 1999 01:29:39 GMT
This posting is in reference to the October 15, 1999 issue of
Crypto-Gram.
And the title of the posting is perhaps a slight exaggeration; if
public-key algorithms are used, then under a threat model that does
not involve an adversary having access to your computer, or with fancy
dedicated hardware, secure cryptography is still possible.
Now just what did Bruce say (write) that inspires me to make this
(still, even after the above qualifications) outrageous assertion?
I'm referring to the article entitled "Key Length and Security".
It makes very important and valid points: a 512-bit key (for a
symmetric algorithm, not for RSA) can still be brute-forced easily if
it is produced by a process,
whether a defective random number generator,
or a hash of a short password
that is likely to generate a key from a pool of 2^56 possibilities, or
much less than 2^56 possibilities. And this often happens.
If we exclude public-key methods from consideration, and if we regard
unencrypted keys stored on a floppy disk, or written on paper, as
insecure even if they're locked in a bank vault,
then the simple flat assertion "user-remembered secrets are not
secure", with which the article ends, essentially means the title of
this posting.
I think it *is* correct that users can't memorize _passwords_ which,
because they have digits or punctuation marks thrown in, have enough
entropy in them to be adequate in themselves.
And there is a reason I underlined the word *passwords* in the
preceding sentence. Because it is the crucial point where I think
Bruce may have been mistaken. It is possible for the user of a
cryptographic system to memorize a pass phrase. It is possible to use
the same kind of tricks with a pass phrase as are used with short
passwords to increase entropy - insert an incongruous word, rather
than a non-alphabetic character, into the phrase. One can require two
or three pass phrases to be entered to produce the key.
(Note that I've earlier advocated stripping punctuation from pass
phrases, since I think it's easier to memorize the words of a longer
pass phrase than to get the punctuation exactly right every time.)
I could be wrong, but I believe it to be - with some effort - possible
for a user to memorize data, _in a suitable form_, from which a key of
sufficient (genuine) length can be derived. As there are many cases
where there is simply no reasonable alternative to a user-memorized
secret, I believe this is a vitally important point.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Biometric Keys are Possible
Date: 17 Oct 99 02:57:06 GMT
Bruce Schneier's latest Crypto-Gram caused me to think about how biometric
information could be used for cryptographic keys.
Some quantities, like the number of fingerprint ridges between two
features, are discrete. Extracting them from a scan of a fingerprint is
still a complicated process, requiring advanced software.
But many biometric characteristics are analog quantities. With such
quantities, there is the inescapable problem that some physical values
will be very close to the boundary between producing two different codes
for the value of the quantity.
No scheme can change this fact; if different output values are possible,
the transition between them must take place somewhere.
However, a system used for shaft encoders and the like, Gray code, can
ensure that codes for consecutive numeric values differ by exactly one
bit.
Why is this useful? Isn't a cryptographic key that is wrong in one bit
still useless?
Ah, but along with a user's ID, a system can store the check bits of an
error-correcting code that can correct a limited number of single-bit
errors in the user's biometric data.
Doubtless someone has thought of this before, and this idea is the subject
of a patent somewhere, but I thought it worth mentioning that this kind of
technique exists as an option.
John Savard
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Subject: Re: Bruce Schneier Proves That Secure Cryptography is Impossible
Date: Sat, 16 Oct 1999 20:02:03 -0400
Reply-To: [EMAIL PROTECTED]
John Savard wrote:
> then the simple flat assertion "user-remembered secrets are not
> secure", with which the article ends, essentially means the title of
> this posting.
> ******************
> And there is a reason I underlined the word *passwords* in the
> preceding sentence. Because it is the crucial point where I think
> Bruce may have been mistaken. It is possible for the user of a
> cryptographic system to memorize a pass phrase. It is possible to use
> the same kind of tricks with a pass phrase as are used with short
> passwords to increase entropy - insert an incongruous word, rather
> than a non-alphabetic character, into the phrase. One can require two
> or three pass phrases to be entered to produce the key.
> *********************
> I could be wrong, but I believe it to be - with some effort - possible
> for a user to memorize data, _in a suitable form_, from which a key of
> sufficient (genuine) length can be derived. As there are many cases
> where there is simply no reasonable alternative to a user-memorized
> secret, I believe this is a vitally important point.
>
> John Savard ( teneerf<- )
> http://www.ecn.ab.ca/~jsavard/crypto.htm
===========================
That's what poetry is for - it makes memorizing long passphrases
easy and fun...
An ass will always stay his kind
You cover him with stars and cheers
When it is time to use his mind
He only flaps his broad ears
Best wishes BNK
------------------------------
From: John Kennedy <[EMAIL PROTECTED]>
Subject: Re: Bruce Schneier Proves That Secure Cryptography is Impossible
Date: Sat, 16 Oct 1999 23:08:13 -0400
On Sun, 17 Oct 1999 01:29:39 GMT, [EMAIL PROTECTED]
(John Savard) wrote:
>This posting is in reference to the October 15, 1999 issue of
>Crypto-Gram.
>
>And the title of the posting is perhaps a slight exaggeration; if
>public-key algorithms are used, then under a threat model that does
>not involve an adversary having access to your computer, or with fancy
>dedicated hardware, secure cryptography is still possible.
>
>Now just what did Bruce say (write) that inspires me to make this
>(still, even after the above qualifications) outrageous assertion?
>
>I'm referring to the article entitled "Key Length and Security".
>
>It makes very important and valid points: a 512-bit key (for a
>symmetric algorithm, not for RSA) can still be brute-forced easily if
>it is produced by a process,
>
>whether a defective random number generator,
>
>or a hash of a short password
>
>that is likely to generate a key from a pool of 2^56 possibilities, or
>much less than 2^56 possibilities. And this often happens.
>
>If we exclude public-key methods from consideration, and if we regard
>unencrypted keys stored on a floppy disk, or written on paper, as
>insecure even if they're locked in a bank vault,
>
>then the simple flat assertion "user-remembered secrets are not
>secure", with which the article ends, essentially means the title of
>this posting.
>
>I think it *is* correct that users can't memorize _passwords_ which,
>because they have digits or punctuation marks thrown in, have enough
>entropy in them to be adequate in themselves.
>
>And there is a reason I underlined the word *passwords* in the
>preceding sentence. Because it is the crucial point where I think
>Bruce may have been mistaken. It is possible for the user of a
>cryptographic system to memorize a pass phrase. It is possible to use
>the same kind of tricks with a pass phrase as are used with short
>passwords to increase entropy - insert an incongruous word, rather
>than a non-alphabetic character, into the phrase. One can require two
>or three pass phrases to be entered to produce the key.
I don't understand the utility of multiple pass phrases. How are three
pass phrases better than one which is a concatenation of the three?
>
>(Note that I've earlier advocated stripping punctuation from pass
>phrases, since I think it's easier to memorize the words of a longer
>pass phrase than to get the punctuation exactly right every time.)
>
>I could be wrong, but I believe it to be - with some effort - possible
>for a user to memorize data, _in a suitable form_, from which a key of
>sufficient (genuine) length can be derived. As there are many cases
>where there is simply no reasonable alternative to a user-memorized
>secret, I believe this is a vitally important point.
And I think there are memorization techniques that will enable one to
remember highly secure pass phrases.
If you can memorize one long pass phrase you can use it to protect an
unlimited number of other secrets that cannot be memorized.
>
>John Savard ( teneerf<- )
>http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Aidan Skinner)
Subject: Re: A viable security strategy (and looking for off-the-shelf product)
Date: 17 Oct 1999 00:56:50 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 13 Oct 1999 19:42:51 GMT, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>attacks, what I'd like to do is have site B return some piece of text
>which needs to be returned to it by site A using some encryption method.
You might want to look into srp:
http://srp.stanford.edu/
>So (a) does this seem like a workable solution and (b) is there some
>off-the-shelf library that'll handle the encryption duties (it needs to
>run under both Windows and Unix)?
There's SRP libraries available, I cant honestly remember about the
licencing though...
- Aidan
--
"I say we just bury him and eat dessert"
http://www.skinner.demon.co.uk/aidan/
------------------------------
Date: Sat, 16 Oct 1999 23:19:57 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Patrick Juola wrote:
> In article <[EMAIL PROTECTED]>,
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >Roger Schlafly wrote:
> >>
> >> Exactly. No interoperability.
> >
> >Why do you care so much about interoperability? For a specific group
> >of communication partners to communicate securely, it suffices that
> >they argree on a specific software/hardware to use.
>
> Because the whole point of computer -- or more generally, communications --
> networks is to permit communication between widely distant and possibly
> unfamilar parties. One of the nice things about the telephone is that
> someone can telephone me from almost anywhere in the world, irrespective
> of whether or not they've communicated with me before or whether or not
> I have the same sort of telephone that they do. I can pass out my
> phone and fax numbers on my business cards, confident that anyone
> can communicate with me -- or that they can tell other people how to
> communicate with on the basis only of that information.
>
> I can drive almost anywhere, secure in the knowledge that no matter
> where I go, I will find a gas station that interoperates with my
> car. I didn't have to put some sort of special doohickey in my
> engine to make sure that the gasoline I put in in Denver will run
> in the engine I bought in New York.
>
> Similarly, I can put my PGP key into a public location and anyone
> who wants it -- and has a copy of PGP -- can get my key and communicate
> with me "securely." However, how many people have PGP? And how many
> people have a different secure Email protocol that is incompatible
> with PGP? And how many people are not going to want to switch over?
This is all fine. Simply pass out the information defining the ciphers you are
equipped to handle. This is not a problem.
>
>
> > If because of
> >lack of interoperability some three-lettered agencicies can't
> >intercept their messages, that's even better, isn't it?
>
> Well, gee. Let's assume that no one can communiate at all -- that
> means that no possible interception can occur. That would be
> best of all, wouldn't it?
>
> > If someone
> >participates in two groups with two different software/hardware, he
> >can acquire the necessary software/hardware, can't he?
>
> Not if it's expensive or ubiquitous. Do you have any idea how much it
> would cost to replace all of IBM's desk telephones?
So now it's an issue of cost rather than interoperability. We're picking a
single cipher to reduce the costs of deploying secure communication?
Consider the cost of replacing all that single-cipher equipment if/when a
weakness is detected. The threat of such a catastrophe dwarfs the cost of
multiple implementations.
Consider also the cost of implementing a less than appropriate cipher in
particular environments. As a designer one wants a little freedom to optimize,
i.e., reduce costs, by picking the most effective solution to the application.
A single cipher cannot be optimum in all situations.
>
>
> > If there is
> >sufficient market demand, manufacturers would provide facilities
> >for handling messages of both groups, much like my electric razor,
> >which works both in Europe and in US, where the voltages are different.
> >The language of my mother tongue needs an entirely different computer
> >input system than for English or the European languages. There isn't
> >any interoperability possible. Do you see the point?
>
> Yes. *IF* you have enough money to buy everything twice then you're
> "merely" inconvenienced.
TAANSTAAFL
Why he suggen concern over costs? The point is a concern of over security.
For a small increment in cost (twice is a ridiculous exaggeration) one gets a
respectable increment in security.
------------------------------
Date: Sat, 16 Oct 1999 23:21:25 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
David Wagner wrote:
> In article <[EMAIL PROTECTED]>,
> Jerry Coffin <[EMAIL PROTECTED]> wrote:
> > I doubt it takes more than 100 lines of code on average to implement
> > the AES finalist algorithms.
>
> In software, it's easy; in hardware, it's a huge added cost.
Huge compared to what? A single-chip implementation of just the cipher
might sustain a 100% or so increase in cost. But an appliance will see
only a few percent increase in cost.
------------------------------
** 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
******************************
