[liberationtech] DecryptoCat

[Patrick Mylund Nielsen]

I see a ton of people criticizing left and right, conveniently leaving out
that this didn't apply to the OTR implementation. I don't see a lot of
people producing more secure or as-easy-to-use alternatives, which
presumably they're more than capable of.

Criticizing is easy. It's okay to feel bad that you made a mistake, but you
don't really have anything to answer for. You clearly stated that you
shouldn't put your life on the line using cryptocat, and that not enough
eyes had looked at it yet.

For the open source vs. proprietary argument: Proprietary is clearly
better, PR-wise at least, as long as you don't have enough eyes. Open
source means nothing if you don't have more qualified "good" people looking
at it than "bad" people.

Virtually everyone in the history of cryptography engineering, as with
software engineering in general, has made mistakes. Critics should lay off
the holier-than-thou nonsense, and spend more time looking at the code so
any outstanding issues can be fixed responsibly.


On Sun, Jul 7, 2013 at 4:34 PM, Nadim Kobeissi <nadim at nadim.cc> wrote:

>
> On 2013-07-07, at 2:25 PM, CodesInChaos <codesinchaos at gmail.com> wrote:
>
> > > So introductory-level programming course mistakes are right out.
> >
> > In my experience it's quite often a really simple mistake that gets you,
> > even when you're an experienced programmer. I'm quite afraid of simple
> off-by-one bug,
> > places which I didn't fix in copy&paste, basic logic mistakes etc.
> > IMO Nadim's main mistake wasn't the actual bug, mistakes like that can
> happen to anybody,
> > but it was designing a really weird API that invites mistakes. Nobody
> sane return decimal digits
> > from a cryptographic PRNG.
>
> That's not what the CSPRNG does exactly, but we routed it through an
> all-purpose function that wields it to present types of data on demand, be
> it random ASCII lowercase, random ASCII uppercase, random digits, random
> bytes. And then I messed up and asked it to produce random digits instead
> of random bytes and BOOM — security disaster, end of the world etc.
>
> For the record, I feel deeply ashamed about this blunder. But I can't give
> up this project simply because bugs like this are bound to pop up for any
> project with this kind of goals and ambition, and our goals are, in my
> view, deeply necessary.
>
> NK
>
> >
> > For example a really basic cryptography mistake is reusing a nonce in
> AES-CTR. Still it happens to people experienced
> > in both coding and cryptography. For example Tarsnap had since
> vulnerability for several versions, despite a competent developer.
> >
> http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-security-bug.html
> >
> > In my own programs I'm really careful about nonces and randomness, but
> still I wouldn't be surprised if a trivial bug slipped through in that area.
> > Writing tests which detect such mistakes is really hard.
> > --
> > Too many emails? Unsubscribe, change to digest, or change password by
> emailing moderator at companys at stanford.edu or changing your settings at
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
> --
> Too many emails? Unsubscribe, change to digest, or change password by
> emailing moderator at companys at stanford.edu or changing your settings at
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130707/558dfe9f/attachment.html>