Re: More on DRB & OpenSSL

On Thu, 7 Aug 2003, Nathaniel Talbott wrote:

> Hugh Sasse Staff Elec Eng [mailto:[e-mail]] wrote:
>
> > It doesn't encrypt the message, but does a checksum with data
>
> Ah... that isn't enough for me. I want information hiding as well.
>
>
> > From the comments I wrote:
> >
>
> I still don't quite understand... is the nonce generated somehow? If so, how
> do both sides use the same nonce?
>
Server generates nonce (as a function of whatever. ($$, time, current
England cricket score, or something)).
Client sees nonce (world sees nonce, too)
Client sticks passwd on the end of nonce, and hashes the whole thing.
Client sends hash back to server.
Server sees response from client, and reconstructs the hash in the
same way as the client.  If they agree all is OK.
The hash function makes it hard for Eve to guess the passwd, and
impossible to directly calculate it because information is
destroyed.

>
> > I'd rather not post my code, because of exposing weaknesses
> > in it. These will exist because I find cryptographic systems
> > full of subtleties, one of the reasons I have not got to
> > grips with writing SSH code.  This is slightly better, I
> > suppose, than thinking I can write such things and have them secure!
>
> Security through obscurity, eh? ;-)

Well, not entirely.  I know that obscurity on its own is rubbish.
It's more like not advertising that you use a lock which others know
to be weak.  The obscurity is not better than thinking I can invent
crypto systems. The avoidance of encryption is better than such
naivety. I think. And I could be wrong; there always seems to be one
more level of subtlety. But there are areas where the data cannot be sent
in plain sight, so this is not universally applicable.

> I can understand your sentiments. Actually, I was thinking about putting
> together a 'locked-down' version of DRb, and submitting it for peer review.
> As Bruce Schneier said (pardon the long quote),
    "[...]
>   it encrypt and decrypt. You know it works, but
>   you have no idea if it's secure or not. And that's
>   a big deal. What it means is that you can't tell if
        [...]
>   transient faults (i.e., Murphy's Law). Security
>   programming involves making sure something
>   works even in the presence of a malicious adversary
>   who will make exactly the wrong thing
>   fail at exactly the wrong time and do it again,
>   and again, and again, and again to break the security.

And HOW do you test (first) for this?  :-)

        [...]"
>   by Bruce Schneier
>   http://www.counterpane.com/real-world-security.pdf
>
> Which scares me a bit, since it means the software I write can work great
> for my users, and yet be totally insecure - and that insecurity won't be
> discovered either until it's compromised, or until I discover it myself.

Exactly.
>
>
> One thing I'd love to see happen is an easy to use, easy to understand, well
> documented suite of ruby security libraries and tools built around the
> OpenSSL library, so that security is easy(er) to set up and use. Currently

Yes. There are still subtleties, though....
        [...]
> my app, but the documentation and tools for doing that are, at least to this
> idiot, obscure, convoluted and complex. It'd be nice if Ruby emerged as a
> solution for doing this simply and well. I know that there are those that
> fear making these things too easy, as some will be lulled in to a false
> sense of security, but I can't see it being worse than it is now, with the
> issue all too often ignored.

And there are plenty of governments who object to people being able
to provide security as well.  This just adds to the complexity.  Yet
another reason why I tried to work without actual cryptography.

> Anyhow, sorry for the long email. If anyone has any further ideas
> for how to secure things, I'm all ears.
>
>
> Nathaniel
>
> <:((><
>
        Hugh
>
>