On Apr 15, 2010, at 12:39 AM, Carey Bishop wrote:
> As your queries are related to Growl for Window, it would probably be best to
> send them to the Growl for Windows Group:
> Email: [email protected]
> Online: http://groups.google.com/group/growl-for-windows
My queries are related to GNTP, which Growl for Mac is moving
toward using, too. I hadn't realized until an hour after my first
message that the Growl for Windows is already fairly far along
and has a ton of clients already.
That's unfortunate, because this looks like a system crypto
problem that will require significant rework of the protocol
to overcome.
> In theory, the purpose of the salt of is to prevent replay attacks, so I
> believe that the Growl for Windows application should reject messages that
> use the same salt, but I know from experience that it currently does not.
I don't believe that is what salt is supposed to be for. Salt is
supposed to make it harder to do some sorts of cryptanalysis.
Actually, I believe the way salt is used in GNTP, it actually hurts
the cryptographic strength to use a different salt every time.
Typically, when you an encrypt the password "foobie", you encrypt
it with some random salt. Then, when you're looking down through
a list of passwords, you can't readily see that two different people
used "foobie" as a password because they both used different salts.
It defeats the purpose of the salt if everyone knows that
xxABCDEFG and yyMNOPQRS are both the same password just
encrypted with different salts.
The way that most systems prevent replay attacks is something
like this:
h := hash( salt + timestamp + my-ip-address + my-socket-port + password );
transmit( salt, timestamp, my-ip-address, my-socket-port, h, message );
The receiving end verifies that the ip-address and port jive with where
the message was received from, the timestamp isn't too far in
the past or future (have to give a bit of grace here because no
two computers agree on the time, plus there is network latency),
and the hash works out. Of course, NAT firewalls make the port
kinda and IP address kinda awkward for the sender to figure out.
But, just the timestamp is a decent start.
Note: this doesn't prevent someone who can quickly grab the same
ip-address and socket-port from sending the same message or
composing an entirely different message unless the server side
rejects repeated salts. But, tracking which salts have already been
used is a bookkeeping headache for both sides. This is especially
a headache for a client like a command-line tool to send a message.
Such a tool would start up, send one single message, and exit. It
could do this several times per second. It probably wouldn't get the
same port each time, but it would have the same IP address and
timestamp (though hopefully different salts, unless the salt is done
with the typical srandom( time( NULL ) ) or without even using
srandom() at all).
I love Growl for Mac and Growl Talk. I thought GNTP was a bit
overblown on verbiage, but was fine with it until I started to try
to deal with the authentication and encryption portions. Now, I
don't want to have to do GNTP at all unless some of the crypto
troubles get addressed.
So, I suppose my questions below have now become more like:
* Does the encryption in the Perl library I link to below
actually succeed in publishing encrypted messages? If so,
then, I think the server's got an encryption bug that leaves
it worse off than even the Protocol document indicates it would be.
* Are these the proper fora for discussing this issue?
* Should I prepare a new rev of the GNTP protocol spec
that I think uses crypto better than the 1.0 spec and
send it around for discussion?
Briefly, the main GNTP/1.X line should have a hash algorithm,
salt, and hash of:
main (encrypted or not) message header bytes + salt + password
Each binary object should have (in addition to the Identifier and Length)
a hash algorithm (or assert the same hash algorithm everywhere),
salt, and a hash of:
(encrypted or not) binary data + salt + password
Alternately, to take advantage of the fact that the Identifier may already
be a hashed value, the new binary object header should have a hash of:
hash( (encrypted or not) binary data ) + salt + password
Thanks,
Patrick
> On Thu, Apr 15, 2010 at 4:10 PM, Patrick Stein <[email protected]> wrote:
>
> In the binary Growl Talk protocol, authentication was done by
> computing a hash value for the whole message + a secret password
> and appending this hash to the message. If someone could eavesdrop
> on the Growl Talk communication, they could replay messages at
> a later date without having to know the secret password. However,
> they could not craft new messages for an application without knowing
> the secret password.
>
> I'm reading the GNTP spec here:
> http://www.growlforwindows.com/gfw/help/gntp.aspx
>
> and looking at this sample implementation here:
> http://github.com/mattn/perl-Growl-GNTP/blob/master/lib/Growl/GNTP.pm
>
> (which looks reasonably to spec except that it doesn't support
> the x-growl-resource:// referencing)
>
> And, it looks to me like the authentication got thrown out
> inadvertently (in both the protocol spec and the sample Perl
> code there). It looks like now anyone who can eavesdrop on
> an encrypted or authenticated channel can both resend messages
> at later times *and* craft new authenticated messages from scratch
> without having to know the secret password.
>
> Here's all that I have to do:
> 1. intercept a message
> 2. copy out the keyHashAlgorithm, keyHash, and salt.
> 3. craft any unencrypted message that I want using the same
> keyHashAlgorithm, keyHash, and salt
>
> GNTP/1.0 NOTIFY NONE keyHashAlgorithm:keyHash.salt
> <any message that I desire>
>
> This new message will have a valid keyHash since the keyHash
> did not depend on the message contents in any way. The only
> way this might still be okay is if the server side keeps track
> of every keyHash/salt it has ever received and only lets each
> get used once. This would be a nightmare on both ends of the
> socket.
>
> The situation looks to be even worse in the sample Perl code
> that I was looking at because it appears (and, maybe I am reading
> it incorrectly, but it appears) step #5 is omitted from the
> Key Generation described in the protocol document and the actual
> key itself is sent in place of the keyHash. This means that I
> can even send encrypted (and authenticated) messages without
> ever needing to know the password since I already have the
> encryption key in my hand. I hope the server side is not skipping
> step #5 and will reject all of the encrypted messages generated
> by that Perl code.
>
> Can somebody please clarify?
>
> Even if we don't bother correcting the protocol to prevent
> replays, we should at least make sure you cannot send arbitrary
> authenticated (or encrypted!!) messages without the secret
> password.
>
> Thanks,
> Patrick
>
> --
> You received this message because you are subscribed to the Google Groups
> "Growl Discuss" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/growldiscuss?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Growl Discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/growldiscuss?hl=en.
