Hey, thanks for the post. It's always nice to hear about new work on ratchets.
+1 for writing new applications/libraries in Rust and ditching C/C++.
On 04/09/15 21:42, Ian Miers wrote:
> * Performance: depends on message distribution. Assuming a poisson process
> for initial messages (you only need this for initial messages, after that use
> Axolotl or another ratchet):
>
Could you explain the intention of {combining this with a ratchet} in a bit
more detail? From your description, it sounds like your protocol "offers the
same service" as a ratchet. What is the point of using two of them? Or from
another viewpoint, why don't I use only "a ratchet" and avoid your scheme
entirely?
In general, I think lossy ratchets are not good things to use for *a single
session* which should have its whole integrity guaranteed. But one can use them
to bootstrap "seed keys" for non-lossy ratchets that protect a whole session,
to prevent drop attacks forcing you to re-use the same long-term key for the
first message of each session. (By "non-lossy ratchet" I mean ones that don't
allow holes in the middle of the session as Axolotl does; one can always
implement a "delete keys and end the session if I don't get a heartbeat within
X time", as you mentioned later.)
> [..]
>
> While this ensures forward security, it means late arriving messages (either
> due to delays or badly set clocks) can't be decrypted. This means we face a
> choice: either have fine grained forward security with short intervals and
> risk losing messages or have long intervals and leave more exposed.
>
> Our scheme, Puncturable Forward Secure Encryption, avoids this. Instead of
> deleting keys, we update ("puncture" them) every time we receive a
> ciphertext. Once punctured on a ciphertext, a key cannot decrypt that message
> but can decrypt new ciphertexts (e.g. late arrivals). Obviously, keys can be
> deleted at some point to avoid an attacker dropping messages and then
> breaking into your computer later.
>
> Unfortunately, decryption is linear in the number of punctures. However,
> punctures are per time interval and don't cary over, so if we make our time
> intervals short, we only expect to see one message per interval and never
> need to decrypt with a punctured key. This ends up being very efficient. It
> does mean performance depends on your message distribution. When you only get
> one message in an interval it works very well.
>
Do you have a paper that describes this in more detail?
It sounds sort of like an inside-out Axolotl - i.e. chaining ("intervals") then
a DH-ratchet inside that ("puncturing"), or maybe even a chain-inside-a-chain?
Could you compare your scheme with those options?
I'm not sure why you distinguish "puncture" as a different operation from
"delete". In forward-secure protocols, whenever you "delete" a key you usually
replace it with a new one so you can keep decrypting later ciphertext, but
that's what you also define "puncture" to be.
> If you get many messages in an interval, performance only in that interval
> linearly worse but is still manageable for a while. (For those of you
> wondering about DOS, the system can always fall back to the time based
> approach. If too many messages arrive in an interval we can stop puncturing
> and lock in whatever performance we have for that interval.... you probably
> should delete that key soon after the interval expires). If you have high
> variance in your message distribution, you're going to need to use shorter
> intervals to ensure you usually get one message per interval. Past a certain
> point, this will also get expensive and the entire scheme might not be well
> suited to your needs. I don't think this is close to the common case at
> all. For most applications, I think you can reasonably ensure you get one
> message per interval on average.
>
Are you expecting the application / higher layer to manage this itself? This
would get awfully complex to do "properly", especially for non-security-trained
application writers.
X
--
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
