Cryptography-Digest Digest #32, Volume #11 Tue, 1 Feb 00 17:13:02 EST
Contents:
Re: Is there a practical guide to using crypto? (Rot 13)
Biggest keys needed (was Re: Does the NSA have ALL Possible PGP keys?) (Darren New)
Re: How to Annoy the NSA (Jerry Coffin)
Re: how to encipher (Albert Yang)
Re: Is there a practical guide to using crypto? (Jerry Coffin)
Re: Suitable hash for this application - in the public domain? (Albert Yang)
Available Algorithms ("Simon R. Love")
Is the following system acceptable for "casual" encryption? (David Goodenough)
english version of the cipherchallenge (Lionux)
Re: Private-key RSA ([EMAIL PROTECTED])
Access Security Broken ("John E. Kuslich")
Re: Does the NSA have ALL Possible PGP keys? (Johnny Bravo)
Re: Does the NSA have ALL Possible PGP keys? (Johnny Bravo)
Re: Is there a practical guide to using crypto? (Darren New)
Re: Private-key RSA (David A Molnar)
Re: Sbox construction idea (Mike Rosing)
Re: english version of the cipherchallenge (Troed)
Re: Is the following system acceptable for "casual" encryption? (Mike Rosing)
Re: Is the following system acceptable for "casual" encryption? (Eric Lee Green)
Re: Available Algorithms (Eric Lee Green)
Re: Does the NSA have ALL Possible PGP keys? (Eric Lee Green)
Re: NIST, AES at RSA conference (Terry Ritter)
Re: Is the following system acceptable for "casual" encryption? (Doug Stell)
----------------------------------------------------------------------------
Subject: Re: Is there a practical guide to using crypto?
From: [EMAIL PROTECTED] (Rot 13)
Date: 1 Feb 2000 11:01:14 -0800
In article <[EMAIL PROTECTED]>,
Jerry Coffin <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] says...
>
>[ ... ]
>
>> One thing I really want to know is if VISA card number consists of
>> 16 digits with two digits for month and four digits for year, whats
>> to stop someone from attempting every possible 22 digits combination
>> until they find one which works?
>
>The fact that there are 10**22 possible combinations.
I beleive that there are much fewer possible combinations.
First, the month/year isn't really part of the number. So that leaves
14-19 digits.
Second, the first 4 or 6 digits are the BIN, or bank id.
That's always the same for each bank.
Last, some number of digits (at least one) are a checksum.
I don't remember the algorithim but it has been posted in
the past and in fact there are "hacker" programs which will
generate numbers with the correct checksum- some merchants
(used to) assume that if the checksum is correct, the card is valid.
>In reality of course, the bank would probably notice something wrong
>well before you got this far.
Even if the possible combinations are greatly reduced due to the
factors above, this is still true.
--
Eric Murray www.lne.com/~ericm ericm at the site lne.com PGP keyid:E03F65E5
<IMG LOWSRC="javascript:alert('Delete C: and install Linux?')">
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Biggest keys needed (was Re: Does the NSA have ALL Possible PGP keys?)
Date: Tue, 01 Feb 2000 19:17:23 GMT
Newgroups trimmed...
> much that it would exceed the chandrasekhar limit and collapse into
> a black hole... so you couldn't retrive the data anyway".
I suspect this has come up before, but is there an upper limit on how big
keys need to be to be unbreakable via brute force? I.e., if I have a cypher
that can't be attacked mathematically (yeah, I know, how do I know?) and
brute-force key search is the only attack, is there a key size that due to
physics will prevent someone from searching all the keys? For example, if
the fastest operation consists of the time for one photon to cross the plank
length, and you assume you have computers that are the size of photons and
pack the entire observable universe with them, perhaps you couldn't count to
2^800 or something?
Is that still big enough given quantum computing advances? Can it be? (The
only quantum computers I've been able to understand are Feynman's
description, which focusses more on reversability than parallelism.)
--
Darren New / Senior Software Architect / IZ, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
There is no safety in disarming only the fearful.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: How to Annoy the NSA
Date: Tue, 1 Feb 2000 12:28:31 -0700
In article <8778es$r8d$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> You are wrong again. According to Science
> Magazine (vol. 275, page 1570, March 14,
> 1997) "hard" problems, or NP-Complete
> problems "underlie nearly all cryptography and
> computer security codes".
You're getting things backwards: when Science Magazine publishes an
article the contradicts Doug Gwyn (among others) about cryptography,
it isn't _quite_ proof that the article you've read is wrong, but
there's a LOT better chance that the article is wrong (or
oversimplifying) than that he is.
> If you don't believe
> me then check out links like the RSAsecurity
> link in my previous message and
> www.cs.ccu.edu.tw/~ccc/student/dcl/dcl.htm
> Despite the issue of NP-completeness, such a
> quantum computer would have awesome power
> for factoring.
A quantum computer could factor quite a bit faster than a traditional
computer, but keep in mind that much more complete and accurate
descriptions are available than simply "awesome power". As a matter
of fact, we already know _exactly_ how factoring can be done on a
quantum computer and can simulate it on a conventional computer. We
can figure out the number of steps involved in such a process.
Equipped with that, we can figure out exactly how large of a key is
needed with RSA (for one example) to completely thwart the attack well
before it exists.
> Everyone should know that Al Gore did not
> invent the internet and that it was first
> developed as a military project about 30 years
> ago.
As usual, you're getting things just about exactly backwards. ARPAnet
was developed in the civilian sector as a way of helping communication
between various places (mostly colleges and universities) doing
research sponsored by the military. The funding (or part of it
anyway) was provided by the military, but the technology was developed
by the civil sector. The military provided some of the big servers in
the early days of the Internet, but most of them were simply old
computers that weren't being used for much else -- computers in active
military use containing anything like classified information aren't
allowed to be connected to the Internet at all.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Albert Yang <[EMAIL PROTECTED]>
Subject: Re: how to encipher
Date: Tue, 01 Feb 2000 19:32:41 GMT
on unix, cal didn't handle it? I would be surprised, since it handles
stuff like 2^128 without much problem.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Is there a practical guide to using crypto?
Date: Tue, 1 Feb 2000 12:36:02 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> Except that credit card numbers are not randomly chosen from the entire
> space. They have some structure to them, including a checksum and
> card-type and bank-specific prefixes.
True, but more or less irrelevant: even if there's enough structure to
reduce the search from 160 years to only few months, the bank's going
to notice a problem anyway.
> Yep. Even in the restricted space of real CC numbers this is definitely
> the case. It's much easier to dig numbers out of the garbage can at the
> mall, or get a job as a clerk somewhere, or...
Quite true -- I'm frequently reminded of an old Dilbert where two of
them are at a restaurant talking about how dangerous it is to use a
credit card on the Internet. During the conversation he hands his
credit card to the waitress to pay for dinner. When the waitress
returns, she's wearing a new fur coat...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Albert Yang <[EMAIL PROTECTED]>
Subject: Re: Suitable hash for this application - in the public domain?
Date: Tue, 01 Feb 2000 19:35:50 GMT
We are contemplating the use of "Tiger" in replacement for MD5.
http://www.cs.technion.ac.il/~biham/
It seems a lot more secure than MD5, and also, a longer hash value as
well. Eli is a very good cryptographer, one of the best in the world,
and so I trust Tiger.
------------------------------
From: "Simon R. Love" <[EMAIL PROTECTED]>
Subject: Available Algorithms
Date: Tue, 1 Feb 2000 19:48:49 -0000
All,
Sorry if this is the wrong newsgroup but you lot are the best placed to know
...
I am interested in using some encryption system in a commercial product. It
is intended to be used outside the US, but with a possible venture over
there at some point in the future.
My basic question, of all the well known algorithms, which ones are
available for use without patent, copyright, trade secret etc which means
its going to cost me ?
I thought that this type of question would be in the FAQ but I couldn't find
it in there !.
If anyone can point me to a summary / list of algorithms and their legal
status ( country dependant ) that would be ideal.
If not, could someone confirm SAFER SK64/SK128 are unpatented and could be
used commercially without restriction ?
Thanks in advance.
Simon R. Love
England
------------------------------
From: David Goodenough <[EMAIL PROTECTED]>
Subject: Is the following system acceptable for "casual" encryption?
Date: Tue, 01 Feb 2000 11:59:17 -0800
First of all, what do I mean by casual encryption? To my somewhat
naive way of thinking, I split the world of people who want to decrypt
my data into two groups: the NSA and everyone else. Casual encryption
should keep out the second group, but is not expected to keep out the
first.
Having said that, this is the system I have in mind:
Have the user enter a password.
Hash the password using a hashing algorithm, e.g. SHA1.
Take the first 128 bits of the hash, and use as a block key for a
symmetric cypher, e.g. SAFER.
Are there any obvious flaws in this system? Will the two example
above provide reasonable security, or should I look elsewhere?
Thanks for any advice,
David Goodenough
------------------------------
From: Lionux <[EMAIL PROTECTED]>
Subject: english version of the cipherchallenge
Date: Tue, 01 Feb 2000 20:04:19 GMT
hi,
I have purchased the book from Simon Singh .But being french ,I have the
french version of the book and so of the cipherchallenge .
Do some of you have or know where I could find the english version
(without buying the book in english ) of the cipherchallenge ?
Thank you for your answer.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Private-key RSA
Date: Tue, 01 Feb 2000 19:59:23 GMT
In article <876qlt$b8n$[EMAIL PROTECTED]>,
David A Molnar <[EMAIL PROTECTED]> wrote:
> > Maybe even if he has a quantum computer (as there are an infinite
> > number of Public(so-called)-keys)?
>
> No, there is a finite number of public keys. About phi(n) of them,
> actually. No idea how that helps/hurts a quantum computer
Sorry...are you saying that there is a finite number of primes...I
always thought there was an infinite number of primes...all these
years...
Jack
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Access Security Broken
Date: Tue, 1 Feb 2000 12:48:58 -0700
Acces Database security is now completely broken. The extremely fine
grained User Level security features of Access involving SID's accounts,
groups, permissions etc. ad nauseam has fallen down because the cryptography
used is easily bypassed by simply walking through the back door.
This is a constant theme we stress about cryptography on the PC. Just
because you use a strong algorithm to encrypt you passwords and just because
you use sophisticated authentication protocols does not mean that your
security cannot be bypassed. The PC is NOT secure.
CRAK Software will now ofer a FREE Access file level password recovery tool
CRAK Software http://www.crak.com as part of the AXcrak product (which also
defeats User Level Password Protection).
The ACxrak file is a very small download (only 83K - less than 30 seconds on
a 28.8kB connection) and is very easy to use (requires NO programming
skills). If you can push a button, you can use this software.
JK
CRAK Software http://www.crak.com
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Tue, 01 Feb 2000 15:20:48 +0000
On Tue, 01 Feb 2000 13:01:44 -0500, cfm <[EMAIL PROTECTED]> wrote:
>What's the big deal, any one of us who wishes to spend the time can
>generate all possible PGP keys.
You are wrong. There are more PGP keys than atoms in the universe. I
leave it to the reader as an exercise to determine how long it would take
for every computer ever constructed (I'll even grant that they are all
functional at 100%, even Eniac :), to compute all the 512 bit primes.
Much less those of 2048 bits.
Your second problem is where are you going to store the list. Even if
you found a method to encoding each number on a single atom, you are going
to run out of atoms in the universe before you run out of numbers.
Johnny Bravo
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Tue, 01 Feb 2000 15:25:03 +0000
On Tue, 1 Feb 2000 11:42:50 -0500, "Dorsey Bolliard"
<[EMAIL PROTECTED]> wrote:
>My suspicion (admittedly without solid basis) is that the government
>probably has people working day and night on the problem, and undoubtedly
>has algorithms that CAN break encoded messages in finite time, but that the
>time involved is still sufficiently long so as to make the routine intrusion
>into every pgp message prohibitively costly.
Or more likely they can't, but they don't need to. Is your home TEMPEST
shielded? I seriously doubt it. The government can park a van outside
your building and read everything on your screen, every keystroke you
make. If they thought you were worth the effort, they would do so.
That is the bottom line, the vast majority of us aren't worth it. The
government doesn't give a damn what is in my email, encrypted or
otherwise.
Best Wishes,
Johnny Bravo
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Is there a practical guide to using crypto?
Date: Tue, 01 Feb 2000 20:30:10 GMT
Jerry Coffin wrote:
> True, but more or less irrelevant: even if there's enough structure to
> reduce the search from 160 years to only few months, the bank's going
> to notice a problem anyway.
Unless you work at the bank, of course. Of course, every CC you look up
might hit a different bank, so the bank may only see a few ban numbers a
day.
> Quite true -- I'm frequently reminded of an old Dilbert where two of
> them are at a restaurant talking about how dangerous it is to use a
> credit card on the Internet. During the conversation he hands his
> credit card to the waitress to pay for dinner. When the waitress
> returns, she's wearing a new fur coat...
The difference being, of course, that on the internet, the banks can't find
patterns of fraud nearly as easily. They don't really care about that fur
coat. They care about the waitress passing the numbers from bunches of
customers on to friends and all the friends buying stuff with them. They can
deal with that by looking at the places where the stolen cards were used,
which they can't do when you use it over the net and it's snagged in
transit.
Of course, there are cheaper ways of getting lots of credit card numbers.
Much cheaper and more reliable (in terms of getting CC#s) to bribe a bank
clerk than a ISP administrator, for example.
--
Darren New / Senior Software Architect / IZ, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
There is no safety in disarming only the fearful.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Private-key RSA
Date: 1 Feb 2000 20:51:50 GMT
[EMAIL PROTECTED] wrote:
> Sorry...are you saying that there is a finite number of primes...I
> always thought there was an infinite number of primes...all these
> years...
My mistake. I thought that we had already fixed n and were talking about
the number of possible "e" values. Of course there is an infinite number
of primes.
Do note, however, that there is a finite number of primes of 512 bits in
size. (or however many fixed bits). You can put a rough upper bound on
the size of the modulus by seeing how big the packets are. :-)
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Sbox construction idea
Date: Tue, 01 Feb 2000 15:11:47 -0600
Tim Tyler wrote:
>
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> : In safer they use 45^x mod 257 for the sbox in the cipher, what if you
> : created a 4x8 parallel set of sboxes [four side by side] with different
> : bases? So you end up with a 8x32 sbox?
>
> : Has that idea ever been discussed before? [...]
>
> I don't know. Would anyone care to offer me some sort of literature
> reference that offers reasons why using a^x mod p is of interest as a
> method of generating s-boxes?
Yes, it's in the literature. These are linear sbox's, and therefore
won't work for crypto. If you use a formula, it has to be nonlinear.
The best sbox designs are to grab random data and check the results
for good avalanch and the rest of good sbox criteria. See "Good S-box's
are easy to find" by C. Adams.
> I'm interested in the general question of how best to combine small
> s-boxes to form larger s-boxes - with "security" and compactness of
> hardware implementation being the criteria I'm most interested in.
>
> A key question appears to be "what is the best size of s-box to use?"
That depends on the application! There are good rules for input/ouput
size limits, check the literature 'cause I'm sure I've forgotten it all
by now :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Troed)
Subject: Re: english version of the cipherchallenge
Reply-To: [EMAIL PROTECTED]
Date: Tue, 01 Feb 2000 21:12:21 GMT
Lionux <[EMAIL PROTECTED]> wrote:
>I have purchased the book from Simon Singh .But being french ,I have the
>french version of the book and so of the cipherchallenge .
>Do some of you have or know where I could find the english version
>(without buying the book in english ) of the cipherchallenge ?
Stages 2-10 of the challenge is the same in all versions of the book.
___/
_/
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Is the following system acceptable for "casual" encryption?
Date: Tue, 01 Feb 2000 15:20:30 -0600
David Goodenough wrote:
>
> First of all, what do I mean by casual encryption? To my somewhat
> naive way of thinking, I split the world of people who want to decrypt
> my data into two groups: the NSA and everyone else. Casual encryption
> should keep out the second group, but is not expected to keep out the
> first.
>
> Having said that, this is the system I have in mind:
>
> Have the user enter a password.
>
> Hash the password using a hashing algorithm, e.g. SHA1.
>
> Take the first 128 bits of the hash, and use as a block key for a
> symmetric cypher, e.g. SAFER.
>
> Are there any obvious flaws in this system? Will the two example
> above provide reasonable security, or should I look elsewhere?
That's pretty much the basics. Try to encourage people to pick long
pass phrases that are easy to remember, and do your best to keep the
code on a single computer. There are many levels of paranoia, you can
use memory locks to prevent any key data from being written to disk
for example. That's something a determined thief/hacker could use.
If it's just to protect data that's going to be shipped around, or
stored for a while, then you're on the right track. Nothing is perfect,
so if you plan to protect data from script kiddies and aren't worried
about the NSA going in with a transmitter, you're on the right track.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Is the following system acceptable for "casual" encryption?
Date: Tue, 01 Feb 2000 14:21:14 -0700
David Goodenough wrote:
> First of all, what do I mean by casual encryption? To my somewhat
> naive way of thinking, I split the world of people who want to decrypt
> my data into two groups: the NSA and everyone else. Casual encryption
> should keep out the second group, but is not expected to keep out the
> first.
>
> Having said that, this is the system I have in mind:
>
> Have the user enter a password.
>
> Hash the password using a hashing algorithm, e.g. SHA1.
>
> Take the first 128 bits of the hash, and use as a block key for a
> symmetric cypher, e.g. SAFER.
>
> Are there any obvious flaws in this system? Will the two example
> above provide reasonable security, or should I look elsewhere?
For best security you'll probably want to packetize the input and use a cipher
block feedback mode. You could also use the cipher as the pad generator for a
stream cipher, but that has the disadvantage that you must have a unique
initialization value, meaning either a very good random number generator or
some other method (otherwise you will be encrypting multiple messages with the
same "one time pad", which I imagine many others will enlighten you as to why
that's a bad idea). Still, a stream feedback mode like CFB-128 is plenty
secure for casual use, as long as you have some place to increment a counter
to produce a unique initialization value each time, or a source of
cryptographical-quality random numbers to use for initialization values. And
it's easier to use a stream mode than it is to packetize your data.
Passwords have little entropy and are succeptible to a variety of precomputed
dictionary attacks, but for casual use (as vs. trying to hide things from the
NSA or FBI or trying to keep hackers out of your credit card database!), that
doesn't matter. Adding a salt value will prevent many pre-computed dictionary
attacks (but not real-time dictionary attacks), but you probably don't want to
bother for your purposes.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Available Algorithms
Date: Tue, 01 Feb 2000 14:24:18 -0700
"Simon R. Love" wrote:
> My basic question, of all the well known algorithms, which ones are
> available for use without patent, copyright, trade secret etc which means
> its going to cost me ?
I don't know about the status of most algorithms, but BlowFish and TwoFish (
http://www.counterpane.com ) were explicitly released without patent and with
a license that allows free use for all purposes. See Counterpane Lab's web
site.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Tue, 01 Feb 2000 14:39:34 -0700
Johnny Bravo wrote:
>
> On Tue, 01 Feb 2000 13:01:44 -0500, cfm <[EMAIL PROTECTED]> wrote:
>
> >What's the big deal, any one of us who wishes to spend the time can
> >generate all possible PGP keys.
>
> You are wrong. There are more PGP keys than atoms in the universe. I
> leave it to the reader as an exercise to determine how long it would take
> for every computer ever constructed (I'll even grant that they are all
> functional at 100%, even Eniac :), to compute all the 512 bit primes.
> Much less those of 2048 bits.
Note that we're concerned about "probably prime" numbers. It is quite a bit
easier to test a number to see whether it is "probably prime" than it is to
attempt every possible factorization of a number and thus PROVE that it's
prime. Otherwise PGP never WOULD be able to generate a key.
Remember, a network of rather modestly-powered personal computers in the
Netherlands broke 512-bit RSA encryption in a matter of weeks. 512-bit
encryption, at least, seems well within the reach of pre-computing all
possible PGP keys. It's estimated that there's approximately 2^86 of them,
77,371,252,455,336,267,181,195,264, though, so storing them would be a slight
problem (we're talking about 77 billion times more storage than the biggest
data warehouse that I've ever encountered!).
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: NIST, AES at RSA conference
Date: Tue, 01 Feb 2000 21:59:43 GMT
On Tue, 01 Feb 2000 11:19:31 -0700, in
<[EMAIL PROTECTED]>, in sci.crypt Shawn Willden
<[EMAIL PROTECTED]> wrote:
>Serge Vaudenay wrote:
>
>> The proof is quite obvious if you consider attacks as distinguishers. If you
>> take MARS o RC6 o TWOFISH with three independent keys as a cipher, then
>> any distinguisher between this and a truly random permutation can be
>> transformed into a distinguisher between for instance RC6 and a random permutation
>> by simulating MARS and TWOFISH.
>>
>> This way the product cipher is at least as secure as its strongest
>> factor.
>
>Given independent keys. What if the same key is used for all three?
Don't do that.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: Is the following system acceptable for "casual" encryption?
Date: Tue, 01 Feb 2000 21:46:37 GMT
On Tue, 01 Feb 2000 11:59:17 -0800, David Goodenough
<[EMAIL PROTECTED]> wrote:
>First of all, what do I mean by casual encryption? To my somewhat
>naive way of thinking, I split the world of people who want to decrypt
>my data into two groups: the NSA and everyone else. Casual encryption
>should keep out the second group, but is not expected to keep out the
>first.
>
>Having said that, this is the system I have in mind:
>
>Have the user enter a password.
>
>Hash the password using a hashing algorithm, e.g. SHA1.
>
>Take the first 128 bits of the hash, and use as a block key for a
>symmetric cypher, e.g. SAFER.
>
>Are there any obvious flaws in this system? Will the two example
>above provide reasonable security, or should I look elsewhere?
The password is the weak link in the system and simple use of a
password is VERY weak. What algorithms you use makes little
difference, because the password is the obvious point of attack.
If you have to live with passwords, consider using salt and enforce
the use of good passwords. For salt, pick a unique random value for
each encryption and concatenate it with the password. To permit
decryption, the salt must be included with the ciphertext. A good
password should have minimum restrictions on length, forced use of
numerals and/or punctuation characters.
>
>Thanks for any advice,
> David Goodenough
------------------------------
** 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
******************************
