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"

Mitar mmitar at
Thu Jul 11 14:06:12 PDT 2013


On Thu, Jul 11, 2013 at 1:47 PM, Andy Isaacson <adi at> wrote:
> and Intel's AESNI implementation is
> coming from an organization with significant resources to dedicate to
> the correctness of their implementation.

And how they managed to get this "significant resources"? They were
running a closed source business model. Hopefully such a business
model will allow Hemlis to also allocate significant resources to
implement server side component securely.

> 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.

So we are judging then the whole system even without knowing anything
about the design? So you are saying that based on the properties we
assume (closed source centralized server component) it is *impossible*
to create a secure design? Or it is maybe just hard? Or we just cannot
image one, yet?

> 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.

Yes. I think they will be just using PGP with some easy to use user
interface on top of it.

What I am worried is forward-secrecy in such case. But let's wait for
their design. For now they are just asking the world: "are you
interested in the app which would allow private messaging and are you
willing to fund it, if yes, we will start working on the design and
implementation of it".

> 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.

PGP and XMPP is pretty standard? Probably we will be able to test
those components. And see if encrypted message I send from my client
(which is open source) arrives the same on the other side
(deterministically) and then again I can test decryption.



More information about the liberationtech mailing list