What are your thoughts on supporting revocations/ any sort of key agility within the Peerio framework?
Under the minilock framework identities were very ephemeral and zero PKI. Now there is a PKI of sorts... On Wed, Feb 25, 2015 at 3:06 PM, Nadim Kobeissi <[email protected]> wrote: > I'm reviving this thread now that I actually have something substantial to > say regarding Peerio's crypto. > > I was inspired by the recent debate over PGP to write this blog post: > http://blog.peerio.com/post/112078157509/going-beyond-pgp > > I'm basically outlining how I think Peerio can be more attractive than PGP > to a vast majority of PGP's users. > > I'd love to hear your thoughts on that blog post. I'd also like to thank > everyone who gave their early comments on Peerio and thank Mike for > starting off this thread. > > Nadim > > On Wed, Jan 21, 2015 at 2:19 AM, Daniel Kahn Gillmor < > [email protected]> wrote: > >> On Fri 2015-01-16 19:07:47 -0500, Joseph Bonneau wrote: >> > Is there a design rationale for these choices? 112 bits is overkill for >> > something users need to memorize (especially with 2^17 of stretching) >> and a >> > 2^16 dictionary in my experience is vastly bigger than ideal (though we >> > don't really have good research confirming this, it's just a hunch). >> > >> > Personally I would say 70 bits plus 2^20 stretching is secure against >> any >> > economically imaginable attacker and 60 bits plus 20 bits of stretching >> is >> > probably secure against non state-level attackers. >> >> This prescription is missing a timescale. >> >> Systems like peerio and minilock have no key transition mechanism >> available, no way for users to change a passphrase. If they're intended >> for lasting use, at least some of the encrypted information will need to >> withstand attackers 10 years from now or later. >> >> Even ignoring major disruptions in hardware, are should we expect users >> to settle for 90 bits of defense (or 80 bits against "non-state-level" >> attackers) for 10 years? >> >> Nadim's choices here might be a little conservative, they don't seem >> excessive to me, given the other tradeoffs he's made in cryptosystem >> design. >> >> --dkg >> _______________________________________________ >> Messaging mailing list >> [email protected] >> https://moderncrypto.org/mailman/listinfo/messaging >> > > > _______________________________________________ > Messaging mailing list > [email protected] > https://moderncrypto.org/mailman/listinfo/messaging > >
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
