More on DRB & OpenSSL

ruby-talk
21

This only works on one machine, and leaves the secret lying around
in memory (@secret). You can’t really pass this object over the net
without exposing the secret. This is the sort of subtlety that
catches me out every time!

I think you may have misunderstood the purpose of this class.

If you are working across two machines, you instantiate a separate copy of
SecureMarshall (with the same shared secret) on each one. You use it to
encode objects, which you squirt across the network, and decode at the other
end. The SecureMarshall object itself is not sent across the network!

OK, right, I’m doing much the same, except where the data cannot be
shared, because the client machines compute it. That is why they
are connected, so they can do their own computation. Then I make
the data I send (in the clear) part of the hashing process.

    [...]

Sure the secret is in memory in @secret. You can’t avoid that - well, you
can read it off disk each time you use it instead, but that’s no more

This is the problem really. I’ve not surmounted this subtlety yet.

secure; in fact you will leave lots of objects in memory which contain the
secret, until the garbage collector picks them up.

Regards,

Brian.

    Thank you,
    Hugh
···

On Thu, 7 Aug 2003, Brian Candler wrote:

On Thu, Aug 07, 2003 at 07:58:59PM +0900, Hugh Sasse Staff Elec Eng wrote:

22

(what was effectively a crayon sketch of CRAM MD5, roughly)

OK. That lets B authenticate A. The main weakness is that if the nonce and

So I have them both ways.

response are sniffed, the password is subject to an off-line dictionary
attack.

Agreed. I don’t know a good way round this. I expect any method
based on Hashing has this misfeature. SHA is said to be better than
MD5 in the RFCs, small help though that is.

And of course, this exchange does not protect the rest of the data in
transit. An active attacker could allow this authentication exchange to take
place, and then substitute the subsequent session data with something else.

Which is why I keep changing the nonce for each bit of dialogue
between the machines, try to ensure (Time(),Date()) that it never
repeats, and make the plain text part of the input to the hasher, so
its authenticity gets tested when the hash is checked.

I’m sure I’ve missed something, though. The phrase “cunning plan”
springs to mind, unfortunately.

Regards,

Brian.

    Hugh
···

On Fri, 8 Aug 2003, Brian Candler wrote:

On Fri, Aug 08, 2003 at 12:03:01AM +0900, Hugh Sasse Staff Elec Eng wrote:

23

OK. That lets B authenticate A. The main weakness is that if the nonce and

So I have them both ways.

response are sniffed, the password is subject to an off-line dictionary
attack.

Agreed. I don’t know a good way round this. I expect any method
based on Hashing has this misfeature. SHA is said to be better than
MD5 in the RFCs, small help though that is.

No, that’s not it. It’s not a weakness of the hash, it’s a weakness of your
challenge-response protocol design. However it’s fine as long as you choose
a strong password (say a true random 128 bit value) which cannot be
brute-forced.

Otherwise you go to a different system altogether - such as public key
authentication.

And of course, this exchange does not protect the rest of the data in
transit. An active attacker could allow this authentication exchange to take
place, and then substitute the subsequent session data with something else.

Which is why I keep changing the nonce for each bit of dialogue
between the machines, try to ensure (Time(),Date()) that it never
repeats, and make the plain text part of the input to the hasher, so
its authenticity gets tested when the hash is checked.

Right, so you’re saying that you calculate the hash over the payload and
the nonce:

    [ payload ] [nonce] [hash]
    ^^^^^^^^^^^^^^^^^^^
                          ^ Hash of (payload + nonce + secret)

But once you’ve done that, you don’t need the nonce in the first place,
which is the point I was trying to make before.

The nonce could still be useful to prevent replay attacks; that’s where the
attacker simply resends a valid signed packet at a later time. But using a
nonce for that purpose requires that every packet is sent in response to a
challenge. A better mechanism is to use timestamps or sequence numbers on
your packets.

That’s what the SecureMarshall class I posted did:

    [ payload ] [ expiry time ] [ hash ]
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                   ^ Hash of (payload + expiry + secret)

You can receive incoming packets asynchronously, and know that they are
valid within a given time window, without having to have a
challenge-response exchange and without having to keep track of which
nonces are “active” (awaiting a response) at any particular instant.

You still have the possibility of replay attack within the timestamp window.
It’s horses for courses. The above mechanism works well for me - I can send
objects off to a completely untrusted person to return back to me at a later
stage (e.g. a subsequent POST of a HTML form), knowing that they have not
been tampered with.

Regards,

Brian.

···

On Fri, Aug 08, 2003 at 01:11:16AM +0900, Hugh Sasse Staff Elec Eng wrote:

24

response are sniffed, the password is subject to an off-line dictionary
attack.

Agreed. I don’t know a good way round this. I expect any method
based on Hashing has this misfeature. SHA is said to be better than
MD5 in the RFCs, small help though that is.

No, that’s not it. It’s not a weakness of the hash, it’s a weakness of your
challenge-response protocol design. However it’s fine as long as you choose

Yes, I see what you mean. Well, it’s not my design really, I
implemented what’s in the RFCs cited earlier. I wouldn’t design my
own, I’ve learned that much! :slight_smile:

a strong password (say a true random 128 bit value) which cannot be
brute-forced.

Otherwise you go to a different system altogether - such as public key
authentication.

OK, I should look into that further, but isn’t that subject to
similar attacks: not dictionary, but the parallel computer based
ones, like DES cracking challenges people set up. Reply off list if
you wish, this could bore the legs of some readers and is getting
less Ruby specific! :slight_smile:

    [....]

Right, so you’re saying that you calculate the hash over the payload and
the nonce:

    [ payload ] [nonce] [hash]
    ^^^^^^^^^^^^^^^^^^^
                          ^ Hash of (payload + nonce + secret)

Yes…

But once you’ve done that, you don’t need the nonce in the first place,
which is the point I was trying to make before.

The nonce gives timeout information, and prevents othere injecting
data into the system. Even if they can forge something convincing
they need the right nonce to be able to do it NOW.

The nonce could still be useful to prevent replay attacks; that’s where the

That’s the sort of thing I mean.

attacker simply resends a valid signed packet at a later time. But using a
nonce for that purpose requires that every packet is sent in response to a

Agreed, unless the packet sent is a challenge in the other direction.

challenge. A better mechanism is to use timestamps or sequence numbers on
your packets.

But can’t sequential numbers be forged easily? (I use time as part
of the nonce, and time alone could be forged: people have had to put
security features into NTP to stop people attacking “time itself”
[There’s a B movie in there somewhere!]).

That’s what the SecureMarshall class I posted did:

    [ payload ] [ expiry time ] [ hash ]
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                   ^ Hash of (payload + expiry + secret)

You can receive incoming packets asynchronously, and know that they are

That can be done with auth in the other direction, can’t it?

    [...]

You still have the possibility of replay attack within the timestamp window.
It’s horses for courses. The above mechanism works well for me - I can send

That’s it. The point I’ve not been making clearly is that one can
provide a level of security and one may think it is good enough. But
there are always subtleties, and I think that it boils down to how
many subtleties one is prepared to consider. The oft-cited thing
about “lines of code you don’t write can’t have bugs” suggests a
parallel: only messages you never have to send will be secure.
It sounds to me as though I may have things about right. Though I
have still probably missed something! :slight_smile:

objects off to a completely untrusted person to return back to me at a later
stage (e.g. a subsequent POST of a HTML form), knowing that they have not
been tampered with.

yes, hashes are particularly good for that.

Regards,

Brian.

    Thank you,
    Hugh
···

On Fri, 8 Aug 2003, Brian Candler wrote:

25

Otherwise you go to a different system altogether - such as public key
authentication.

OK, I should look into that further, but isn’t that subject to
similar attacks: not dictionary, but the parallel computer based
ones, like DES cracking challenges people set up. Reply off list if
you wish, this could bore the legs of some readers and is getting
less Ruby specific! :slight_smile:

I guess you’re right. Bruce Schneier’s “Applied Cryptography” is a highly
recommended read.

Right, so you’re saying that you calculate the hash over the payload and
the nonce:

    [ payload ] [nonce] [hash]
    ^^^^^^^^^^^^^^^^^^^
                          ^ Hash of (payload + nonce + secret)

Yes…

But once you’ve done that, you don’t need the nonce in the first place,
which is the point I was trying to make before.

The nonce gives timeout information, and prevents othere injecting
data into the system. Even if they can forge something convincing
they need the right nonce to be able to do it NOW.

Then it is not a nonce. A nonce would be a random meaningless string - which
could of course include the current date/time as part of ensuring it is not
repeated. But if you are extracting the date/time out of that string and
using it to decide whether you will accept the packet or not, then it’s a
timestamp.

challenge. A better mechanism is to use timestamps or sequence numbers on
your packets.

But can’t sequential numbers be forged easily?

You can’t forge anything which is under the protection of the signature
(i.e. included as part of the hash in the shared-secret algorithm we’re
discussing), because to do so you would need to know the secret.

You keep a counter at the receiver end. Once you have received packet number
7, you will only expect to see packet 8. If somebody replays packet 5, then
you ignore it, because it’s out of sequence. They can’t send packet 9
without knowing the secret.

Regards,

Brian.

···

On Fri, Aug 08, 2003 at 06:36:59PM +0900, Hugh Sasse Staff Elec Eng wrote:

26

Otherwise you go to a different system altogether - such as public key
authentication.

OK, I should look into that further, but isn’t that subject to
similar attacks: not dictionary, but the parallel computer based
ones, like DES cracking challenges people set up. Reply off list if
you wish, this could bore the legs of some readers and is getting
less Ruby specific! :slight_smile:

I guess you’re right. Bruce Schneier’s “Applied Cryptography” is a highly
recommended read.

Right, so you’re saying that you calculate the hash over the payload and
the nonce:

    [ payload ] [nonce] [hash]
    ^^^^^^^^^^^^^^^^^^^
                          ^ Hash of (payload + nonce + secret)

Yes…

But once you’ve done that, you don’t need the nonce in the first place,
which is the point I was trying to make before.

The nonce gives timeout information, and prevents othere injecting
data into the system. Even if they can forge something convincing
they need the right nonce to be able to do it NOW.

Then it is not a nonce. A nonce would be a random meaningless string - which
could of course include the current date/time as part of ensuring it is not

That’s what it is…

repeated. But if you are extracting the date/time out of that string and

And that is what I am not doing. The end that served the nonce
‘knows’ when to expire it.

using it to decide whether you will accept the packet or not, then it’s a
timestamp.

OK, I see what you mean. I think the Concise Oxford Dictionary
definition would stil encompass that, but I won’t press the
point!:slight_smile:

    [...]

But can’t sequential numbers be forged easily?

You can’t forge anything which is under the protection of the signature
(i.e. included as part of the hash in the shared-secret algorithm we’re
discussing), because to do so you would need to know the secret.

Good point. Well, I’ll stick with the nonces for now, I need them
for initial setup, and code re-use is good.

Regards,

Brian.

    Thank you for your input on this.
    Hugh
···

On Fri, 8 Aug 2003, Brian Candler wrote:

On Fri, Aug 08, 2003 at 06:36:59PM +0900, Hugh Sasse Staff Elec Eng wrote: