On Apr 15, 2010, at 2:12 PM, briandunnington
<[email protected]> wrote:
On Apr 15, 8:58 am, Patrick Stein <[email protected]> wrote:
On Apr 15, 2010, at 10:43 AM, Brian Dunnington
<[email protected]
> wrote:
replay attacks are
possible and were a known compromise in deciding on the current
system.
I don't think it's really necessary to fight off replay attacks.
Someone mischievous could keep resend a message over and over, but it
shouldn't be hard to deal with such persons in meatspace. ;)
agreed 100%
your main point though about being able to intercept the
keyhash.salt
and re-use it is valid. i would love to come up with a workable
solution that the Mac guys can implement as well.
In the Growl Talk protocol, authentication worked fine. All it would
take on GNTP is rather than sending the password hash sending the
hash
of the body + password.
i was worried that we would risk getting into a chicken-and-egg
situation with encrypted requests (you need the key to encrypt the
message body, but you need the encrypted body to generate the key
hash), but that isnt true.
the *key* is generated in step #4 and can then be used to encrypt the
message. once that is done, the *key hash* (generated in step 5) could
be generated. (i am assuming that the key hash is using the password +
encrypted body so that the receiver doesnt have to first try to
decrypt the body with a potentially invalid key).
that would also mean that 'body' means each individually-encrypted
section (so that binary resources are still encrypted separately). for
binary sections, we have a few options:
1. add new header(s) to indicate the section hash, hash algorithm, and
salt
2. add new header(s) to indicate the section hash and salt (require
and assume the same algorithm as the main body)
3. add new header(s) to indicate the section hash (require and assume
the same algorithm and salt as the main body)
4. no changes (require and assume the same algorithm and salt as the
main body, as now)
#4 would mean that an attacker could intercept a message and, although
they could not modify the main body or the number of binary resources,
they could swap out a binary resource for a different one. if that is
unacceptable, i would think #3 would be sufficient. the salt is still
serving its purpose even if it is reused for binary items in the same
message (in fact, that is how the IV is currently used). i think that
#1 is probably overkill, since i cant think of anyone (or any reason)
why you would want/need to use a different algorithm for each section.
i know that Mac support is still nascent, but i would really like to
see these encryption changes labeled as GNTP/1.1. there are a lot of
client libraries already written to the current 1.0 spec and it would
be nice to be able to transition to the new spec without having them
all break overnight when the receiver is updated.
I'm fine with that. Using your implementation and the other libraries
to get it right is definitely the right way to do things since we have
the opportunity to do so.
Chris
--
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.
