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. -- 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.
