Re: New toy: SSLbar

2003-06-26 Thread Mister Lee
Steven M. Bellovin wrote:
 Please don't take this personally...

None taken here either, and I'm the author :)

 From a security point of view, why should anyone download any plug-in
 from an unknown party?  In this very specific case, why should someone
 download a a plug-in that by its own description is playing around in
 the crypto arena.

They probably shouldn't.  Unless they've conversed with me at length and 
decided that I'm nice, or they download the JAR and vet the code themselves.  
IMO this is just something that takes time.  If I work on SSLbar (or other 
plugins) long enough, and they get used, I cease to be an unknown party...  
It'd probably help if I signed the thing, too :)

 How do we know it's not going to steal keys?  Is the
 Mozilla API strong enough that it can't possibly do that?

Presumably it is strong enough to stop that, but I haven't pushed it yet 
(you're talking about personal certs installed in Mozilla, yes?).

 Is it
 implemented well enough that we trust it?  (I see that in this case,
 the guts of the plug-in are in Javascript.  Given how often Javascript
 has played a starring role in assorted security flaws, that doesn't
 reassure me.  But I do appreciate open source.)

Security problems with JavaScript are directly related of the context (or lack 
thereof) in which the code is run.  The entire UI of Mozilla is actually 
bolted together with JavaScript, including the existing SSL certificate 
properties pages.  Unzip the pippki.jar file in your mozilla/chrome directory 
and take a look at content/pippki/viewCertDetails.js and viewCertDetails.xul 
- this is code for viewing certs that comes with Mozilla.  As far as I am 
aware, you can't access any of the juicy stuff from within eg: a web page, 
only from within toolbars and other UI overlays.

Regarding the usefulness of SSLbar itself, its immediate purpose was 
fingerprint display, as a (theoretically) easy means of checking a cert's 
validity yourself, rather than relying on a third party signing.  That list 
of officially sanctioned CAs that comes with browsers just keeps getting 
longer and longer.  I don't know who the hell any of those organizations are, 
or what their policies are...  Anyway, SSLbar could be made much more useful 
if I were to have it (somehow) cache fingerprints or certs, and a flag to 
indicate whether the user has validated them.  Implementing this requires 
further investigation however, and I've just been pointed at this list and 
it's archive, so I have some more reading to do :)



The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: pubkeys for p and g

2003-06-26 Thread Anton Stiglic
I'm not certain I understand your questions, but here are some answers (I
In the DH protocol you have what we call public parameters, p and g.
p is a large prime integer, which defines a group Z*p, g is a generator
defines a subgroup in Z*p.
You can use fix values for p an g.
Now, participants will choose private and public keys.  The private key
is simply chosen as a random number x, whose value is between 1 and
p-1.   The public key associated to x will be y = g^x mod p.
Participants keep x secret and y is public.
You can say that (y, g, p) is the public key, or simply say that y is the
key if g and p (the public parameters) are implicitly known.
Participants can choose a different x and associated y on each execution
of the protocol, or have long term private public key pairs.


The Check Point Firewall-1 Docs insist, that the public keys be used
for p and g for the Oakley key exchange. I ask you: is this

  - which of the two pubkeys will be p, which g?
  - are they both always primes?
  - are they both always suitable generators mod p?

It just seems to me that Check Point isn't entirely sure themselves
here. I'd appreciate a short cleanup...

To my knowledge, g and p are globally defined, either in DH Groups
(which are nothing but pre-defined g's and p's, right?), or
otherwise set constant. Am I wrong about this?


The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]