Re: [cryptography] the Zcash Open Source Miner Challenge (and about Zcash in general)

[Zooko Wilcox-OHearn]

On Wed, Nov 9, 2016 at 3:07 PM, Jaromil  wrote:
>
> ...but ZCash feels a bit scammy. Its pumped up entry on the market
> burnt a lot of people's money... is it just their fault being stupid?
…
> Sincerely, I'm not trolling. Seeing there is some space for a civil
> conversation, I'd be interested in reading answers from the Zcash ppl
> themselves here, what they are going to make out this market hype
> stun. I'm a big fan of all Z- things (ZFS, ZSh, Zorro) but
> ZCash still.. meh. how about helping us understand?


I'm not quite sure what your question or objection is. Can you spell it out?

I and the Zcash dev team have no control over the market price. We
don't operate an exchange, we haven't bought or sold any ZEC, we have
never given anyone investment advice, and we've always striven in our
public communications to be clear about the risks and limitations of
the Zcash project.

Sincerely,

Zooko
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] the Zcash Open Source Miner Challenge (and about Zcash in general)

[Zooko Wilcox-OHearn]

Hi folks!

I've been quiet on this list for a while now. I've been hard at work
on creating a Bitcoin-like cryptocurrency with zero-knowledge-based
crypto:

https://z.cash

This is the most sophisticated crypto that I've ever seen someone
attempt to deploy at scale to the Internet. (By all means feel free to
reply and teach me about counter-examples to that generalization.)

There's a lot going on there. To jump into the technical side, I'd
suggest the Zcash protocol spec:
https://github.com/zcash/zips/blob/master/protocol/protocol.pdf . For
an introduction to the bigger picture, probably our blog
(https://z.cash/blog/) and FAQ (https://z.cash/support/faq.html).

Okay the reason I'm writing today is to let you know about the Zcash
Open Source Miner Challenge:

https://zcashminers.org/

The Zcash company has donated $30,000 for prize money to reward better
open-source implementations of Equihash by Biryukov & Khovratovich:

https://www.internetsociety.org/sites/default/files/blogs-media/equihash-asymmetric-proof-of-work-based-generalized-birthday-problem.pdf

Jump in! The worst that can happen is that you get the fun and
education of implementing an interesting new proof-of-work algorithm.
:-)

Regards,

Zooko
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Should Sha-1 be phased out?

[Zooko Wilcox-OHearn]

On Tue, Oct 20, 2015 at 8:00 AM, Joachim Strömbergson
 wrote:
>
> Esp in embedded space, md5 is still very, very common even in new
> designs. And SHA-1 is the new black.
>
> A typical setup is that someone has found out that there is a secure
> hash function called md5 and decided to implement it in their new
> system. When told that md5 is in fact broken since ages, the response is
> usually a at the moment-decision that it is not used for security, and
> that the application doesn't really have any security implications (i.e.
> that the service performed by the system has no value).

Yep. Actually the post-hoc rationalization is usually that
collision-resistance isn't needed, only (2nd-)pre-image resistance.

Some of the time this is actually true, but I think the people making
the claim don't really know whether it is true. I think what they
typically do is spend 60 seconds trying to imagine how they could
attack their own system using collisions, and then having failed to
find such an attack, they conclude that collision-resistance isn't
needed for their system.

Here's one of my favorite examples of this methodology, from Linus
Torvald: 
http://git.vger.kernel.narkive.com/9lgv36un/zooko-zooko-com-revctrl-colliding-md5-hashes-of-human-meaningful#post2

So, my attempted contribution to this pattern was to help specify
BLAKE2, so that instead of telling people "MD5 is broken! Switch to
this secure but slower hash function!" we could tell them "MD5 is
broken! Switch to this secure but faster hash function!"

https://blake2.net/acns/slides.html

It remains to be seen if they are any more responsive to the new
argument than they have been for the last couple of decades to the old
argument.

Regards,

Zooko
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] hashes based on lots of concatenated LUT lookups

[Zooko Wilcox-OHearn]

Dear Eugen:

There have been several experiments in this direction, using
memory-hard proofs-of-work. For example, this was the motivation for
Litecoin (https://en.wikipedia.org/wiki/Litecoin) to use scrypt in its
Proof-of-Work. To my knowledge, the state-of-the-art design is John
Tromp's Cuckoo PoW: https://github.com/tromp/cuckoo

In my opinion, this is a promising direction to take. It might still
succumb to centralization-of-mining in the long-term, but maybe not.
There's a possibility it would settle into an economic equilibrium in
which independent/hobbyist/small-time mining is sufficiently
rewarding, but customized, large-scale, vertically-integrated mining
is not rewarding enough to justify its costs.

Among anti-mining-centralization techniques that I've studied, this is
the only one that is easy to implement in the near-term, and doesn't
come with too many complications and risks for near-term deployment.

For the contrarian view, arguing that ASIC-resistance is either
undesirable and/or impossible, see this whitepaper by andytoshi:
http://download.wpsoftware.net/bitcoin/asic-faq.pdf . I disagree with
the conclusions, but it makes some good arguments.

For a survey of state-of-the-art ideas about Proof-of-Stake — ideas
which *aren't* easily implementable and which *do* come with
complexity, uncertainty, and risk — see Vitalik Buterin's latest opus:
https://blog.ethereum.org/2014/07/05/stake/ . That guy is a good
thinker and writer! And he appears to have been reading my mind. As
well as adding in a bunch of ideas that were not in my mind, from such
sources as http://eprint.iacr.org/2014/452.pdf .

Regards,

Zooko
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [zfs] [Review] 4185 New hash algorithm support

[Zooko Wilcox-OHearn]

On Mon, Oct 28, 2013 at 6:49 AM, Richard Elling
richard.ell...@gmail.com wrote:

 I hate to keep this thread going, but it cannot end with an open-ended 
 threat... please, let's kill it off nice and proper.

Hey, I don't want to waste anyone's time, including my own. If nobody
is interested in this — possibly including the original author of the
patch, Saso Kiselkov, judging from ¹ — then by all means let's drop
the subject.

¹ http://article.gmane.org/gmane.os.illumos.zfs/3103

However, in case someone out there is reading this…

 Do you agree that if the attacker does not have DDT key (including the hash) 
 of the future intended write (ignoring the fact that we haven't invented a 
 properly working time machine yet) that this attack is extraordinarily 
 difficult to conduct with any hope of a fruitful outcome? If so, let's kill 
 this thread.

I'm not sure what you mean about the future intended write. The risk I
was talking about was that an attacker can cause two blocks (on
someone else's ZFS system) to hash to the same fingerprint.

Assuming that “the DDT key” is the secret which is prefixed to the
block contents in the current patch, then I agree it is extremely
difficult to cause two blocks to hash to the same fingerprint. A way
to be more precise about how difficult it is, is to talk about what
property we depend on the hash function to have in order to prevent
this attack.

If the attacker steals the secret, or if there is some variant of ZFS
which shares that secret among multiple parties ², then the property
that we rely on the hash function to have is “collision-resistance”.
If the attacker doesn't have the secret, then the property that we
rely on the hash function to have one which is closely related to, and
even easier-to-achieve than, “MAC”.

² http://article.gmane.org/gmane.os.illumos.zfs/3015

Functions which, in my opinion, have this easier-to-achieve-than-MAC
property include SHA-256, HMAC-MD5, Skein, BLAKE2, and
BLAKE2-reduced-to-5-rounds. Almost all cryptographic hash functions
have this property! One of the few cryptographic hash functions which
I would be not so confident in is Edon-R. It *probably* still has this
property, but it might not, and cryptographers haven't studied it
much.

Functions which, in my opinion, have the much harder-to-achieve
“collision-resistance” property include SHA-256, Skein, BLAKE2, and
*probably* BLAKE2-reduced-to-5-rounds.

 I'll let the fact that there is no future dedup run and there is no 
 replace blocks later in ZFS fall quietly in the forest with nobody 
 listening.

I'm sorry if I've misunderstood; I'm not an expert on ZFS. If you'd
like to take some of your valuable time to explain it to me, I'll
spend some of my valuable time to learn, because I'm interested in
filesystems in general and ZFS in particular. If not, I'm pretty sure
everything I've written above is still true.

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.


---
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182191/22842876-ced276b8
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=22842876id_secret=22842876-4984dade
Powered by Listbox: http://www.listbox.com
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [zfs] [Review] 4185 New hash algorithm support

[Zooko Wilcox-OHearn]

On Tue, Oct 22, 2013 at 6:05 AM, Schlacta, Christ aarc...@aarcane.org wrote:

 If any weakened algorithm is to be implemented, how can we know how weak is 
 too weak, and how strong is sufficient?  Each professional Cryptographer has 
 given different opinions and all those at our immediate disposal have now 
 been biased.

A good way to do that is use an algorithm that has attracted interest
from a large number of independent cryptographers. If many
cryptographers have invested extensive effort trying to find
weaknesses in a algorithm, and haven't reported any, then we can feel
more confident that it is less likely to harbor undiscovered
weaknesses.

Among the algorithms we've been talking about in this thread, SHA-256,
HMAC-MD5, Skein, Keccak, and BLAKE are all in this category of being
well-studied.

Cryptographers publish it if they find a weakness in a reduced-round
variant of an important algorithm. You can see a summary of the best
results against weakened variants of BLAKE in ¹ (Table 1).

¹ http://eprint.iacr.org/2013/467

The rows labeled perm. and cf. are attacks on just one component
of the hash, not the whole algorithm. The # Rounds column shows how
many rounds of a reduced-round variant would be vulnerable to that
attack.

Don't forget to look at the Complexity column, too! That shows
(roughly) how many calculations would be necessary to implement the
attack. Yes, almost all of them are computations that are completely
impossible for anyone to actually execute in the forseeable future.
But still, they are the best attack that anyone has (publicly) come up
with against those weakened variants of BLAKE so they serve as a
heuristic indicator of how strong it is.

Among the well-studied algorithms listed above, BLAKE is one of the
best-studied. It was one of the five finalists in the SHA-3 contest,
and in the final report of the contest ², NIST wrote “The
cryptanalysis performed on BLAKE […] appears to have a great deal of
depth”. Here is a list of research reports that analyzed BLAKE: ³.

² http://dx.doi.org/10.6028/NIST.IR.7896
³ https://131002.net/blake/#cr

Now, BLAKE2 is not necessarily as secure as BLAKE. We could have
accidentally introduced weaknesses into BLAKE2 when making tweaks to
optimize it. The paper ¹ looked for such weaknesses and reported that
they found nothing to make them distrust BLAKE2.

We use a stream cipher named ChaCha ⁴,⁵ as the core of BLAKE and
BLAKE2, and nobody has found any weakness in ChaCha. Again, that
doesn't mean we didn't manage to screw it up somehow, but I think it
helps! If anyone found a weakness in ChaCha, it would *probably* also
show them a weakness in BLAKE2, and vice versa.

⁴ https://en.wikipedia.org/wiki/ChaCha_%28cipher%29#ChaCha_variant
⁵ https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-02

In sum, there has been a lot of independent analysis of BLAKE2, BLAKE,
and ChaCha, and I hope there will be more in the future. If you use a
reduced-round version of BLAKE2, you can look at these results to see
whether anyone has published an attack that would break that
reduced-round version. Of course, more rounds is safer against future
breakthroughs.

It was in that context that I recommended that ZFS use the most rounds
of BLAKE2 that it can while still being faster than Edon-R. ☺ That
will probably be around 5 rounds.

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.


---
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182191/22842876-6fe17e6f
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=22842876id_secret=22842876-a25d3366
Powered by Listbox: http://www.listbox.com
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] my comment to NIST about reduced capacity in SHA-3

[Zooko Wilcox-OHearn]

Date: Tue, 1 Oct 2013 15:45:27 -0400
From: zooko zo...@zooko.com
To: Multiple recipients of list hash-fo...@nist.gov
Subject: Re: On 128-bit security

Folks:

Here are my personal opinions about these issues. I'm not expert at
cryptanalysis. Disclosure: I'm one of the authors of BLAKE2 (but not
one of the authors of BLAKE).

I personally do not believe that there is any secret agenda behind
this proposal, even though I believe that there was a secret agenda
behind Dual EC DRBG.

One reason that I believe that the motivation behind this proposal is
the stated motivation of improving performance, is that Joan Daemen
told me in person in January of 2013 that the Keccak team had
considered defining a reduced Keccak to compete with BLAKE2, but had
decided against it because they didn't want to disrupt the SHA-3
standardization process.

Apparently they changed their minds, and apparently their fears of
disruption turned out to be prescient!

I also do not think that a security level of 2^256 is necessarily
better than a security level of 2^128. *Maybe* it is better, but I'm
not aware of any examples where that sort of distinction has turned
out to matter in practice, and I can't really judge if it is likely to
matter in the future (except, of course, if you forget to take into
account multi-target issues…). I suspect nobody else can, either.

However, even though I *personally* would have confidence that a
Keccak with a 256-bit capacity would be safe and would be free of
maliciously induced weakness, I want a standard to be widely accepted
in addition to being safe.

This is the Caesar's wife must be above suspicion argument. It isn't
enough to make a secure standard, but also we need other people to
have confidence in it.

And, I don't know if we can persuade people that no it isn't actually
backdoored/weakened. It may be the kind of thing where if that's the
conversation we're having then we've already lost.

Would it make sense to go ahead and standardize
SHA3-as-a-replacement-for-SHA2 by standardizing the form of Keccak
which is most widely accepted by cryptographers and which is closest
to what was studied during the contest, and then separately offer
SHAKE and reduced-for-speed-Keccak as additional new things?

A lot of uses of secure hash functions don't need to be particularly
efficient. In my slides about BLAKE2
(https://blake2.net/acns/slides.html) I argue that there are use-cases
where efficiency is critical, but it is equally true that there are
common and important use cases where a 576-bit capacity Keccak would
be fine, e.g. public key certificates.

---

Joan Daemen, one of inventors of AES and one of the inventors of
Keccak (SHA-3), replied to my mailing list post as follows:

Date: Fri, 4 Oct 2013 05:08:07 -0400
From: Joan DAEMEN joan.dae...@st.com
To: Multiple recipients of list hash-fo...@nist.gov
Subject: RE: On 128-bit security

Hello all,

Zooko wrote:

 I personally do not believe that there is any secret
 agenda behind this proposal, even though I believe that
 there was a secret agenda behind Dual EC DRBG.

 One reason that I believe that the motivation behind
 this proposal is the stated motivation of improving
 performance, is that Joan Daemen told me in person in
 January of 2013 that the Keccak team had considered
 defining a reduced Keccak to compete with BLAKE2, but
 had decided against it because they didn't want to
 disrupt the SHA-3 standardization process.

 Apparently they changed their minds, and apparently
 their fears of disruption turned out to be prescient!

Yes, Zooko and I met at the end-of-Ecrypt II event on Tenerife early
2013 (24° C in January!).
I don't remember our conversation in detail, but I I'm sure Zooko is
citing me correctly because that is what we were thinking about at the
time.

Actually, what we had in mind was to propose something like Keccak2
to compete with BLAKE2 by drastically cutting the number of rounds,
e.g., down to 12 rounds for Keccak-f[1600], but otherwise keeping the
algorithm as it is. That might have sent the wrong message indeed, but
we just didn't do it.

In contrast, the capacity is an integral parameter of the Keccak
family that we even proposed as user-tunable in our SHA-3 submission.
Matching the capacity to the security strength levels of [NIST SP
800-57] is simply exploiting that flexibility.

Kind regards,

Joan, also on behalf of my Keccak companions

---

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Reply to Zooko (in Markdown)

[Zooko Wilcox-OHearn]

Dear Jon:

Thank you for your kind words and your detailed response.

I am going to focus only on the issue that I think is most relevant
and urgent for your customers and mine.

That urgent issue is: what's the difference between the now-canceled
Silent Mail product and the products that you are still offering, such
as Silent Text?

I don't understand why the Lavabit shutdown and the related domestic
surveillance disclosures imply that Silent Mail was unsafe in any way
that wouldn't also mean Silent Text is unsafe.

Before I go on, I'd like to point out a critical fact that some
readers might not be aware of: Ladar Levison, the owner of Lavabit,
now claims that he is being threatened with jail time *for having shut
down the service*:

http://investigations.nbcnews.com/_news/2013/08/13/20008036-lavabitcom-owner-i-could-be-arrested-for-resisting-surveillance-order?lite

This changes the equation, because it means not only can the U.S.
federal espionage authorities say Backdoor all of your customers or
close your business., they can also say Backdoor all of your
customers or go to jail.. As the owner and CEO of a
privacy-protecting service (https://LeastAuthority.com) and a U.S.
citizen, and as the father of three precious boys who do not want to
be separated from me for any length of time, this concerns me greatly.

Now, maybe the U.S. espionage authorities wouldn't make that threat
again. Maybe Ladar Levison's resistance will teach them that it was a
mistake. I don't know, but we have to take into account this
possibility for now. Your decision to shutter the Silent Mail product
was made because of such possibilities.

But your decision to *keep* the Silent Text service (and the others)
still operating while shutting down the Silent Mail service would make
sense only in the following scenario:

Attacker: We're here to compel you to give us access to the
confidential communications of all of your customers.

Silent Circle: But, to do that we would have to change our client —
for example, change its random number generator to produce output that
we can predict — and then upload a software update to the Apple and
Google app stores, and then wait for all of our customers to
automatically upgrade to the new version!

Attacker: Oh, well in that case nevermind.

Why do you think that this scenario is plausible? I don't think it is
plausible. Instead, I think the conversation would go like this:

Silent Circle: … and then wait for all of our customers to
automatically upgrade to the new version!

Attacker: Okay. Do that.


Now, there is a big, complex, and interesting question about how to
enable others to *verify* the security of software. It is not
impossible, as you suggested. Good progress on enabling independent
verification of security is being made, by Whisper Systems
(https://whispersystems.org/), my own company LeastAuthority.com, the
Tor Project 
(https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise),
Gitian (https://gitian.org/), Debian
(https://wiki.debian.org/ReproducibleBuilds), and Bitcoin
(https://en.bitcoin.it/wiki/Release_process).

But before we get into the nuts and bolts of how to facilitate
verification of end-to-end security, I want to hammer on the first
issue: before going forth to try to improve an issue, we should first
admit to our current customers and to the public that the issue
exists. We shouldn't mislead our customers into thinking that they are
safe from something that they are not. Silent Circle's closure of
Silent Mail for the stated reason is inconsistent with its continued
operation of the Silent Text service. The stated reason was that the
US federal government could compel Silent Circle to backdoor the
Silent Mail service. That same reason applies today to the Silent Text
service and the other services that Silent Circle is still operating.

To be clear, I'm not asking you to shut down your other services. I
think that would be a loss for everyone. And I'm not asking you to
magically fix all of the problems by tomorrow. I know, in part from
your detailed letter, that you are currently working on improving some
parts of your process, and I think that there are other techniques
that you could use (including licensing your source code as Free and
Open Source software) that would help. But I understand the challenges
of running a business, actively serving customers, and performing
sophisticated engineering all at once. I know that improvement takes
time. What I'm asking you to do is to *be clear* with your customers
and with the public about the current limitations.

Currently, the US federal espionage agencies can compel Silent Circle
to secretly provide access to all of Silent Circle's customers'
private communications. That's too bad. But it is fixable! But to fix
it starts with admitting what the problem is.


Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Service Rep
https://LeastAuthority.com
Freedom matters.

[cryptography] open letter to Phil Zimmermann and Jon Callas of Silent Circle, re: Silent Mail shutdown

[Zooko Wilcox-OHearn]

also posted here: https://leastauthority.com/blog/open_letter_silent_circle.html


This open letter is in response to the `recent shutdown of Lavabit`_ ,
the ensuing `shutdown of Silent Circle's “Silent Mail” product`_, `Jon
Callas's posts about the topic on G+`_, and `Phil Zimmermann's
interview in Forbes`_. Also, of course, all of this is unfolding in
the context of the `2013 Mass Surveillance Scandal`_.


Dear Phil and Jon: Hello there! It is good to have a chance to chat
with you in public.

Please accept the following in the spirit of constructive criticism in
which it is intended.

For those readers who don't know, I've known you both, personally and
professionally for decades. You've each written texts that I've
learned from, inspired me to follow your example, we've worked
together successfully, and you've mentored me. I have great respect
for your technical abilities, your integrity, and your general
reasonableness. Thank you for the all of that and for holding fast to
your principles today, when we need it more than ever.

Now:

Your job is not yet done. Your customers are currently vulnerable to
having all of their communications secretly monitored.

I just subscribed to the service at https://SilentCircle.com, and
after I paid $120 for one year of service, it directed me to install
the Silent Text app from Silent Circle on my android phone, which I
did. Now, when I use that Silent Circle app to send text messages to
other Silent Circle customers, I have no way of verifying whether it
is really encrypting my message on my own phone, and if it is really
keeping the encryption key only for me, or if it is leaking the
contents of my messages or my encryption keys to you or to others.

If some attacker, for example the U.S. Federal Government — or to pick
a different example the Zetas Mexican drug cartel — were to coerce
Silent Circle into cooperating with them, then that attacker would
simply require Silent Circle to distribute an update to the app,
containing a backdoor.

There is no way for me to verify that any given version of Silent
Text, including the one that I just installed, is correctly generating
strong encryption keys and is protecting those keys instead of leaking
them.

Therefore, how are your current products any safer for your users that
the canceled Silent Mail product was? The only attacker against whom
your canceled Silent Mail product was vulnerable but against whom your
current products are safe is an attacker who would require you to
backdoor your server software but who wouldn't require you to backdoor
your client software.

Does that constraint apply to the U.S. Federal Government entities who
are responsible for PRISM, for the shut-down of Lavabit, and so much
else? No, that constraint does not apply to them. This was
demonstrated in the Hushmail case in which the U.S. DEA asked Hushmail
(a Canadian company) to turn over the plaintext of the email of one of
its customers. Hushmail complied, shipping a set of CDs to the DEA
containing the customer's messages.

The President of Hushmail `emphasized`_ in interviews with journalists
at the time that Hushmail would be able to comply with such orders
regardless of whether the customer used Hushmail's “client-to-server”
(SSL) encryption or its “end-to-end” (Java applet) encryption.

.. _emphasized: http://www.wired.com/threatlevel/2007/11/hushmail-to-war/

Phil had been Chief Cryptographer of Hushmail years earlier, and was
still a member of the Advisory Board of Hushmail at the time of that
case. He commented about the case at that time, and he also `stated`_,
correctly, that the Hushmail model of *unverified* end-to-end
encryption was vulnerable to government coercion. That's the same
model that Silent Circle uses today.

.. _stated: http://www.wired.com/threatlevel/2007/11/pgp-creator-def/

You have just taken the courageous act of publicly shutting down the
Silent Mail product, and publicly stating your reasons for doing so.
This, then, is your opportunity to make your stance consistent by
informing your customers of the similar dangers posed by the software
distribution practices currently used by Silent Circle (along with
most of the rest of the industry).

I don't know the perfect solution to the problem of the
*unverifiability* of today's software. But being frank about the
current approach and the vulnerability that it imposes on users is the
first step. People will listen to you about this, now. Let's start
talking about it and we can start finding solutions.

Also, warn your users. Don't tell them the untruth that it is
impossible for you to eavesdrop on their communications even if you
try (as your company seems to be on the borderline of doing in public
statements like these: [ `¹`_, `²`_]).

.. _¹: 
http://www.forbes.com/sites/parmyolson/2013/07/15/corporate-customers-flock-to-anti-snooping-app-silent-circle/
.. _²: 

[cryptography] LeastAuthority.com announces PRISM-proof storage service

[Zooko Wilcox-OHearn]

Dear people of the cryptography@randombit.net mailing list:

For obvious reasons, the time has come to push hard on *verifiable*
end-to-end encryption. Here's our first attempt. We intend to bring
more!

We welcome criticism, suggestions, and requests.

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.

---




 LeastAuthority.com Announces A PRISM-Proof Storage Service


Wednesday, July 31, 2013

`LeastAuthority.com`_ today announced “Simple Secure Storage Service
(S4)”, a backup service that encrypts your files to protect them from
the prying eyes of spies and criminals.

.. _LeastAuthority.com: https://LeastAuthority.com

“People deserve privacy and security in the digital data that make up
our daily lives.” said the company's founder and CEO, Zooko
Wilcox-O'Hearn. “As an individual or a business, you shouldn't have to
give up control over your data in order to get the benefits of cloud
storage.”

verifiable end-to-end security
--

The Simple Secure Storage Service offers *verifiable* end-to-end security.

It offers “end-to-end security” because all of the customer's data is
encrypted locally — on the customer's own personal computer — before
it is uploaded to the cloud. During its stay in the cloud, it cannot
be decrypted by LeastAuthority.com, nor by anyone else, without the
decryption key which is held only by the customer.

S4 offers “*verifiable* end-to-end security” because all of the source
code that makes up the Simple Secure Storage Service is published for
everyone to see. Not only is the source code publicly visible, but it
also comes with Free (Libre) and Open Source rights granted to the
public allowing anyone to inspect the source code, experiment on it,
alter it, and even to distribute their own version of it and to sell
commercial services.

Wilcox-O'Hearn says “If you rely on closed-source, proprietary
software, then you're just taking the vendor's word for it that it
actually provides the end-to-end security that they claim. As the
PRISM scandal shows, that claim is sometimes a lie.”

The web site of LeastAuthority.com proudly states “We can never see
your data, and you can always see our code.”.

trusted by experts
--

The Simple Secure Storage Service is built on a technology named
“Least-Authority File System (LAFS)”. LAFS has been studied and used
by computer scientists, hackers, Free and Open Source software
developers, activists, the U.S. Defense Advanced Research Projects
Agency, and the U.S. National Security Agency.

The design has been published in a peer-reviewed scientific workshop:
*Wilcox-O'Hearn, Zooko, and Brian Warner. “Tahoe: the least-authority
filesystem.” Proceedings of the 4th ACM international workshop on
Storage security and survivability. ACM, 2008.*
http://eprint.iacr.org/2012/524.pdf

It has been cited in more than 50 scientific research papers, and has
received plaudits from the U.S. Comprehensive National Cybersecurity
Initiative, which stated: “Systems like Least-Authority File System
are making these methods immediately usable for securely and availably
storing files at rest; we propose that the methods be further
reviewed, written up, and strongly evangelized as best practices in
both government and industry.”

Dr. Richard Stallman, President of the Free Software Foundation
(https://fsf.org/) said “Free/Libre software is software that the
users control. If you use only free/libre software, you control your
local computing — but using the Internet raises other issues of
freedom and privacy, which many network services don't respect. The
Simple Secure Storage Service (S4) is an example of a network service
that does respect your freedom and privacy.”

Jacob Appelbaum, Tor project developer (https://www.torproject.org/)
and WikiLeaks volunteer (http://wikileaks.org/), said “LAFS's design
acknowledges the importance of verifiable end-to-end security through
cryptography, Free/Libre release of software and transparent
peer-reviewed system design.”

The LAFS software is already packaged in several widely-used operating
systems such as Debian GNU/Linux and Ubuntu.

https://LeastAuthority.com
Title: LeastAuthority.com Announces A PRISM-Proof Storage Service






LeastAuthority.com Announces A PRISM-Proof Storage Service

Wednesday, July 31, 2013
LeastAuthority.com today announced “Simple Secure Storage Service (S4)”, a backup service that encrypts your files to protect them from the prying eyes of spies and criminals.
“People deserve privacy and security in the digital data that make up our daily lives.” said the company's founder and CEO, Zooko Wilcox-O'Hearn. “As an individual or a business, you shouldn't have to give up control over your data in order to get the benefits of cloud storage.”

verifiable end-to-end security
The 

Re: [cryptography] LeastAuthority.com announces PRISM-proof storage service

[Zooko Wilcox-OHearn]

On Tue, Aug 13, 2013 at 5:16 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
 On 8/13/13 11:02 AM, ianG wrote:
 Super!  I think a commercial operator is an essential step forward.

 How so? Centralization via commercial operators doesn't seem to have helped 
 in the email space lately.

It helps because we at LeastAuthority.com
(https://LeastAuthority.com/about_us ) can spend our days improving
the performance and reliability of our ciphertext storage servers and
contributing patches back to the free-and-open-source client
(https://Tahoe-LAFS.org ).

If we weren't running LeastAuthority.com, we would presumably have to
get different jobs which would take a lot of time away from LAFS
hacking!

It helps our customers because they can avoid doing the effort and
expense of setting up and managing servers, and instead pay us a
monthly fee to maintain those servers and the storage of their
ciphertext. Also our customer and business partners like having the
option of hiring us for support when they are integrating the
free-and-open-source LAFS software into their own products.

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] ANNOUNCING Tahoe-LAFS v1.10

[Zooko Wilcox-OHearn]

ANNOUNCING Tahoe, the Least-Authority File System, v1.10

The Tahoe-LAFS team is pleased to announce the immediate
availability of version 1.10.0 of Tahoe-LAFS, an extremely
reliable distributed storage system. Get it here:

https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/quickstart.rst

Tahoe-LAFS is the first distributed storage system to offer
provider-independent security — meaning that not even the
operators of your storage servers can read or alter your data
without your consent. Here is the one-page explanation of its
unique security and fault-tolerance properties:

https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/about.rst

The previous stable release of Tahoe-LAFS was v1.9.2, released
on July 3, 2012.

v1.10.0 is a feature release which adds a new Introducer
protocol, improves the appearance of the web-based user
interface, improves grid security by making introducer FURLs
unguessable, and fixes many bugs. See the NEWS file [1] for
details.


WHAT IS IT GOOD FOR?

With Tahoe-LAFS, you distribute your filesystem across
multiple servers, and even if some of the servers fail or are
taken over by an attacker, the entire filesystem continues to
work correctly, and continues to preserve your privacy and
security. You can easily share specific files and directories
with other people.

In addition to the core storage system itself, volunteers
have built other projects on top of Tahoe-LAFS and have
integrated Tahoe-LAFS with existing systems, including
Windows, JavaScript, iPhone, Android, Hadoop, Flume, Django,
Puppet, bzr, mercurial, perforce, duplicity, TiddlyWiki, and
more. See the Related Projects page on the wiki [3].

We believe that strong cryptography, Free and Open Source
Software, erasure coding, and principled engineering practices
make Tahoe-LAFS safer than RAID, removable drive, tape,
on-line backup or cloud storage.

This software is developed under test-driven development, and
there are no known bugs or security flaws which would
compromise confidentiality or data integrity under recommended
use. (For all important issues that we are currently aware of
please see the known_issues.rst file [2].)


COMPATIBILITY

This release should be compatible with the version 1 series of
Tahoe-LAFS. Clients from this release can write files and
directories in the format used by clients of all versions back
to v1.0 (which was released March 25, 2008). Clients from this
release can read files and directories produced by clients of
all versions since v1.0. Servers from this release can serve
clients of all versions back to v1.0 and clients from this
release can use servers of all versions back to v1.0.

Except for the new optional MDMF format, we have not made any
intentional compatibility changes. However we do not yet have
the test infrastructure to continuously verify that all new
versions are interoperable with previous versions. We intend
to build such an infrastructure in the future.

The new Introducer protocol added in v1.10 is backwards
compatible with older clients and introducer servers, however
some features will be unavailable when an older node is
involved. Please see docs/nodekeys.rst [14] for details.

This is the eighteenth release in the version 1 series. This
series of Tahoe-LAFS will be actively supported and maintained
for the foreseeable future, and future versions of Tahoe-LAFS
will retain the ability to read and write files compatible
with this series.


LICENCE

You may use this package under the GNU General Public License,
version 2 or, at your option, any later version. See the file
COPYING.GPL [4] for the terms of the GNU General Public
License, version 2.

You may use this package under the Transitive Grace Period
Public Licence, version 1 or, at your option, any later
version. (The Transitive Grace Period Public Licence has
requirements similar to the GPL except that it allows you to
delay for up to twelve months after you redistribute a derived
work before releasing the source code of your derived work.)
See the file COPYING.TGPPL.rst [5] for the terms of the
Transitive Grace Period Public Licence, version 1.

(You may choose to use this package under the terms of either
licence, at your option.)


INSTALLATION

Tahoe-LAFS works on Linux, Mac OS X, Windows, Solaris, *BSD,
and probably most other systems. Start with
docs/quickstart.rst [6].


HACKING AND COMMUNITY

Please join us on the mailing list [7]. Patches are gratefully
accepted -- the RoadMap page [8] shows the next improvements
that we plan to make and CREDITS [9] lists the names of people
who've contributed to the project. The Dev page [10] contains
resources for hackers.


SPONSORSHIP

Atlas Networks has contributed several hosted servers for
performance testing. Thank you to Atlas Networks [11] for
their generous and public-spirited support.

And a special thanks to Least Authority [12], which employs several
Tahoe-LAFS developers, for their continued support.

HACK TAHOE-LAFS!

If you can find a security