Cryptography-Digest Digest #579, Volume #9       Sat, 22 May 99 07:13:04 EDT

Contents:
  Re: HushMail -- Free Secure Email (Terry Ritter)
  Re: HushMail -- Free Secure Email (Terry Ritter)
  Re: HushMail -- Free Secure Email ("Roger Schlafly")
  Re: Random permutation (Stephen Weis)
  Re: symmetric boolean functions (Hankel O'Fung)
  Re: symmetric boolean functions (Hankel O'Fung)
  Re: prime numbers and the multplicative inverse ([EMAIL PROTECTED])
  Re: Diophantine equations (Klaus Pommerening)
  Re: Thought question: why do public ciphers use only simple ops like shift and XOR? 
([EMAIL PROTECTED])
  Re: HushMail -- Free Secure Email (David Crick)
  Re: Complexity Question (Harm Anne Schotanus)

----------------------------------------------------------------------------

From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: HushMail -- Free Secure Email
Date: Sat, 22 May 1999 07:26:30 GMT


On Fri, 21 May 1999 22:08:40 -0700, in <[EMAIL PROTECTED]>,
in sci.crypt Chem-R-Us <[EMAIL PROTECTED]> wrote:

>Terry Ritter wrote:
>> 
>> I think it is clearly your problem.  The real issue may have nothing
>> to do with JavaScript.
>
>It certainly is some kind of problem. Whose problem is a subject of
>useless debate. 
>
>IF I enable both Java and Javascript (netscape 4.5 on Linux), the
>sign-in process goes without a flaw, as does accessing and reading
>email. If I disable Java or Javascript, then the screen just turns
>purplish and dies (ala NT's BSOD - which is very disconcerting).
>Re-enabling both is the only way to get the site to work.

Yet you were willing -- even eager -- to assume that disabling
JavaScript did not work on *my* Win95; perhaps it is now time to
consider some sort of problem in *your* far-superior Linux.  

With JavaScript supposedly turned off in my browser, the JavaScript
pages on my site just sit there: they show no results.  My guess is
that JavaScript really *is* turned off, just like it says.  Imagine
that!  And yet HushMail still works for me.  So what are we to think?



>Which leads us to some computing fundamentals "All software sucks,
>just some sucks worse than others. The same goes for hardware."
> 
>The site does claim to be in beta, so a little latitude should be
>allowed for growing pains. However, since this is crypto (the domain
>of the security conscious to the irrationally paranoid), exactly how
>much anamolous behavior is considered allowable?

Yes, it is a new system, still in beta, and deserves some time to
settle down.  Yet there *is* no anomalous behavior on *my* system.
That may be a clue....

Perhaps the browser of the same name is in fact different.  Maybe the
next Linux version will fix your problem.  Or maybe the HushMail guys
can find the problem and work around it.    


>Their effort may one day be laudable, but for now is little more
>than laughable, because, as you point out:
>
>> I'm not saying this is the best possible system, or the best possible
>> security.  Almost anything is going to be compromised to some extent
>> by Windows itself.  But for easy-to-install, fairly-intuitive, and
>> apparently fairly secure end-to-end encryption, this is clearly a big
>> step up for most people.  It is free and easy to use.  If this is the
>> thing that popularizes cryptography to the masses, I can hardly wait.
>> If they someday start charging for it, we can look for something else.
>> 
>> I am nervous about the keys.  If the public key process really is
>> end-to-end (not just a secret key), I would like to have the ability
>> to validate the public key from the other user with a signature.  The
>> way it is now, maybe every key is inherently a man-in-the-middle,
>> re-enciphered at the server for the receiving party.  They say not,
>> but maybe.  But the basic concept is not inherently bad.
>> 
>> This is actually similar to PGP, as far as I know, for I doubt that
>> one PGP user in 50 actually certifies they public keys they use.
>
>I too am nervous about the keys. With PGP I can call and verify a
>fingerprint or key ID, or read them from a website. 

I think calling is fine to validate keys.  But how often have you
actually done that?  And some would argue that calling someone you do
not know and cannot verify is not much authentication at all.  

On the other hand, reading from a website is definitely *not* fine.
The path may be subverted and the fingerprint changed in transit.  

You say that HushMail is currently "laughable."  But accepting either
one of the above certification techniques is more "laughable" than you
are apparently willing to admit.  Yet that's what you call "security."



>I've even done
>it via snail mail. 

And that is better -- although certainly not perfect.  


>With keys I cannot touch, but am simply assured
>are there, how can I be sure that it is nothing more than a
>yahoo.com or hotmail.com masquerading as a secure system.

1) You can look at the source.  

2) You can see the fingerprint of *your* key now.  The remaining step
is to display the fingerprint of the key used for encryption.  That is
not such a big step.  We shall see if that is implemented.  Indeed,
maybe I just missed it.  

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.  

The real difference between PGP and HushMail is that most users will
never use PGP at all, to say nothing of using it securely.  If we are
to bring cryptography into society, we must get many ordinary users to
use crypto every day.  HushMail (or something like it) just might do
that; PGP never, ever, will.  

---
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 07:43:26 GMT


On Sat, 22 May 1999 00:01:21 -0700, in
<7i5ko0$a2k$[EMAIL PROTECTED]>, in sci.crypt "Roger Schlafly"
<[EMAIL PROTECTED]> wrote:

>Terry Ritter wrote in message <[EMAIL PROTECTED]>...
>>   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.
>
>According to Internic,
>
>   Domain Name: HUSHMAIL.COM
>   Hush Communications USA, Inc. 2002 Guadalupe St. #133
>   Austin, TX 78705   US
>
>Even if they have some offshore servers, they could be subject to US
>laws if it is owned by some Texans.

That address would be just west and south of the University of Texas
at Austin.  Perhaps it is in or near Jester Center, about a block west
of the PCL library.  I know nothing of them; maybe they started out
here and moved away.  

But even if not, if the code was developed outside the US, how is
*importing* it a problem?  

---
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: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: HushMail -- Free Secure Email
Date: Sat, 22 May 1999 01:05:17 -0700

Terry Ritter wrote in message <[EMAIL PROTECTED]>...
>But even if not, if the code was developed outside the US, how is
>*importing* it a problem?

I don't know. If circumventing the US export laws were that simple,
Microsoft and others would user a foreign unit to develop outside the
US.

Maybe Hushmail has its servers and developers all outside the US,
and nothing that ever comes into the US ever goes back out. But
if so, I think it is a little strange that they have a US address with
Internic. What country are they really in?

Internic:
http://www.networksolutions.com/




------------------------------

From: Stephen Weis <[EMAIL PROTECTED]>
Subject: Re: Random permutation
Date: 18 May 1999 03:21:42 GMT

Bryan Olson <[EMAIL PROTECTED]> wrote:
:> > If efficient means we want to use the fewest calls to our
:> > random number generator, use the same idea as we used to generated
:> > a uniform choice in [0..n) given a uniform and independent bit
:> > source.  Suppose rand16() returns a random choice from [0..15].

I had an idea on how to permute a range of numbers [0..n] while 
minimizing calls to a random number generating function. Basically, j
ust use the random number as an index into an array. If it is already 
filled, increment modulo n to the next available slot. 

Here's a piece of code which does it:
int[] permute(int n) {
   int[] a = new int[n];
   int rand;
   for (int i=0; i<n; i++)
       a[i] = -1;
   for (int i=0; i<n; i++) {
       rand = (int)round(random()*n);
       while (a[rand%n] != -1) { rand++; }
       a[rand%n] = i;
   }
   return a;
}

To permute n elements, it will make only n calls to random(). I ran 
this over about 10000 runs and kept track of the results. The 
distribution appeared to be even. How could I better test the 
"randomness" of the generated permutation? Could there be some 
problems with naively incrementing to the next available index 
when collisions occur?

Here is some java code with a test function:
========================
class randPerm {
    static final int SIZE = 10;
    static final int TESTS = 10000;

    public static void main(String args[]) {
        if ((args.length > 0) &&
            (args[0].equals("-t")))
            test();
        else {
            int[] perm = permute(SIZE);
            for (int i=0; i<SIZE; i++)
                System.out.print(perm[i] + "\t");
            System.out.println();
        }
    }

    static void test() {
        int[][] counts = new int[SIZE][SIZE];
        int[] perm;

        for (int t = 0; t<TESTS; t++)
            for (int i = 0; i<SIZE; i++) {
                perm = permute(SIZE);
                counts[i][perm[i]]++;
            }

        System.out.println("Array Index/Counts");
        for (int i = 0; i<SIZE; i++) {
            for (int j = 0; j<SIZE; j++)
                System.out.print(counts[i][j]+ "\t");
            System.out.println();
        }
    }

    static int[] permute(int n) {
        int[] a = new int[n];
        int rand;
        for (int i=0; i<n; i++)
            a[i] = -1;
        for (int i=0; i<n; i++) {
            rand = (int)Math.round(Math.random()*n);
            while (a[rand%n] != -1) { rand++; }
            a[rand%n] = i;
       }
        return a;
    }
}








------------------------------

From: Hankel O'Fung <[EMAIL PROTECTED]>
Crossposted-To: 
sci.chem,sci.econ,sci.image.processing,sci.electronics.design,sci.physics,sci.physics.fluid-dynamics,sci.math
Subject: Re: symmetric boolean functions
Date: Sat, 22 May 1999 15:25:45 -0700

Thanks, Mike. You are very helpful. I should have learnt the notation GF(n) in
university, but I can't recall anymore. Also this is the first time I am hear
about the Trace() function.

Best Wishes, Hankel


------------------------------

From: Hankel O'Fung <[EMAIL PROTECTED]>
Crossposted-To: 
sci.chem,sci.econ,sci.image.processing,sci.electronics.design,sci.physics,sci.physics.fluid-dynamics,sci.math
Subject: Re: symmetric boolean functions
Date: Thu, 20 May 1999 18:47:23 -0700

Hi Michael, Ted, Russell and Gary,

Thanks very much. All your suggestions and comments are helpful to me.

> I think I'm getting the hang of where you're heading.

Here's the story. Recently, my boss wrote a paper on neural networks, and wanted
to polish his paper well. To him, it is of utmost importance to get his research
paper accepted by the end of this year, otherwise he may not be able to extend
his contract. If he lose his job, I may lose my job too, but then I'll face a
severe financial (mortgage) problem. So it is important for me to accomplish the
mission, too. Besides, I haven't done math for quite a couple of years, and I
have no experience in neural networks. So you may imagine that I was panic when
I was told to give only some small examples.

Now he had done something on the realization of symmetric boolean functions, and
wanted to extend his result to shift-invariant ones, and hopefully to the
general ones ultimately. Thus he wished to include in his paper some examples
that seemed relevant or meaningful to the engineers or biologists or whoever.
Since he didn't like me to disclose any details of this piece of research to
anybody else, I acted like a secret agent in my previous postings. Although I
didn't like this sort of style, I was (and am) obliged not to say much (sorry).
In fact, he doesn't know that I am seeking help from the newsgroup.

Before I posted the first message, what I thought about was an example on the
parity function. I chose this function because it was defined for any number of
arguments, and it was the XOR operator when it took two arguments --- you may
know that the XOR operator has an important place in the history of the
development of neural networks.

Another symmetric boolean I chose was f(b_1,b_2)=(b_1 OR b_2, NOT(b_1 OR b_2)).
It was a small nice function that was known not to be realizable by a single
layer positive diagonal recurrent Hopfield networks. See

   P. B. Watta, K. Wang, R. Shringarpure, M. H. Hassoun,
   Dynamical Boolean Systems: Stability Analysis and Applications,
   Proceedings of SPIE, vol. 2492, pp. 512--523.

So I could actually manage the examples for the symmetric case before I posted
the first message, but I have no idea on what  application domains of those
shift-invariant boolean functions might be. I am glad to receive helps from all
of you. I must say again that your suggestions are really helpful to me.

Gary, perhaps I am asking too much, but would you please teach me the example
you mentioned? Thanks.

> There is a generalized function similar to checksum using weighted
> constants.
> It's used in ANNs.  You can even use threshold values for step output.  If
> you want you can use a different threshold on the way up than on the way
> down
> though I think this would violate some condition you're wanting.
>
> Why do you need shift-invariance?
>
> You can use multiplication rather than summation and get different results.
> The closer to one the weight is the slower the drop off.  You might even
> want
> to map the two value inputs to numbers close to one.

Regards,
Hankel


------------------------------

From: [EMAIL PROTECTED]
Subject: Re: prime numbers and the multplicative inverse
Date: Thu, 20 May 1999 11:04:01 GMT


> I'm not familiar with IDEA, but every non-zero element in _any_ field
> has an inverse.
>

No, it is a special case.  You can compute it's inverse but not like
the other 65535 integers in the field.

--
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: [EMAIL PROTECTED] (Klaus Pommerening)
Subject: Re: Diophantine equations
Date: 20 May 1999 11:27:28 GMT

In <7hvd11$4jm$[EMAIL PROTECTED]> David A Molnar wrote:
> Recently someone posted an implementation of Boyar's methods for
> predicting an LCG. I regret that I can't locate it right now
> 
http://www.uni-mainz.de/~pommeren/Kryptologie/Material/lcgcrack.c

> (and along with it the correct spelling of the author's name..)
> 
See below.
-- 
Klaus Pommerening  [http://www.Uni-Mainz.DE/~pommeren/]
Institut fuer Medizinische Statistik und Dokumentation
der Johannes-Gutenberg-Universitaet, D-55101 Mainz, Germany
PGP fingerprint: F5 03 CE E7 70 C2 8C 74  BA ED EC 60 83 3B 7C 89


------------------------------

From: [EMAIL PROTECTED]
Subject: Re: Thought question: why do public ciphers use only simple ops like shift 
and XOR?
Date: Mon, 17 May 1999 06:49:17 GMT

Terry Ritter wrote:
> Bryan Olson:
> > Terry Ritter:
> >> Sorry, you still do not understand that the single cipher system has
> >> *no* guaranteed security.  Nothing I could do could possibly be worse
> >> than that.
> >
> >You're arguing against a position no one took.  I long ago granted that
> >there is no proof of computational security, and not once have I
> >written anything that contradicted that.  Your proposal, like the
> >methods you reject, has no (excuse me - *no*) guaranteed security, and
> >thus by the logic you stated above, nothing could be worse than your
> >proposal.
> >
> >Your claim that I still don't understand that a single cipher has no
> >guaranteed security is indefensible.  The reason I don't repeat the
> >fact as often as you (I have noted it on occasion as of course you
> >are aware) is twofold:  first, most of us don't need to be reminded
> >of it every few sentences, and second, I'm comparing two systems
> >_neither_ of which guarantees security.
>
> The reason I keep repeating that no cipher has any guranteed level of
> security is that you do not yet get the implications of this, as we
> see...
>
> >> Cryptanalysis provides *no* lower bound to strength.  Once we finally
> >> realize what that means, we can start to innovate protocols to do what
> >> we can.
> >
> >"Do what we can" is exactly what the crypto community is doing.
> >We can build in large safety factors.
>
> We *can't* build in "safety factors" if we don't know that anything is
> strong.  We don't.  You assume something which is not known.  That is
> unlikely to be a good path toward a correct result.
>
> >We can reject cipher based
> >on flaws that are far from providing practical breaks.
>
> That's fine.  The problem comes when you have no such flaws and then
> release a cipher which may be weak anyway.

And your system is the same, which is why I wrote,
>
> >It makes no sense to reject one method because of lack of proof
> >of security in favor of another that also has no proof of security.
> >
> >> If a single-cipher system is broken, it stays broken.  A many-cipher
> >> system changes ciphers, and starts over.
> >
> >And if a single-cipher system is strong, it stays strong.
>
> Sure.  Unfortunately, the single-cipher system may be weak, no matter
> how overloaded with "safety factors" you think it might be.

Same for the multi-cipher system.

> >So as
> >I've been saying, a many cipher system is less likely to expose
> >all the traffic but more likely to expose a portion of the
> >traffic.  In real-world applications, a 95% chance of revealing 5%
> >of the messages is worse than a 5% chance of revealing all the
> >messages.
>
> But you still haven't gotten it, so your comparisons don't represent
> the situation.

So comment on the comparisons please!  If I'm wrong that your
system, like the single cipher system has provable security of
zero, please post the proof.

> >In terms of proof of security, both types of systems are tied
> >at goose-egg.
> >[...]
> >> >I didn't expect to convince you.  You've made your case, I've made
> >> >mine.  Now we're just repeating the same thing over and over.  I've
> >> >been happy to see that some people have understood my side, and maybe
> >> >some people think you're right.
> >>
> >> My position is fact, not opinion.  Sides are irrelevant.
> >
> >The fact is that the position you have clearly stated implies
> >that people should use a system of unproved and unquantified
> >strength.  It just happens to be your system rather than
> >Schneier's.
>
> The fact is that "my" system changes ciphers.  If there is a break on
> any of those ciphers, that data may be exposed, but only for the
> ciphers which are broken.  And the use of an unbroken cipher ends the
> problem.

That's why I wrote that the multi-cipher system is less likely
to expose all the traffic.  But note that "ends the problem"
is misleading: the new cipher will be used for only one message,
then it's back to the pool.  Some ciphers may be strong, others
weak.  That's why the multi-cipher system is more likely to
expose a significant portion of traffic.

> The fact is that "Schneier's system" does not change ciphers.  And
> that means if the cipher is broken, it exposes data.  And not just
> once, but continually, until the system itself is replaced.

So you've made my case: the single cipher system is more likely
to expose all the traffic, while the multi-cipher system is
more likely to expose a portion of the traffic.

You say you don't like my comparisons, but you can't show
anything wrong with them.  Worse, you don't seem willing to
do comparisons at all.  You complain about the lack of
quantifiable security in one system, but never seem to
notice that yours has zero provable security.  Can you show
that methods which break one cipher or combination of
ciphers will be inapplicable to the next cipher?  How do you
know that the same breaks don't apply to many of the
ciphers?

> My patented and published Dynamic Substitution stuff simply has not
> been addressed.  Neither has Balanced Block Mixing, or Variable Size
> Block Ciphers, both of which are patented and thus published in ink on
> paper, and available anywhere on line.

Great, now you've done _a_ _lot_ of complaining about your ideas
not being addressed.


> >It offers no provable security.  On less
> >formal grounds I argued that the use of 1000 or so ciphers makes
> >it worse.
>
> Too bad your argument does not address the weakness of continuing to
> use a cipher which may have been broken.  I would call that a security
> risk.

Flat out wrong.  I granted from the start that the many
cipher system is less likely to expose all the traffic.  The
problem is that the security risk of the many-cipher proposal,
is worse.

--Bryan

============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

------------------------------

From: David Crick <[EMAIL PROTECTED]>
Subject: Re: HushMail -- Free Secure Email
Date: Sat, 22 May 1999 11:18:07 +0100

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.

Total security would also require users to be running 128-bit crypto
browsers, something which isn't clearly stated on the web site.

public/private keys are stored on their server, encrypted with Blowfish.

Assuming this isn't some Three Letter Agency scam (*g*), they appear
to have reproduced the nym system, but without the remailing.

  David.

> If this ends up being practical, it could obsolete PGP in many cases,
> and might change the practical situation for cryptography more than
> any court decision.
> 
> Also see the CNET story:
> 
>    http://www.news.com/News/Item/0,4,36868,00.html?owv
> 
> ---
> 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]

-- 
+-------------------------------------------------------------------+
| David Crick  [EMAIL PROTECTED]  http://members.tripod.com/vidcad/ |
| Damon Hill WC96 Tribute: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
| PGP Public Keys: 2048-bit RSA: 0x22D5C7A9 4096-DH/DSS: 0x87C46DE1 |
+-------------------------------------------------------------------+

------------------------------

From: [EMAIL PROTECTED] (Harm Anne Schotanus)
Subject: Re: Complexity Question
Date: Fri, 21 May 1999 12:45:48 GMT

On Thu, 20 May 1999 14:36:21 -0700, in sci.crypt you wrote:
 
> lg 4096=12 because the number 4096 can be stored in 12 bits.

not directly correct. Correct is to store 4096 different values you at least need 12 
bits. The actual value stored in the 12 bits is irrelevant.
Besides to store 4096 as an unsigned integer you at least need 13 bits.



------------------------------


** 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
******************************

Reply via email to