Search Mailing List Archives

Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] - "The Beautiful & Secure Messenger"

Andy Isaacson adi at
Thu Jul 11 13:47:32 PDT 2013

On Thu, Jul 11, 2013 at 08:44:24AM -0700, Steve Weis wrote:
> It's not true that all widely used crypto implementations are open.
> Even open source projects themselves depend on closed implementations.
> For example, Linux, OpenSSL, GnuTLS, libgcrypt, and dm-crypt may all use
> AESNI on x86, usually by default [1].

That's not a very good parallel to the Hemlis critique.  The AES is a
very well defined specification, and Intel's AESNI implementation is
coming from an organization with significant resources to dedicate to
the correctness of their implementation.  The implementation follows
well understood public principles and has a determistic output which can
be checked against an open implementation. [1adi]

By contrast, the proposed Hemlis system has no public design (in fact
the authors imply they have barely started to design the system, and
significant aspects of it seem to be undefined still) and there's no
commitment from them to publish the design.  The mere fact that they
don't seem to be aware of Kerckhoff's Principle is alarming.

Their design sketches seem to imply that they don't care about (or maybe
don't know about) significant threats that have been discussed in the
OTR community for most of a decade now.

In contrast to the AES case, Hemlis won't have multiple open source
implementations of the same standard to be checked against.  Hemlis
won't have a well-defined deterministic behavior to implement.

> Linux now also uses a closed RdRand [2] RNG if available.

There was a bunch of churn when this code went in, so I could be wrong,
but I believe that RdRand is only used to stir the same entropy pool as
all of the other inputs which are used to generate random data for
/dev/random et al.  It's hard to leverage control of one input to a
random pool into anything useful.

[1adi] which is not to say that there are no interesting vulnerabilities
       in the AESNI space!  Perhaps on receipt of a special Wi-Fi packet
       the Centrino firmware lets the CPU know that it should leak the
       AES-NI key data in timing information of another instruction
       sequence entirely, for example.


More information about the liberationtech mailing list