4 ms·

Indeed, I am not a patent lawyer; I am a crypto geek attempting to ascertain whether and to what extent this treads on current, and future, implementations of (

Indeed, I am not a patent lawyer; I am a crypto geek attempting to ascertain whether and to what extent this treads on current, and future, implementations of (edit: and enhancements to) the double ratchet algorithm. I believe that my tweets are pretty clear about that. ps: other people have simply said to "read the claims", which is fine but does not help clarify anything.

matthewdgreen 7y ago
I’ve read the claims, and don’t currently see how they exclude Signal. Perhaps on claim construction it might be possible to dig into the specification and find non-standard interpretations of some terms that walk around the existing prior art. But that feels like a very unreliable approach.
- hcknwscommenter 7y ago
  The patent office specifically looked at Signal and other implementations and states that the Examiner "has been unable to locate prior art that would suggest that the device sending a message in a particular epoch require its own private key in generation of the shared first refresh key and first state with the recipient device. Although using public keys to securely transmit data is known in the art . . . ." The patent Applicant states "Sarafa fails to [suggest each and every step of] 'generating on the first device, a first epoch key . . . transmitting, from the first device, the first epoch key . . . generating, independently on each of the first device and the second device, a first refresh key . . . *wherein the first refresh key is generated on the first device without requiring a private key corresponding to the first epoch key"
  - matthewdgreen 7y ago
    I haven’t read the specification carefully enough yet to determine what they mean by “refresh key” since that’s not really a standard term of art. If this could refer to a Diffie-Hellman ephemeral, then said key would be generated without requiring a separate private key corresponding to the epoch key, something that’s also not really a standard term. My concern with patents like this is that, since many of the terms are non-standard and thus defined by the specification, any vagueness in the spec leaves room for future interpretations in an infringement case that may, in fact, lead to de facto Signal implementations being found to infringe. ETA: I’ll read the spec later this weekend and see how they define all these terms.

matthewdgreen 7y ago

I’ve read the claims, and don’t currently see how they exclude Signal. Perhaps on claim construction it might be possible to dig into the specification and find non-standard interpretations of some terms that walk around the existing prior art. But that feels like a very unreliable approach.

hcknwscommenter 7y ago
The patent office specifically looked at Signal and other implementations and states that the Examiner "has been unable to locate prior art that would suggest that the device sending a message in a particular epoch require its own private key in generation of the shared first refresh key and first state with the recipient device. Although using public keys to securely transmit data is known in the art . . . ." The patent Applicant states "Sarafa fails to [suggest each and every step of] 'generating on the first device, a first epoch key . . . transmitting, from the first device, the first epoch key . . . generating, independently on each of the first device and the second device, a first refresh key . . . *wherein the first refresh key is generated on the first device without requiring a private key corresponding to the first epoch key"
- matthewdgreen 7y ago
  I haven’t read the specification carefully enough yet to determine what they mean by “refresh key” since that’s not really a standard term of art. If this could refer to a Diffie-Hellman ephemeral, then said key would be generated without requiring a separate private key corresponding to the epoch key, something that’s also not really a standard term. My concern with patents like this is that, since many of the terms are non-standard and thus defined by the specification, any vagueness in the spec leaves room for future interpretations in an infringement case that may, in fact, lead to de facto Signal implementations being found to infringe. ETA: I’ll read the spec later this weekend and see how they define all these terms.