Cryptography-Digest Digest #258, Volume #12 Thu, 20 Jul 00 10:13:01 EDT
Contents:
Re: Quantum Computer similator websites with source code (Jochen Messner)
Re: Carnivore and Man-in-the-middle (Anon User)
Re: how strong is my own encryption? ("Martin")
Searching for an algorithm... (Thomas Luzat)
Re: Signed Data ("Hans Husman")
Re: Has RSADSI Lost their mind? (Mark Wooding)
Re: Searching for an algorithm... ("Kasper Pedersen")
Re: Searching for an algorithm... (Mark Wooding)
Re: Has RSADSI Lost their mind? (Larry Kilgallen)
RE: Signed Data ([EMAIL PROTECTED])
Re: how strong is my own encryption? (Mark Wooding)
Re: Searching for an algorithm... ("Kasper Pedersen")
New stream cipher ([EMAIL PROTECTED])
Re: Searching for an algorithm... (Runu Knips)
----------------------------------------------------------------------------
Date: Thu, 20 Jul 2000 13:43:59 +0200
From: Jochen Messner <[EMAIL PROTECTED]>
Crossposted-To: comp.theory
Subject: Re: Quantum Computer similator websites with source code
Jamie Andrews wrote:
>
> Jeff Erickson wrote:
> >Hardly. Given the recent computation of the trillionth(!) bit of pi
> >using classical computers, why should anyone think computing bits of
> >sqrt(2+x) is hard?
>
> Absolutely. Heck, I can compute the millionth bit of
> sqrt(2+x) in my head... for x of the form (n*n - 2).
>
The nice thing in this case is that you cannot fail. Both answers
0 or 1 are correct ... so it is possible to give the answer even without
using your head ...
Jochen
------------------------------
Date: Thu, 20 Jul 2000 06:55:05 -0500 (CDT)
From: Anon User <[EMAIL PROTECTED]>
Subject: Re: Carnivore and Man-in-the-middle
>> not really,
>> the box is TOTALLY FBI secured, therefore no one [ event ISP ]
>> knows what FBI is / will collect ...
>
> Yes, but the original assertion that a canivore unit will be
> permanently installed in every ISP's data path is something I haven't
> heard before. (And tend to doubt ;)
Why? CALEA makes sure LEO access is built in to every Central Office switch.
E911 requires wireless companies to provide LEO with tracking ability.
And we all know about ECHELON. This is just another avenue towards the feds'
ultimate goal of total pervasive surveillance capacity. Orwell's nightmare
fully realized and expanded with technology in ways he could never imagine.
> Granted, the entire system has some serious issues to be resolved, but
> paranoia cerainly won't help.
Paranoia is the only thing that keeps me one step ahead of "Them".
Tell me, can you think of any case in this context where paranoia was NOT
justified? In Britian RIP is about to pass into law - they already have
cameras on streetlight poles providing police with real-time crowd survellance
slaved to databases of digitally-stored photos. Keep in mind that in the early
1990s a private company built just such a database from US driver's licenses.
Who funded this private company you ask? Why, the Secret Service did - you see,
it was illegal (at that time) for a "government entity" to build such a database.
But "They" wanted it so "They" merely contracted the job out. All perfectly
legal.
For a while, Georgia required your thumbprint to be digitally encoded on
a resident's driver's license. I believe this actually angered The Public enough
to where the govt had to back off. For now. Care to make a wager as to when, not
if, one or more forms of biological ID will be required on some form of govt ID
card? There already exist databases of DNA gathered from assorted rapists and child
molesters. And as expected the govt has slowly been expanding the definition of
who's DNA would be included in these databases - "stretching the net", it's called.
Utimate goal? - a database of everyone's DNA. Those clever chaps in Britian are
in the process buidting just exacly that.
And then there's the "covert search" bill buit into the giant "meth" bill
plodding through Congress, which will give the feds the ability to sneak into
your home without your knowledge and gather "information". Couple that with
another law They just got passed that lets them load sneaky survellance programs
onto your computer without your knowledge, things like password grabbers and
encryption key grabbers.
Just when you think it can't get worse, it does. Usually in the name of
"protecting the children" and "domestic terrorism".
You say I'm paranoid? I say you (people) need to see the bigger picture.
"Your tax dollars at work."
------------------------------
From: "Martin" <[EMAIL PROTECTED]>
Subject: Re: how strong is my own encryption?
Date: Thu, 20 Jul 2000 13:15:07 +0100
Okay. Thanks for the link.
While I'm here, can someone please post a list of good cryptography books?
Martin
Eric Hambuch <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Martin wrote:
>
> >
> > I'm quite new to this crytology thing and I was wondering how you would
do
> > the statistical analysis?
>
> Okay, I've found a good paper, that describes a simple algorithm:
>
> T. Jakobsen: A Fast Method for Cryptanalysis of Substituion Ciphers,
> Cryptologia 19(3), 1995
> online available at:
> http://www.counterpane.com/biblio/all-by-author.html
>
> Eric
------------------------------
From: Thomas Luzat <[EMAIL PROTECTED]>
Subject: Searching for an algorithm...
Date: Thu, 20 Jul 2000 14:34:13 +0200
Reply-To: [EMAIL PROTECTED]
I'd like to create a password management program which stores
passwords the user enters encrypted. Now I wonder which way to do this
best.
I thought of creating a hash from the master password which is then
used to encrypt the whole file which contains the passwords (and which
could be compressed before doing the encryption). Is this a good way
to handle it?
The next question is which strong and free (!) algorithms could be
used for creating the hash and encrypting the file. I thought of using
Blowfish (it's free, isn't it?), but any alternatives would be nice
(3DES?). I've heard that MD5 could be used for hashing, but also that
it isn't the best choice nowadays. Any suggestions?
Thanks,
Thomas Luzat
------------------------------
From: "Hans Husman" <[EMAIL PROTECTED]>
Subject: Re: Signed Data
Date: Thu, 20 Jul 2000 14:43:40 +0200
IE doesn't have a ready to run function lika crypto.signText but you can
access the CryptoAPI in advapi32.dll from VBScript to get the same
functionlity and more.
Best Regards
============================================================================
---
Hans Husman
Security Specialist
Mynta Management & IT AB
[EMAIL PROTECTED]
http://www.mynta.se
============================================================================
---
Prenumerera på något av Myntas nyhetsbrev!
Mynt@. Ett nyhetsbrev från en elektronisk affärsvärld.
Säker med Mynta. En elektronisk tidning om datasäkerhet.
Skicka ett mail till [EMAIL PROTECTED] och ange vilket nyhetsbrev du vill ha.
============================================================================
---
"Yo" <[EMAIL PROTECTED]> wrote in message
news:8l6lfe$rvh$[EMAIL PROTECTED]...
> No
> Kevin Crosbie <[EMAIL PROTECTED]> escribió en el mensaje de
noticias
> 8l4uj4$[EMAIL PROTECTED]
> >
> > Does IE have a scripting function(VBScript, JScript....) which provides
> the
> > same function as crypto.signText?
> >
> >
>
>
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Has RSADSI Lost their mind?
Date: 20 Jul 2000 12:51:36 GMT
Vin McLellan <[EMAIL PROTECTED]> wrote:
[With occasional snippings and minor reformatting:]
> Mark Wooding asked a famous question:
>
> Why, in the fall of 1994, did Netscape's management choose to build
> SSL around RSApkc -- as opposed to D-H/El Gamal -- and RSADSI's BSAFE
> crypto toolkit?
At this point, a clarification is perhaps in order. My question did not
address BSAFE (which I thought implemented Diffie-Hellman anyway --
certainly RSAREF does -- and is therefore a red herring). And it was
intended to be a technical rather than a political question, although I
understood at the time, and still do, that it may have a political
answer.
One of my major concerns in protocol designs at the moment is forward
secrecy. This concern is motivated by the Regulation of Investigatory
Powers (RIP) bill, which the UK Home Office is attempting to push
through Parliament. One of this bill's provisions is that it permits
`authorised persons' to present people with notices (called `Section 46
notices') requiring them to surrender keys or `render intelligible'
encrypted messages. There is a special provision in this bill which
protects keys used only for making digital signatures; hence, protocols
in which the only long-term keys are signing keys are resistant to
compromise through the serving of Section 46 notices[1].
Now the RIP bill is fairly new, and clearly wasn't a concern when SSL
was being designed. But we've surely known for a long time the benefits
of including forward secrecy in our protocols. So, my question was:
give that it has the significant technical advantage of providing
forward secrect, why isn't ephemeral authenticated Diffie-Hellman a
better-supported, and indeed dominant, key-exchange mechanism in SSL?
Roger Schlafly's response was somewhat cynical, but has an air of truth.
(I don't have a specific axe to grind, but I have little love for
RSADSI.) My point above about BSAFE implementing Diffie-Hellman remains
unanswered by this, though, so Roger's explanation is at best
incomplete.
> ([...] Old PGPers are gleefully predicting a September Doom for RSA,
> while others accuse RSA of being downright ungenerous to PGP Inc.,
> that notable bastion of neo-Capitalist self-righteousness and
> prematurely post-patent profit-seeking;-)
While this sentence gave me a grin when I read it, it doesn't entirely
hang together. I'm not sure quite how well the old PGPers and PGP
Inc. go together. I've been a low-scale PGP user since version 2.3, but
I remain extremely sceptical about PGP Inc. and its products. I now use
the GNU Privacy Guard instead.
I'm certainly less confident than others in this thread that 20
September (a date I've had marked down for some sort of celebration for
most of the year) will mark the Beginning of the End for RSASI; but I'd
certainly not be unhappy to be proven wrong.
> Someone in one of the followup messages referred back to
> Mr. Schlafly's post to reassure someone else that his cynicism was
> well founded: that the choice of RSApkc over D-H was "just politics."
>
> From another point of view, that's sheer bullshit. There was no big
> decision. RSApkc and the RSA BSAFE crypto toolkit were the obvious
> choices for Netscape.
The technical advantage of ephemeral Diffie-Hellman, was ignored
completely, then? That sounds very strange.
> RSA offered Netscape a deal in which this hungry little startup got an
> unrestricted license to use RSA's BSAFE code, cash-free, in exchange
> for a legendary 1 percent of Netscape.
Not completely unrestricted, clearly: they're not allowed to release the
sources as part of Mozilla.
> What isn't clear in Mr. Schlafly's summary was that that deal merely
> settled -- on relatively generous terms, I think -- what was always a
> foregone conclusion. D-H was simply a non-starter in 1994, according
> to most informed observers.
Not a total non-starter. Sun's `Secure RPC' was based on Diffie-Hellman
and DES, for example. Could you perhaps amplify on this paragraph,
offering the reasons why Diffie-Hellman was a `non-starter', by
preference addressing the issue of ephemeral key exchange providing the
property of forward secrecy, a property which RSA can't provide because
the keys take so (comparatively) long to generate?
The SSH protocol, which I described in overview in this newsgroup a
month or so ago, uses short-term RSA keys for forward secrecy. This is
rather bizarre behaviour, but it does demonstrate that the SSH designers
were aware that this was an important issue. Given that SSL lacks many
of the other more questionable aspects of the SSH protocol (e.g., the
use of encrypted CRCs to provide an integrity check on packets), are you
really trying to tell me that the SSL designers entirely neglected
forward secrecy in their design?
> Putting aside the obvious risks -- to the users, (to the web), and to
> the reputation of all RSA-enabled security products -- of allowing
> OEMs write their own cryptographic implemention code
Are those risks obvious? Given the number of times RSA screwed up with
their own code, I think that this sounds a bit hollow (consider, for
example, the chosen ciphertext attack against PKCS#1 type 2 packing, and
the buffer overflow exploit in RSAREF).
To pick on a particular case, did requiring Zimmerman to replace his
solid and efficient modexp code in PGP with the slow and (as we now
know) insecure RSAREF implementation do anything to improve the
reputation RSADSI?
> isn't there also a clear business case for this marketing strategy?
> (So clear, in fact, that any software firm which didn't use it would
> look silly -- as well as be damned by many here for simply licensing,
> not developing, its patents.)
I'm ambivalent on the subject of what you do with patents once you've
got them, on the grounds that I oppose their existence entirely.
> The bottom line: the more OEMs which purchase a BSAFE license, the
> more products which use (compatable, potentialy interoperable) BSAFE
> code modules -- and thus, the more valuable each individual BSAFE
> license, current and future, would be to all BSAFE licensees, current
> and future. And to RSADSI, of course!
Or, with opposite spin, by
(a) defining the standard data formats for keys, certificates, etc.,
in terms of an arcane syntax notation and horrific concrete
representations, and
(b) forcing these representations onto the world through their
(US-only) monopoly on RSA toolkit software,
they hoped to lock their customers into using BSAFE even after
2000-09-20 in a stroke of cynical genius of which even Microsoft would
have been proud.
> (There are now over a *half-billion* BSAFE installations, embedded in
> thousands of different commercial products, from over a thousand
> different OEM vendors who have licensed BSAFE code.
Working well, isn't it? ;-)
> ([...] Others are non-US firms which never had to worry about the US
> patent. Weatherman, weatherman, which way is that wind blowing?? ;-)
Weatherman
You get it over
We penetrate your disguise
Weatherman, get it over
Twist the fork in her spine
[Machines of Loving Grace]
> Back to the Question: Why, in 1994, did Netscape chose RSApkc as the
> basis for Kipp Hickman's SSL v.1 and SSL v.2?
>
> Paul Kocher, one of the designers of SSL 3 for Netscape, now president
> of Cryptography Research, Inc. and a leading US cryptographer,
> summarized the logic in a post to the OpenSSL list:
[snip]
It doesn't at all address the issue of ephemeral Diffie-Hellman. While
he expresses concern about DSA, there's no reason you can't do EDH
authenticated using RSA signatures.
> I don't really want to get into a prolongued pissing match here
> (although it could be entertaining, at least to observers;-) I only
> suggest that anyone with a real interest in crypto history should roam
> a bit beyond this forum -- or at least this thread -- and sort out the
> politics, economics, and morality of the RSA story for themselves.
Thanks for yet another long but informative article. I hope you take
the comments I've made above in the (occasionally pointed but generally
friendly) spirit in which they're intended.
[1] There's a downside, in that by signing ephemeral keys, a user
provides a certificate that they participated in a particular
instance of the protocol. This must be addressed by weakening the
binding between signing keys and physical people.
-- [mdw]
------------------------------
From: "Kasper Pedersen" <[EMAIL PROTECTED]>
Subject: Re: Searching for an algorithm...
Date: Thu, 20 Jul 2000 13:18:43 GMT
"Thomas Luzat" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I'd like to create a password management program which stores
> passwords the user enters encrypted. Now I wonder which way to do this
> best.
I did such a thingy, although a bit different. I haven't published it, as I
haven't really scutinized* it yet.
It has the benefit that it doesn't need the mater passphrase to be present
every time you enter a new password.
I chose a prime and a generator for DH (stole them from SSLeay actually),
and used a hash of the master passphrase as secret x(a). Out pops the public
y(a)=g^x(a) mod p.
y(a) is then stored in public view, and x(a) is destroyed.
When I enter a new ordinary-password, the middle part of the DH key exchange
is done:
x(b) is selected at random, y(b) is calculated and stored in the a file,
followed by the password blowfish encrypted by K=y(a)^x(b) mod p.
To retrieve K, recreate x(a), and calculate K=y(b)^x(a) mod p. Now you can
read the stored password.
I presume it's the right way to do it, but there might be a danger in
reusing the x(a)/y(a) - I admit I don't know*, but it can't affect the
security of the master passphrase - the gurus here might be able
to drive a nail through it.
And while they're at it they could tell me wether x(*) needs to be more than
128 bits long.
/Kasper
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Searching for an algorithm...
Date: 20 Jul 2000 13:24:51 GMT
Thomas Luzat <[EMAIL PROTECTED]> wrote:
> I'd like to create a password management program which stores
> passwords the user enters encrypted. Now I wonder which way to do this
> best.
>
> I thought of creating a hash from the master password which is then
> used to encrypt the whole file which contains the passwords (and which
> could be compressed before doing the encryption). Is this a good way
> to handle it?
>
> The next question is which strong and free (!) algorithms could be
> used for creating the hash and encrypting the file. I thought of using
> Blowfish (it's free, isn't it?), but any alternatives would be nice
> (3DES?). I've heard that MD5 could be used for hashing, but also that
> it isn't the best choice nowadays. Any suggestions?
1. Counterpane already has Password Safe, which you may want to look
at. It doesn't cost anything but they don't give you the source
code. I think I'd trust them to have got it right anyway, but I
don't like non-free (in the FSF sense) software anyway.
2. Blowfish is indeed strong and free. Following Steffan Lucks'
attack on triple-DES, I consider Blowfish to be stronger. It's
also about five times as fast, in my experience.
3. MD5 could be used. I'd rather use RIPEMD-160, Tiger or SHA1. All
of these are free. MD5 has been attacked though not demolished;
the others are standing firm as far as I can tell.
4. I think your scheme to encrypt the passwords with the hash of a
master passphrase is too simplistic.
When the password file is created, I'd invent a strong random key, and
encrypt the passwords under that. Give each a different IV, so that
they can be decrypted and modified individually. Encrypt the master key
under a `master passphrase key' created by hashing the master passphrase
together with a random `salt' which you store in the clear.
So: let K be the secret random key, and let M be the master passphrase.
Write encryption of x using key k and initialization vector i as E_k(i,
x). Store in the header R, E_{0, H(R || M)}(K), where R is a random
salt. Then for each password P_i, store I_i, E_K(I_i, P_i) where I_i is
a sequentially allocated or randomly generated initialization vector for
that password.
Why? Separating the master passphrase from the key allows you to change
the passphrase more easily. Individually encrypting the password
entries allows you to pick out just the one you want and decrypt it
individually, and to manipulate the entries (e.g., reordering or
deleting) without having to decrypt anything first. Oh, and the salt
protects against prehashed dictionary attacks. Make it about 64 bits
long.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Larry Kilgallen)
Subject: Re: Has RSADSI Lost their mind?
Date: 20 Jul 2000 10:29:39 -0500
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Mark Wooding) writes:
> Vin McLellan <[EMAIL PROTECTED]> wrote:
>
> [With occasional snippings and minor reformatting:]
>
>> Mark Wooding asked a famous question:
>>
>> Why, in the fall of 1994, did Netscape's management choose to build
>> SSL around RSApkc -- as opposed to D-H/El Gamal -- and RSADSI's BSAFE
>> crypto toolkit?
>
> At this point, a clarification is perhaps in order. My question did not
> address BSAFE (which I thought implemented Diffie-Hellman anyway --
> certainly RSAREF does -- and is therefore a red herring). And it was
> intended to be a technical rather than a political question, although I
> understood at the time, and still do, that it may have a political
> answer.
Although BSAFE implements Diffie-Hellman, what RSAREF does is a red
herring, as RSA Data Security Incorporated typically did not allow
the use of RSAREF in commercial products.
> One of my major concerns in protocol designs at the moment is forward
> secrecy. This concern is motivated by the Regulation of Investigatory
> Powers (RIP) bill, which the UK Home Office is attempting to push
> through Parliament.
If you are concerned about forward secrecy, it does stand to reason
that US export control officials are also concerned, although perhaps
in the opposite direction. Perhaps something that relied on the RSA
algorithm was considered more exportable (ignoring what they actually
do with RSA that might be used to achieve forward secrecy).
Certainly when Public Key Partners was breaking up there was a conflict
regarding whether RSA Data Security Incorporated had the rights to
continue providing Diffie-Hellman in the BSAFE toolkit. Although
RSA Data Security Incorporated ultimately won this dispute, perhaps
the outcome was not certain at the time that Netscape made their
decision.
RSA Data Security Incorporated could have made use of the RSA algorithm
a condition of Netscape's license (which was already using non-standard
terms).
> To pick on a particular case, did requiring Zimmerman to replace his
> solid and efficient modexp code in PGP with the slow and (as we now
> know) insecure RSAREF implementation do anything to improve the
> reputation RSADSI?
It certainly solidified their stance toward other licensees,
that you don't get the good stuff without paying. That may
not be what Free Software advocates want to hear, but it is
the cornerstone of the US economy, and these tensions have
still not been resolved.
> Or, with opposite spin, by
>
> (a) defining the standard data formats for keys, certificates, etc.,
> in terms of an arcane syntax notation and horrific concrete
> representations, and
> they hoped to lock their customers into using BSAFE even after
> 2000-09-20 in a stroke of cynical genius of which even Microsoft would
> have been proud.
I find very little ASN.1 flavor in the BSAFE interfaces, but I find
ASN.1 marvelous to work with in an automated fashion. Perhaps you
are attempting hand-coding, which is a big mistake. There are two
new ASN.1 books out this year. The most troublesome part I have
seen is the PEM encoding which public CAs tend to use for exchange
in web browser windows. It brings back issues of endian-bias which
were solved 16 years ago by ASN.1.
------------------------------
From: [EMAIL PROTECTED]
Subject: RE: Signed Data
Date: Thu, 20 Jul 2000 13:21:41 GMT
In article <8l6lfe$rvh$[EMAIL PROTECTED]>,
hi yo,
Could u then illuminate us as to how does one perform certain security
procedures in web appliacations without depending entirely on the
browsers/server TLS security only?
I guess the question is not clear but the prior question pertained with
performing such activities using common scripting languages...
In my experience (which ain't nything, frankly) i have seen that one
enables the TLS security and thats it.. i've seen the TLS protocol
detail ... agreed it is sufficient for some needs... but how about
transferring control to the web programmer.
regards,
shailesh.
"hoping to learn"
"Yo" <[EMAIL PROTECTED]> wrote:
> No
> Kevin Crosbie <[EMAIL PROTECTED]> escribió en el mensaje de
noticias
> 8l4uj4$[EMAIL PROTECTED]
> >
> > Does IE have a scripting function(VBScript, JScript....) which
provides
> the
> > same function as crypto.signText?
> >
> >
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: how strong is my own encryption?
Date: 20 Jul 2000 13:32:30 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Since what time are books not sold at bookstores and freely obtainable
> on the internet??
I had to get HAC as a special order from Heffers in Cambridge. It's now
available for free download from
http://www.cacr.math.uwaterloo.ca/hac/
Does that count as a precedent?
-- [mdw]
------------------------------
From: "Kasper Pedersen" <[EMAIL PROTECTED]>
Subject: Re: Searching for an algorithm...
Date: Thu, 20 Jul 2000 13:39:48 GMT
"Kasper Pedersen" <[EMAIL PROTECTED]> wrote in message
news:T_Cd5.3392$[EMAIL PROTECTED]...
>
Just thought about it for three more seconds.
BANG!
There, nailed to the wall. It should be safe, as it doesn't matter who
creates the extra x(b)/y(b) sets.
/Kasper
------------------------------
From: [EMAIL PROTECTED]
Subject: New stream cipher
Date: Thu, 20 Jul 2000 13:33:43 GMT
AOTP-Alex One Time Pad stream cipher.
Performance of this implementation is 190 Mb/sec.
It was measured sending 256 byte in loop 777215 times.
Description.
Idea of this algorithm goes up to Vigenere cipher.
Plain text stream is a sequence of bytes.
Key has length 256 byte. The key is used to generate
infinite byte sequence of key stream using finite group
of the order 65536.
Vigenere Tableau is implemented as multiplication table
of finite group of the order 256.
Encryption.
Byte of input plain stream and byte of key stream are
operands of group law of composition.
This gives one byte of output cipher stream.
Decryption.
Byte of input cipher stream and inverse to byte of
key stream are operands of group law of composition.
This gives one byte of output plain stream.
Delphi source code, EXE, description in pdf and
description to view online are available at
www.alex-encryption.de. Please follow links for 'AOTP'
Regards.
Alex.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Thu, 20 Jul 2000 15:44:13 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Searching for an algorithm...
Thomas Luzat wrote:
> I'd like to create a password management program which stores
> passwords the user enters encrypted. Now I wonder which way to do this
> best.
The standard way is to use a salt (a sequence of random data) and
create a hash of the password plus the salt. The salt makes it
impossible to do dictionary attacks (someone build a large database
where each entry contains the precomputed hash for the most often
occuring passwords, such as women names).
> I thought of creating a hash from the master password which is then
> used to encrypt the whole file which contains the passwords (and which
> could be compressed before doing the encryption). Is this a good way
> to handle it?
I've no clue why you need to create a hash of a master password. You
can use the master password itself as the encryption key if you want
to encrypt your user database. This requires, however, that there is
always an administrator available to boot the environment, else one
can't access the user database.
> The next question is which strong and free (!) algorithms could be
> used for creating the hash and encrypting the file. I thought of using
> Blowfish (it's free, isn't it?), but any alternatives would be nice
> (3DES?). I've heard that MD5 could be used for hashing, but also that
> it isn't the best choice nowadays. Any suggestions?
Free hash algorithms are SHA-1, RIPE MD160, Tiger.
Free symmetric ciphers are Blowfish, Twofish, Serpent.
Free asymmetric ciphers are ElGamal, and soon (in September) RSA.
I think one can trust these algorithms above fully, at least
at the moment.
There are other nonfree algorithms which are equally trustable
(IDEA, the RCn family by Rivest/RSAlabs), there are other free
algorithms which are as trustable but slow (3DES), and there
are many free algorithms which aren't that trustable (Mars by
IBM, or those ciphers in the sci.crypt cipher contest at:
http://www.wizard.net/~echo/crypto-contest.html).
------------------------------
** 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
******************************
