Cryptography-Digest Digest #581, Volume #9 Sat, 22 May 99 19:13:01 EDT
Contents:
Secure Service Providers ([EMAIL PROTECTED])
Re: Secure Service Providers (David A Molnar)
Re: Looking for ScramDisk/PGPDisk user experiences (Paul Koning)
Re: HushMail -- Free Secure Email (Terry Ritter)
Re: HushMail -- Free Secure Email (Terry Ritter)
Re: RSA Cryptography Question ([EMAIL PROTECTED])
Re: Reasons for controlling encryption (Paul Koning)
Re: HushMail -- Free Secure Email (Terry Ritter)
Re: public/private key authentication? (revisited) ("rosi")
Re: public/private key authentication? (revisited) ("rosi")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Secure Service Providers
Date: Sat, 22 May 1999 16:58:39 GMT
I was just thinking of a cool way to make a secure provider (for let's
say cable).
In this we will assume some things
1. There is a machine in the home, capable of uploading data to the
provider.
2. The data is not encrypted.
We will use the RC4 rng as an example but any other algorithm (BBS
comes to mind) would do.
All you do is when you pay your bill, they give you a x-bit key which
is used to seed the rng (in the case of RC4 we could make this a 128
bit key) then every n-seconds you are required to upload the next RNG
value. If the value fails you lose the connection.
Possible problems:
1. Requires the sever to generate the values
2. Re-sync problems if say you generate one too many (not a prob with
BBS)
An alternative would be to:
1. server sends a number y
2. home system computes the y-th BBS numbers making a 128 bit output
3. uploads result
This could be valid for 30 minute periods or so. And wouldn't require
a lot of cpu time (well if they are not all at the same time).
Just a thought. This could also apply to satelite where a dial-up
connection will authenticate access for a period of time. The box
could shut down if the authentication fails, making encryption not
required.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Secure Service Providers
Date: 22 May 1999 19:03:32 GMT
[EMAIL PROTECTED] wrote:
> All you do is when you pay your bill, they give you a x-bit key which
> is used to seed the rng (in the case of RC4 we could make this a 128
> bit key) then every n-seconds you are required to upload the next RNG
> value. If the value fails you lose the connection.
This sounds like you're basically using the RNG to make a bunch of
one-time passwords. What would be wrong with repeatedly hashing
the seed instead of using RC4 or BBS? One iteration of BBS is a modular
squaring, which for a 128-bit number is 128*128 = 16384 operations to
multiply plus a reduction - at least using the naive O(n^2) for mult.
I haven't counted for RC4, but one hash with SHA-1 is about 760 bit
operations or so.
It may make a difference in the $$$ required for the chip which
does the encryption. I don't know how much that would affect the
cost of the whole system - maybe someone else does?
Just in passing, I'm told that a cable company recently started using
a variant of the Fiat-Shamir scheme in their set-top boxes for
exactly this purpose. anyone know details ?
> Possible problems:
> 1. Requires the sever to generate the values
> 2. Re-sync problems if say you generate one too many (not a prob with
> BBS)
3. Server has to know where the box is physically located, and needs
a quick way to match the box's value to the "correct value for this
location." Unless you don't mind people taking their set-top boxes
to friends' houses.
4. Needs a way to distinguish between an accidentally unplugged box
and one which has been taken out of one location to be loaned to
someone else at another.
> An alternative would be to:
> 1. server sends a number y
> 2. home system computes the y-th BBS numbers making a 128 bit output
> 3. uploads result
> This could be valid for 30 minute periods or so. And wouldn't require
> a lot of cpu time (well if they are not all at the same time).
I think this scales linearly - the number of seeds your server will have
to keep increases by one with every user added to the system. Plus your
server is always online. Even if the model is such that boxes have to be
cheap and the server can be very powerful, this is still going to
be a lot to ask of the server.
Thanks
-David Molnar
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Looking for ScramDisk/PGPDisk user experiences
Date: Fri, 21 May 1999 13:47:39 -0400
Mark E Drummond wrote:
>
> Michel Bouissou wrote:
> >
> > Scramdisk will be excellent for that purpose.
>
> Are there any similar tools for Unices? Not encrypted filesystems but
> simple end-user tools that have the same/similar functionality to
> scram/PGPdisk.
I don't know why you contrast scramdisk with encrypted filesystems;
for practical purposes they are the same.
In any case, on Linux at least you can have an encrypted loop driver,
which is the Linux equivalent of Scramdisk running on a container file.
paul
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: HushMail -- Free Secure Email
Date: Sat, 22 May 1999 21:37:57 GMT
On Sat, 22 May 1999 08:59:42 -0400, in <[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] wrote:
>Is HushMail realated to a New Zealand Product called InvisiMail?
I have no idea. The only things I know about HushMail I got from
their pages or the recent CNET article.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Free Encrypted Email www.hushmail.com [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: HushMail -- Free Secure Email
Date: Sat, 22 May 1999 21:38:32 GMT
On Sat, 22 May 1999 11:18:07 +0100, in <[EMAIL PROTECTED]>,
in sci.crypt David Crick <[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>>
>> Most people on sci.crypt should probably check out the new free
>> encrypted email web site:
>>
>> http://www.hushmail.com/
>>
>> Encryption is end-to-end and occurs locally by downloading a public
>> key Java applet. Source is available. The company is outside the US.
>
>It only remains encrypted between users and hushmail. Any external
>email (i.e. to non hushmail users) will of course be in clear text
>once it leaves hush mail.
Any cryptosystem requires that both ends be in on the same joke. What
alternative did you have in mind?
I guess we could hope for a sort of Netscape crypto, where we download
a free package and use it, but I doubt that would have much success.
That would almost be PGP, which hardly has Netscape-level penetration.
We could think of using the crypto applet off line (and then we could
even do the crypto in our own code), but I don't know how much
advantage that would be. Unless the whole thing is painless, ordinary
users are not going to use it.
Maybe the biggest advantage right now is the foreign source for the
system. I certainly couldn't release any of my systems on the web,
because I live in the US. It does seem surprising that we don't have
competing systems from at least some other countries. Maybe we will
now see that happen.
My attraction to this is the possibility that the approach could
fundamentally change the crypto debate, first by educating large
numbers of users, and next by educating government about what crypto
means to ordinary citizens.
>Total security would also require users to be running 128-bit crypto
>browsers, something which isn't clearly stated on the web site.
I don't like the term "total security," because it invites everyone to
buy into a false reality.
128-bit crypto would be nice, but it seems to me that any real
security should depend more on end-to-end public key validation than
on trusting the HushMail site.
>public/private keys are stored on their server, encrypted with Blowfish.
HushMail needs to be using new random message keys for each email like
almost every serious system; if they aren't, they have problems,
because this would certainly be an expected requirement.
Public keys *have* to be distributed to the far end. They *can* be
stored; that is why they are called "public." Maybe part of what
HushMail brings to the table is an seamless key distribution facility.
And even if keys are not *immediately* validated end-to-end, if they
*ever* are shown to differ, we can write off HushMail. At least this
sort of system allows us to identify the problem.
But if you know they are keeping private ("secret keys"?), I guess I'd
like to know what you mean and where this information comes from.
That would be a big problem. It is hard to imagine that they would
release source if this sort of thing was going on.
>Assuming this isn't some Three Letter Agency scam (*g*), they appear
>to have reproduced the nym system, but without the remailing.
Some remailers have gone to charging for their services. If there
needs to be an economic basis for crypto, advertising seems about as
innocuous as one could get.
Even if it *is* some sort of scam, if we can accept the system as
defined in the source (assuming the system eventually plays real
cryptography) and validate our keys, I don't think we care.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Free Encrypted Email www.hushmail.com [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RSA Cryptography Question
Date: 22 May 99 21:20:02 GMT
Chris Monico <[EMAIL PROTECTED]> wrote:
> m^{phi(n)+1}==m (mod n) for all m.
as long as n is square free, of course.
(e.g. n=12 has a factor of 2^2=4. phi(12)=4:
2^(phi(12)+1)=2^5=32=8 mod 12, not 2 mod 12
(of course, in cryptography, one assumes that the original message m IS
relatively prime to n ... one can always check GCD(m,n) otherwise and if
it is not one, have a factor of n -- very insecure -- having an m which is
not relatively prime to n ... well, if that would happen once in a billion
messages then the encryption is insecure ... for one could simply generate
the small number of a billion random m's and check the GCDs to get a
factor of n. For n=pq, p,q large primes, on the order of, say, 512 bits,
the probability that an "m" is NOT relatively prime to n is
1-(1-1/p)(1-1/q) or about 1/p+1/q or about 1/2^511 -- if everyone
generated a billion "m"s every second for a billion years
(population=10_billion say: [10*10^9]*[31536000*10^9]*10^9
(population*number_of_seconds_per_year*one_billion_years*
one_billion_keys_per_second)
this would be about 3*10^35 random "m"s while one would expect that one
would have to generate about 2^511=6*10^153 such random numbers before one
would find an "m" that is not relatively prime to "n" and which would
allow one to factor n)
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Reasons for controlling encryption
Date: Fri, 21 May 1999 16:29:59 -0400
Andrew Haley wrote:
> ...
> The export controls mean that there is no standard way to interoperate
> secure telecomms. This hampers use just as well than controlling the
> availability of hardware.
Nonsense.
PGP has been a de facto standard for many years. And there are a pile
of RFCs describing secure communications protocols.
Interoperability is a well established capability.
paul
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: HushMail -- Free Secure Email
Date: Sat, 22 May 1999 21:37:47 GMT
On Sat, 22 May 1999 09:09:18 -0400, in <[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] wrote:
>Terry Ritter wrote:
>
>> 3) And since all messages flow through the same system, if we *ever*
>> *do* find a fingerprint difference, we know who to blame. That is a
>> surprisingly significant advantage in crypto: Normally we never know
>> when we are being screwed or by whom.
>
>This may be somewhat over-broad. The parallel with the US Post Office
>is obvious. PO regs are draconian (the PO is the eldest bureacracy in
>the US Gov't). In essence the regs state that while in the USPS has
>custody of your mail, nobody touches the it. No way, no how, no body.
>
>But the regs do not address Others to whom the USPS will temporarily
>surrender custody of your mail.
>
>What think?
I guess we would hope that if the crypto is done right we would not
have those worries. But in practice, there is no absolute security,
so we should hardly be surprised when we do not get it. Even if we
find the USPS *rules* acceptable, if we are interested in security, we
have to assume that reality may be somewhat different.
My point here was that the normal failure mode for crypto is to expose
our messages in secret. If our information is harvested properly, we
never know, and continue to use the same broken system.
In contrast, with something like this HushMail system, *if* the crypto
is done properly, *if* we can get public key validation
(certification) to the far end, the system should be pretty secure
independent of whatever might go on in between. Which doesn't mean
that your PC could not be snooped, or the far-end subverted, who would
then simply tell all. Crypto only does so much.
Real crypto attacks thrive on our inability to know who might have
access to our ciphertext messages, and our inability to know when our
messages are exposed. So if we can pinpoint a single responsible
entity, and detect if our keys do not validate, we are somewhat better
off because we can stop what we were doing and do something else.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Free Encrypted Email www.hushmail.com [EMAIL PROTECTED]
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: public/private key authentication? (revisited)
Date: Sat, 22 May 1999 17:36:14 -0400
Dear Phil,
I think I know what you are asking, but not too sure.
First of all, To be FRANK, I do not know if there is such an
algorithm. Then I doubt there could be one, but this is closely
tied to my next question. What do you mean by encryption?
If there is no 'one-wayness', then there is NOT and that puts
everybody on 'even' ground. I do not see how impersonation
can be 'practically' nullified. If, on the other hand, there is 'one-
wayness' involved, I would love to see that is not categorized
as encryption but I do not seem to see reasonably how. (You
mentioned PK, and think you may be referring to something
'one-way' without being regarded as being 'one-way').
Not here to dampen anything. Would love to also see such an
algorithm or method, even something close.
Thanks
--- (My Signature)
P.S.
I think I should make this explicit as well. If the 'public' thing can
only be used 'one time', it is not really public and, to me, is really
not public.
Phil Howard wrote in message ...
>It seems my news provider has already discarded the thread I started.
>They claim 30 day retention but a post 11 days ago isn't there. I'll
>have to question them about it.
>
>Anyway, I found some replies made to my original posting on Dejanews.
>
>John Savard suggested because of my ham radio call, I was looking for
>a solution that didn't violation ham radio regulations. Well, that
>might in fact be a valid pursuit and I would even be interested in it.
>However, it wasn't why I posted the question in the first place.
>
>What I want is a means to strongly authenticate a connection over the
>network that does not need any encryption to hide anything, without
>using any form of encryption for reasons of both US export restrictions
>as well as possession restrictions in other places (like France).
>
>That's why instead of:
> D(k',E(k,m)) -> m
>I'm really looking for:
> A(k',m,S(k,m)) -> 1 (authentication passes) or 0 (fails)
>
>The essential requirements are:
>
>1. No ability for any observer to impersonate the sender.
>2. No ability for the recipient to impersonate the sender.
>3. No man-in-the middle attack.
>
>Number 2 sort of rules out shared secret. If that were not a requirement,
>then I could simply hash (such as with RIPEMD-160) the message and secret
>together, send the hash and message to the other end, and there hash the
>message with the supposed same shared secret and compare received hash with
>the stored hash. But in order to meet #2 I'd have to have N*N-N secrets
>for N parties and provide for N*N-N secret channels to exchange keys. It
>would be better to have a public private key scheme like PK crypto has.
>
>So if I can generate k and k' and publish k' and then generate a hash with
>k that can be authenticated with k' (doesn't matter if it can also be
>authenticated with k) that would be what I am looking for.
>
>That would allow me to post a message to the public and allow everyone to
>authenticate the message, and not just one recipient. So it might well be
>good in ham radio, too, for this reason.
>
>Any algorithms?
>
>--
>Phil Howard KA9WGN
>[EMAIL PROTECTED] [EMAIL PROTECTED]
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: public/private key authentication? (revisited)
Date: Sat, 22 May 1999 17:28:09 -0400
Dear Phil,
I think I know what you are asking, but not too sure.
First of all, To be FRANK, I do not know if there is such an
algorithm. Then I doubt there could be one, but this is closely
tied to my next question. What do you mean by encryption?
If there is no 'one-wayness', then there is NOT and that puts
everybody on 'even' ground. I do not see how impersonation
can be 'practically' nullified. If, on the other hand, there is 'one-
wayness' involved, I would love to see that is not categorized
as encryption but I do not seem to see reasonably how. (You
mentioned PK, and think you may be referring to something
'one-way' without being regarded as being 'one-way').
Not here to dampen anything. Would love to also see such an
algorithm or method, even something close.
Thanks
--- (My Signature)
P.S.
I think I should make this explicit as well. If the 'public' thing can
only be used 'one time', it is not really public and, to me, is really
not public.
Phil Howard wrote in message ...
>It seems my news provider has already discarded the thread I started.
>They claim 30 day retention but a post 11 days ago isn't there. I'll
>have to question them about it.
>
>Anyway, I found some replies made to my original posting on Dejanews.
>
>John Savard suggested because of my ham radio call, I was looking for
>a solution that didn't violation ham radio regulations. Well, that
>might in fact be a valid pursuit and I would even be interested in it.
>However, it wasn't why I posted the question in the first place.
>
>What I want is a means to strongly authenticate a connection over the
>network that does not need any encryption to hide anything, without
>using any form of encryption for reasons of both US export restrictions
>as well as possession restrictions in other places (like France).
>
>That's why instead of:
> D(k',E(k,m)) -> m
>I'm really looking for:
> A(k',m,S(k,m)) -> 1 (authentication passes) or 0 (fails)
>
>The essential requirements are:
>
>1. No ability for any observer to impersonate the sender.
>2. No ability for the recipient to impersonate the sender.
>3. No man-in-the middle attack.
>
>Number 2 sort of rules out shared secret. If that were not a requirement,
>then I could simply hash (such as with RIPEMD-160) the message and secret
>together, send the hash and message to the other end, and there hash the
>message with the supposed same shared secret and compare received hash with
>the stored hash. But in order to meet #2 I'd have to have N*N-N secrets
>for N parties and provide for N*N-N secret channels to exchange keys. It
>would be better to have a public private key scheme like PK crypto has.
>
>So if I can generate k and k' and publish k' and then generate a hash with
>k that can be authenticated with k' (doesn't matter if it can also be
>authenticated with k) that would be what I am looking for.
>
>That would allow me to post a message to the public and allow everyone to
>authenticate the message, and not just one recipient. So it might well be
>good in ham radio, too, for this reason.
>
>Any algorithms?
>
>--
>Phil Howard KA9WGN
>[EMAIL PROTECTED] [EMAIL PROTECTED]
------------------------------
** 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
******************************
