Cryptography-Digest Digest #87, Volume #11 Thu, 10 Feb 00 08:13:01 EST
Contents:
Re: Does hashing an encrypted message increase hash security? (David Hopwood)
Re: Continually Secure Password/Pin (David Hopwood)
Re: Anybody know about this flaw? (Greg)
Re: Anybody know about this flaw? (Greg)
Re: NIST, AES at RSA conference ("Joseph Ashwood")
Re: I'm returning the Dr Dobbs CDROM ("Douglas A. Gwyn")
Re: Strip Security (Gordon Walker)
Re: Anybody know about this flaw? (No Brainer)
Re: Guaranteed Public Key Exchanges (No Brainer)
Re: NIST, AES at RSA conference ("Rick Braddam")
Re: NIST, AES at RSA conference (Alan Braggins)
Re: New standart for encryption software ([EMAIL PROTECTED])
Re: Guaranteed Public Key Exchanges (Roger Gammans)
Persistent vs Non-Per DH for Voice ([EMAIL PROTECTED])
----------------------------------------------------------------------------
Date: Thu, 10 Feb 2000 05:24:29 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Does hashing an encrypted message increase hash security?
=====BEGIN PGP SIGNED MESSAGE=====
Erann Gat wrote:
>
> Suppose I do the following:
>
> 1. Generate a 128-bit MD5 hash of a message.
> 2. Generate a second 128-bit MD5 hash of the same message encrypted
> with (say) Blowfish using an N-bit key.
> 3. Concatenate the results together to form a 256-bit hash.
>
> Does the resulting 256 bit hash have any more security than the
> original 128-bit MD5 hash by itself?
It depends which security property you're looking at:
one-wayness: provably no (just ignore the second half of the hash)
collision resistance: probably yes
second pre-image resistance: probably yes
psuedo-randomness: provably no (if the first half is not pseudo-random
then the hash as a whole would not be considered
psuedo-random)
> How much more?
For collision and second pre-image resistance, I've no idea.
> What if the Blowfish encryption key is known
It doesn't appear to matter whether the key is known when considering
one-wayness and pseudo-randomness.
For collision and second pre-image resistance, I don't know (but note
that a function that requires secret information to evaluate
typically wouldn't be classified as a hash; it would be classified as
a MAC instead, and those have different security requirements).
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOKJLUTkCAxeYt5gVAQHYTAf+NbfilZPFbY/3HB5RowJwt/ZhP1dwxUYY
LWegMriXJFXxV8XlGD4GYIA9C4z7Xorzy4FzaZ7vJ/SS99onfHuevLR8VoB+Z+re
tC8AfWVHq8b3FiFGVAHQrp0EAH1e5LIYZKVeroPvETuaY7cnI0hBNv4IQyR/rR4F
1ZNPz5nuwjfNDysUlz5U+O34PfKEFkGv4QK01nywaLOSwSTaG9M7dS5rxtxSTBsL
Qf8K2cO8cMf0GdGAN7lLoQxeZ0KrsLDr89vNT3xrBoiD9tVj3O4xSiBPQ7lGTXfO
h5ANpSTgj94xIjSzNZru06Dwn8pbNT7k3AZ3edpI2t6+iGahMU+3Sg==
=J7aI
=====END PGP SIGNATURE=====
------------------------------
Date: Thu, 10 Feb 2000 06:48:09 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Continually Secure Password/Pin
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
>
> When creating and using a user/password account on the web why isn't
> the following method used:
>
> Client types in user name and password, clients computer sends server
> user name and the one millionth iterative one way hash of the password.
> Server creates user name and stores said hash.
>
> When logging on first time user sends user name and the 999,999th
> iterative hash of the password. Server authenticates by hashing this
> and comparing it to last stored hash. On acceptance it allows access to
> account and updates servers hashed password to the new 999,999th
> iteration.
>
> Next time user logs on he uses the 999,998th iteration and so on.
This protocol was used by a system called S/Key, and is described in
section 3.2 of Applied Cryptography, 2nd ed.
Here are some weaknesses:
- It's possible to do an off-line dictionary attack on the password.
I.e. an attacker can intercept one session and then test likely
passwords off-line.
- If someone impersonates the server, they get a hash which is
password-equivalent (for one use).
- If the user has the same password for more than one server then
the protocol is not secure. (Perhaps this could be fixed by using
the server name as a salt.)
- It's easy to do a denial-of-service attack by causing the user and
server to get out of sync (this can also happen accidentally).
- The protocol doesn't establish a shared secret key between the user
and server, so after authentication, an attacker can hijack the
session.
However, I don't think that any of these problems are the reason
why the most common authentication used "when creating and using a
user/password account on the web" is the (totally insecure) HTTP
Basic authentication. The reason for that is that the information
on most sites that use passwords is not really worth protecting -
they only have user accounts for the purpose of collecting
information about users (or sometimes for no discernable purpose
at all). I have accounts on several web servers with the username
"dhopwood" and the password "foobar", and I couldn't really care
less about whether anyone hacks into them.
Some of the more clueful sites that do have something worth protecting,
first set up an SSL session, and have the user enter the password
into a form which is sent over SSL. This has the virtue of using an
existing widely implemented protocol, and apart from users tending
to use the same password for more than one server (which may not
necessarily trust each other), it is quite secure.
Also, it solves the problem of securely distributing (or allowing
the user to choose) an initial password, which is something that many
password protocols gloss over, or assume to be done out-of-band.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOKJe3DkCAxeYt5gVAQGMBQf+JnrLfIm+yYTWpKitxlTyzQNWBNSUdS4l
VyvodixgGmpYU11YbEOu0ynGbsnQmdbwBl0U0GTysWOAnTC59bXAohGDVnSyPrYv
1ibd2C3nphcazAxUpt0d8PZRogICj96QIZpirkdEbzBgHS+8ykB6t+EekxN9L56V
/hFzUMm6C8K1hKJdsOiaAiIcDJZI3Apyow+YD2ap+3Ac8teG1r3dl5jrZRhNS7aK
uNaHiSrin+RmpQJCIGOs7IIH9Vkym71FFwLR3uFCTmSvoZm6smAvKmtvn/Cfyc+y
sFD+xPY+j84KmuoQpj75Alzm7+1zWqqvrsyfS+rhPfzve67bjb9IRg==
=ZXyd
=====END PGP SIGNATURE=====
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Anybody know about this flaw?
Date: Thu, 10 Feb 2000 08:23:29 GMT
> Well, the fact that you're using PUBLIC keys means that interception
> is useless to an attacker. The beauty of public key crypto. Deriving
> the private key from the public key is VERY difficult, if not
> impossible.
I think what he was getting at was that if there was no other means of
communicating between Alice and Bob, then Bob would not be certain that
the public key he receives was from Alice or "Middle Man Mark". In
which case the answer is, no there is no way to secure communications
by using public keys only. One needs an alternate form or channel of
communications to verify the owner of the public key.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Anybody know about this flaw?
Date: Thu, 10 Feb 2000 08:25:55 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Dan Day) wrote:
> On Wed, 09 Feb 2000 23:50:14 +0800, No Brainer <[EMAIL PROTECTED]>
wrote:
> >I was wondering if anyone knows of a secure way to exchange public
keys
> >between two people via Internet e-mail without using any other form
of
> >communication?
>
> The whole point of a "public key" is that it doesn't MATTER if it's
> intercepted. You don't NEED a "secure way" to exchange them.
> You could publish them in the newspaper if you like.
A newspaper constitutes another form of communication. The answer to
his question is no, there is no way. A public key must be verified and
it cannot be done over the internet.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Thu, 10 Feb 2000 01:01:54 -0000
> On the other hand, if
> someone can convince me that there is an actual
*contradiction* in my
> belief that multiciphering (with non-groupy ciphers) must
increase
> strength at least by the amount of processing effort, that
will, of
> course, change my belief.
While I haven't had the time yet (and I probably never will)
to build it into an actual proof, the outline is as follows.
Given a function f() with output confined to a space k,
given any input (of a value in k) to f() the odds of an
identical output is at least 1/k for a further reapplication
of the function f() n times the odds of there existing an m
(m<n) such that f^n() = f^m() is at least (n-1)/k (m must
not be negative, but may be zero indicating the plaintext)
When n = (k +1) there must exist an m < n
Given this f^n() (for n = k+1) is equivalent to f^m(), a
goal that is computationally easier to achieve.
It is also possible to change f() at some point in the
stream and the proof is likely to still apply provided that
k remains fixed across functions (although a similar proof
will exist).
Based on this I assert that there is a limit to the number
of times a function f() (including any cryptographic
algorithm) can be applied is K and in the case of a
cryptographic algorithm of length x the maximum number of
times that algorithm can be applied without being gaurenteed
to provide a reduction of strength is 2^x.
In short, I can't prove that applying an algorithm 3 times
forms such a decrease, and I believe that for most
non-groupy ciphers that tripling will likely increase the
security, there is a limit to how far we can take it.
Joe
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: I'm returning the Dr Dobbs CDROM
Date: Thu, 10 Feb 2000 09:10:06 GMT
wtshaw wrote:
> Even html is better than muddy images.
What does HTML have to do with it?
------------------------------
From: [EMAIL PROTECTED] (Gordon Walker)
Crossposted-To: comp.sys.palmtops.pilot,alt.comp.sys.palmtops.pilot,comp.sys.handhelds
Subject: Re: Strip Security
Date: Thu, 10 Feb 2000 09:18:41 GMT
On Tue, 08 Feb 2000 20:31:17 GMT, [EMAIL PROTECTED]
(Jim) wrote:
>>to a three digit pin. What is the method of determining this, and what
>>must be taken into account for more complex systems that include alpha
>>numeric placeholders.
>
>AFAIK, for non-digits you need c=n! (c=n factorial).
Only if you require that the same character not be used twice in the
PIN, ie. that AAB is not allowed. If repetition is allowed then the
number of combinations is s^n where s is the number of symbols and n
the number of characters in the PIN.
--
Gordon Walker
------------------------------
From: No Brainer <[EMAIL PROTECTED]>
Subject: Re: Anybody know about this flaw?
Date: Thu, 10 Feb 2000 17:26:24 +0800
Paul Schlyter wrote:
> In article <[EMAIL PROTECTED]>,
> No Brainer <[EMAIL PROTECTED]> wrote:
>
>
> > I was wondering if anyone knows of a secure way to exchange public keys
>
> Why would you want to do that? The keys are public, aren't they?
> For public keys, no security is needed.
>
> > between two people via Internet e-mail without using any other form of
> > communication?
> >
> > Also, would the proposed system work if "someone unbeknownst to us" was
> > intercepting and modifying the key exchanges?
>
> If you want to agree upon a secret key with someone else, when
> communicating over some tapped communication medium (telephone,
> email, snailmail, whatever - assuming an eavesdropper is listening to
> everything you communicate), you could use the algorithm of
> Diffie-Hellman.
>
> Or you could use RSA: send the other person your public key, and have
> him encrypt the secret data with you public key and send it to you.
> To decrypt these data, your secret key, known only by you, will be
> needed. Now you have a secret session key, and you can use that to
> exchange whatever data you want, with whatever encryption algorithm
> you want.
Paul,
That's all well and fine but what about a middle man attack?
------------------------------
From: No Brainer <[EMAIL PROTECTED]>
Subject: Re: Guaranteed Public Key Exchanges
Date: Thu, 10 Feb 2000 17:29:39 +0800
Darren New wrote:
<snip>
> Ask it a different way. You and I are "unknown to each other." If you want
> to exchange keys with *me*, why? You couldn't even verify I'm not the man in
> the middle if you met me face to face, could you? Calling me on the phone
> won't help if you don't know my voice. Etc.
>
Paul,
I totally agree, but *how* or *is* there a way to do it securely?
------------------------------
From: "Rick Braddam" <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Thu, 10 Feb 2000 04:36:52 -0600
"David Wagner" <[EMAIL PROTECTED]> wrote in message
news:87tpt9$pi4$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>, Terry Ritter
<[EMAIL PROTECTED]> wrote:
> > It is clear to me that you think all we need to do is have some
> > academics check out candidate ciphers (even though we really don't
> > know how much effort anyone in particular has put into doing that),
> > then society should use the result.
>
> Terry, it seems to me that your statement is primarily subjective in
> nature: You are not personally comfortable with the level of assurance
> provided by the AES candidates.
Maybe Terry's concerns are similar to mine. I am not comfortable with
the standardization process itself, and the likely result. If one cipher
is selected as the standard, it very likely will be widely implemented
as the only cipher used. Years down the road, if a weakness is found or
the cipher broken, the news may be suppressed for an extended period of
time to prevent panicking everyone while a new standardization process
is implemented. If this came about, how long might our financial or
personal information be compromised before new methods are developed and
implemented? Many, much better educated than I, might think that this
possibility is so remote as to be beneath consideration. I think that it
is inevitable.
The danger can be averted. One cipher can be selected as "must
implement", the others selected as "may implement". Procedures can be
put in place to evaluate new candidates *as they are developed* and add
them to the "may implement" list. The standard could restrict business
with the US Govt to the "must implement" cipher while implicitly
endorsing the others (for other uses) by their inclusion in the
standard.
Were the AES candidates developed *just* for the standardization
competition, or were they already in development? In other words, did
the AES competition stimulate the development of ciphers which may not
have been developed without it? I think we need a continuous AES
competition, with no limit on the number of "may implement" ciphers.
Different classes of users have different requirements for ciphers, and
the more "approved" ciphers available the more likely one of them will
be the best fit for a class of user.
Just some random thoughts and concerns. I really appreciate the views
you and all the other contributors to sci.crypt have presented. Thank
you.
Rick
------------------------------
From: Alan Braggins <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: 10 Feb 2000 11:57:04 +0000
[EMAIL PROTECTED] (Terry Ritter) writes:
> with any reasonable probability. And we already know that the problem
> is not restricted to the mathematical definition of groups, so there
> is no technical name for it. In the end, adding a non-groupy
> assumption would seem to be reasonable progress.
But unless you have a technical _definition_ for "groupy" more precise
than "causes this sort of problem", you're just saying "we can prove
that for those ciphers where there is no problem, there is no problem,
but we can't be sure which those ciphers are". Which doesn't seem like
progress at all.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: New standart for encryption software
Date: Thu, 10 Feb 2000 12:19:32 GMT
In article
<[EMAIL PROTECTED]>,
Eric Lee Green <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > I wonder if Entrust, Verisign, Data Fellows ...are going to comply
with
> > your request or suggestion.
>
> First of all, Verisign is a public key repository. They do not
themselves
> encrypt any of your data, they merely store your public key so that
somebody
> else can encrypt/decrypt your data.
That is not quite accurate. The master Scret key (generated by Versign)
signs all your certificates...presume that the system (potentially)
could sign other certs which you dont know about...
Entrust, as well as a CA , Has a Key Key generation system...where the
System actually Generates not only certifiactes..but your Secret/Public
key pairs...and it also has a history log of all key pairs generated for
a user...They also generate the key pairs , in duplicate, for key
escrow...
So if you dont know what the hell the system is doing inside...you have
to trustwhat the software is doing...
>
> Secondly, there are many, both overseas and in this country, who
believe that
> most of the closed-source cryptography products contain "back doors"
allowing
> law enforcement agencies and "no such agencies" to gain access to the
contents
> of encrypted communications. Whether this is true or not does not
matter. What
> matters is that most Europeans will *NOT* use an American-made
closed-source
> cryptography product, because they view such products as containing
NSA back
> doors.
Is this an assumption, or based on hard facts???
European customers have had to put up with Netscape's 56 bit SSL
encryption....I dont see any 128 bit European Browser???
(Not that closed-source European products are any better... eg.
it was
> revealed that at least one Swiss cryptography vendor put modifications
into
> their machines at the behest of the NSA to leak key material as part
of the
> data stream).
>
> One reason that PGP is so popular (and so hated by most closed-source
vendors)
> is because you can go to http://www.pgpi.com and download the source
code,
> examine it yourself, and verify that if there's a back door in there,
it's a
> mighty subtle one.
OK but how many people do you think can actually download the source
code and compile it for their platform...I suggest less then 1 % of all
PGP users...
Unless you compile and run the compiled code yourself...you have no
gaurantee of 1-1 equivalence between the binary and the source..
As I see it, probably companies are unwilling to reveal the source code
of their products for competitive reasons... PGP is a very special
case...
Not that I, personally, would bother doing so...
but you
> can bet that all of PGP's competitors are doing so at this very
moment, and if
> they could find a weakness, there would be papers submitted to various
> journals at this very moment demonstrating those weaknesses. That is
what
> gives me confidence that PGP, if compromised, is not significantly
> compromised. I have no such confidence regarding closed-source
cryptographic
> software.
>
> --
> 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
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Roger Gammans)
Subject: Re: Guaranteed Public Key Exchanges
Date: Thu, 10 Feb 2000 12:36:58 GMT
In article <[EMAIL PROTECTED]>, Darren New wrote:
>No Brainer wrote:
>
>One of my bosses recorded himself speaking his own PGP fingerprint and put
>it up on his web site as a .au file.
Of course this is open to a splicing attack on the audio file..
You just have to generate a key which has the same which has
no digits in the fingerprint that the original doesn't have.
Oh, and be able to replace the key and audio authentication files.
TTFN
--
Roger.
------------------------------
From: [EMAIL PROTECTED]
Subject: Persistent vs Non-Per DH for Voice
Date: Thu, 10 Feb 2000 12:38:44 GMT
A number of Voice encryption systems (PGPFone etc)have been developed in
the past using Non-Persistent DH using Secret Sharing to ensure Forward
Secrecy. The DH keys are volatile and last only for the session
I would like to know, if the technology of using Persistent Keys ( DH or
RSA) is more secure for voice communications or a better method
(authentication, Integration with digital certs etc).
One can envision using a smart card with Secret/Public key pairs for
encryption and authentication.....
Would like input on these two approaches...
The recent starium startup seems to go for the first approach....But
that is just a hint..they have not published any details...they have a
smart card, I guess for authentication only.
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
******************************
