-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It's also worth noting that they are using Cloudflare. Has Cloudflare made any statements about whether they log traffic and/or hand over data to governments? On 1/14/15 11:32 AM, Cathal Garvey wrote:

...

It's an obvious vulnerability to use a domain that's controlled by the US and its allies.

More good reasons to implement an open server! :)

On 14/01/15 18:32, Mirimir wrote:

...

On 01/14/2015 07:22 AM, Cathal Garvey wrote:

...

Just landed beta: open source, minilock-based crypto, really nice design. Server side storage of end-to-end encrypted files and messages, 1.3Gb of storage for free. No ads.

https://peerio.com

Very cool. Thanks :)

...

I expect that the "product" will end up being "storage space", which is fine by me! Right now the server code isn't open, though the protocol (and therefore API) is very well documented in the git source:

https://github.com/PeerioTechnologies/peerio-client

Expect to see it banned in the UK soon. :)

It's an obvious vulnerability to use a domain that's controlled by the US and its allies.

-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJUtshUAAoJEOrRfDwkjbpTDKkIALHPT+y3enTfO3OU3m3rIEU5 gHf3ZEqoN1cbryHZq3UrZMMMOVUGDzL/OzU9N5cq0HoQTUw9jCfgrYRmnYxJDjTP chppyMeMFZkrckL+UaksjhyB0N+uPhgWsqfwbmw54xcWeYLY8eGD7xzOsdInsNsu +tzaYCNd6CKSm4lnxARaPa6wOB875vJLsJ5SeoKVHDUyMZrgQHRNtxnN3sOW7paM gQ8IJGqD3tgUyv1VTcUv37XEeyLAOJqqn5Xzt1C7h9Jss8bIYodWkTS9Mglm9kek lmtdYuDLmLNmSonMFfLOxt5uj9Y1KEzd5HmNfgQPnYBimxtmxgY/isgnfRBUdjc= =X26g -----END PGP SIGNATURE-----

On 01/14/2015 01:01 PM, Cathal Garvey wrote:

...

Has Cloudflare made any statements about whether they log traffic and/or hand over data to governments?

Well, anyone with a brain knows they do, and that statements from a US company are meaningless because nobody wants to go to jail over an NSL.

:)

What a top-level observer can see (AFAIK) is who's logged in, probably what their username/keyID is, and how much they're talking to the server.

Because peerio uses miniLock formatted messages, the potential exists for minimal-knowledge service, but from the github docs it seems the server maintains an entry for which user is allowed to access which encrypted files, and therefore reveals to an observer who's the recipient.

So, it's a metadata-rich service, little better in that regard than email.. although the encryption is pretty well designed and unless you set up a "PIN" there's no permanent storage of private keys even on your computer, so it's also quite secure when crossing borders.

So it would be prudent to use pseudonyms, and to access via some mix of VPN(s), JonDonym and Tor (according to ones need for anonymity vs speed). And using devices with removable local storage, there would be no traces to be inspected by adversaries. Cool. But still, how is peerio more secure spideroak, for example?

Also, there is a feature that clearly relies on compliant clients, where you can delete files from the server including copies sent to clients. Obviously if the attached files are downloaded from the system, this can't reach them, but it will destroy any "authenticated" copies of the messages from the server, if it works (you're trusting the server). OPSEC wise, this is a nice feature because it means you can clean up after yourself and keep the authenticated-data-at-rest on either end of a conversation to a minimum.

On 14/01/15 19:49, aestetix wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

It's also worth noting that they are using Cloudflare. Has Cloudflare made any statements about whether they log traffic and/or hand over data to governments?

Dnia środa, 14 stycznia 2015 22:09:12 Cathal Garvey pisze:

...

So it would be prudent to use pseudonyms, and to access via some mix of VPN(s), JonDonym and Tor (according to ones need for anonymity vs speed). And using devices with removable local storage, there would be no traces to be inspected by adversaries.

Well, I use my real name in most places and communicate a lot with real-world friends and family by email, su using Peerio is therefore a step up in security for me even if I continue to go by my usual name and use my usual IPs.

If you need hard anonymity, this is only a marginal gain over regular email because metadata (when, who, how, where) is a significant threat to anonymity. So yea, use a burner email when setting up a peerio account (no longer required after setup, probably a throwback to email-as-salt in miniLock plus contact discovery by known email address), then use through Tor (do research whether websockets are tor-safe?).

...

Cool. But still, how is peerio more secure spideroak, for example?

Spideroak appears to be more about file storage and sync, whereas Peerio seems to me to simply be a better approach to server:client email. It's down to the bone: message-passing with attachments, and a nice UI.

As a crypto-app, it's targeted at the mainstream, and people who interact with the mainstream. People on this list will have better, more secure ways of communicating, but Nadim (to his credit) excels at making crypto-apps that can appeal to normal users while adding a significant privacy. It's an easier sell from "us" to "them".

With server code closed, it doesn't make sense to me to "sell" it to anybody. -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147

On January 15, 2015 1:20:22 PM EET, Cathal Garvey wrote:

If the server code were open, how would you know the server was actually running that code anyway? Having the protocol documented so thoroughly makes the task of writing an alternative server trivial if time-consuming. I'd obviously prefer the server were AGPL, and I hope someone will write an AGPL'd server and federation.

For now though, the client is open source, the crypto doesn't suck, the

UX is excellent, and the threat model is pretty transparent. I'm *never* going to inflict PGP on friends, but I'll happily inflict this on them.

Since this is mostly for synchronous communication, you can inflict jabber+otr, which has all the benefits you mention above.

Dnia czwartek, 15 stycznia 2015 11:20:22 Cathal Garvey pisze:

If the server code were open, how would you know the server was actually running that code anyway?

Not much. But it would allow others to run the server code and offer similar service, at the very least.

Having the protocol documented so thoroughly makes the task of writing an alternative server trivial if time-consuming. I'd obviously prefer the server were AGPL, and I hope someone will write an AGPL'd server and federation.

Of course. The "time-consuming" part is what bothers me. I *could* throw in an hour or two to set-up a peerio server had the code been available; I have absolutely *no way in hell* of throwing in days or weeks of work to implement their protocol.

For now though, the client is open source, the crypto doesn't suck, the UX is excellent, and the threat model is pretty transparent. I'm *never* going to inflict PGP on friends, but I'll happily inflict this on them.

So far, as far as I can see, you're not even inflicting PGP on us here, let alone your friends. -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On this whole point of Gnupg (gpg) and some of the issues with using it (and transitions etc), may I (well, I just will) recommend this, from sources I've compiled in a way that people seem to like and have found helpful: Crazy Strong: @gnupg "learn or die" in 2015 #31c3 All systems https://securityinabox.org/thunderbird_main See also http://futureboy.us/pgp.html#GettingStarted http://www.g-loaded.eu/2010/11/01/change-expiration-date-gpg-key/ on twitter as: https://twitter.com/AnonyOdinn/status/550826144014934016 which has caused Gnupg / thunderbird / etc. awareness to reach 14,685 accounts that might otherwise not have seen it. based on an analysis from http://tweetreach.com/reports/12801475 Learn or die folks. but you may ask, what about the transitions? new machine? older key issues? proper use? getting stronger new key? etc. valid questions! which is what I am asking myself right now (since I have some old key issues that I am trying to work through and I didn't have good answers). fortunately, rysiek came to the rescue in a very timely way, and gave me permission to republish (rysiek's) statement which appears below: rysiek explains: GPG Key Transition: http://rys.io/en/147 Zmieniam klucz GPG: http://rys.io/pl/147 twitter: https://twitter.com/AnonyOdinn/status/552630836747456512 The instructions are very clear and helpful. (Thank you rysiek!) I'll be developing my own transition statement at some point soon using rysiek's page as a guide. Not sure of when, but rysiek's page will be my guide. Cathal Garvey:

...

So far, as far as I can see, you're not even inflicting PGP on us here, let alone your friends.

I did for a while, but then I moved hardware and didn't see any reason to set up PGP again. At best, it was a signal to people that I cared about security/privacy, at worst it was making everything I posted non-repudiable for no useful reason.

The fact that miniLock is authenticated but repudiable makes it a better bet for PGP-usecase purposes *anyway*, and my minilock ID is in my signature (again, had lapsed by accident) for people who want to use miniLock outside of peerio.

But, miniLock isn't (opportunistic pun) "turn-key", it requires launching, authenticating, dropping a file to encrypt, typing in a miniLock ID to encrypt to (encrypting to yourself probably makes it non-repudiable if someone acquires your private key, beware!), downloading the encrypted file, and then transmitting the encrypted file out-of-band.

Now, implementing Peerio server is something I endorse. If I weren't too busy, I'd investigate doing it myself, it looks like fun. If anyone does feel like it, they have miniLock for JS-based servers, and deadLock for Python-based servers (needs some work/bugfixes).

On 15/01/15 16:44, rysiek wrote:

...

Dnia czwartek, 15 stycznia 2015 11:20:22 Cathal Garvey pisze:

...

If the server code were open, how would you know the server was actually running that code anyway?

Not much. But it would allow others to run the server code and offer similar service, at the very least.

...

Having the protocol documented so thoroughly makes the task of writing an alternative server trivial if time-consuming. I'd obviously prefer the server were AGPL, and I hope someone will write an AGPL'd server and federation.

Of course. The "time-consuming" part is what bothers me. I *could* throw in an hour or two to set-up a peerio server had the code been available; I have absolutely *no way in hell* of throwing in days or weeks of work to implement their protocol.

...

For now though, the client is open source, the crypto doesn't suck, the UX is excellent, and the threat model is pretty transparent. I'm *never* going to inflict PGP on friends, but I'll happily inflict this on them.

So far, as far as I can see, you're not even inflicting PGP on us here, let alone your friends.

- -- http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJUuNWoAAoJEGxwq/inSG8Cww8H/1EwN1FZ9ghrvsNlf+BcfoO4 EGVz2zuT7fkz6zNUahf6VPHIWeYJszspEv3e6a9Kn7m9Hbt6YPPBc22o/aeadaFi jQjgj7dSfx5eYJbhw+fNANh4VLgpgxhqTn6rmkj+VuFveebYoFkAivGok7hX8B7r nO4jgAy9xq4jyw6ovWSpCkBfC7YemmZeYQbFtuxlTBHe4/RBbwG0xNukYvxfWZbM SA0a7RQTFXWN3r0YhPSbKGlsToyhdYK+f6wCqbzQQUpCmG7mZ+mk/VatV3dYsM84 OzIjrLzSHYM+0Ds9SG2X+PVsSkPjYlTQ3qWbRFgVrc3ypTDOjfUx+yXVngUN24Q= =6gAV -----END PGP SIGNATURE-----

On 01/14/2015 03:09 PM, Cathal Garvey wrote:

...

So it would be prudent to use pseudonyms, and to access via some mix of VPN(s), JonDonym and Tor (according to ones need for anonymity vs speed). And using devices with removable local storage, there would be no traces to be inspected by adversaries.

Well, I use my real name in most places and communicate a lot with real-world friends and family by email, su using Peerio is therefore a step up in security for me even if I continue to go by my usual name and use my usual IPs.

If you need hard anonymity, this is only a marginal gain over regular email because metadata (when, who, how, where) is a significant threat to anonymity. So yea, use a burner email when setting up a peerio account (no longer required after setup, probably a throwback to email-as-salt in miniLock plus contact discovery by known email address), then use through Tor (do research whether websockets are tor-safe?).

...

Cool. But still, how is peerio more secure spideroak, for example?

Spideroak appears to be more about file storage and sync, whereas Peerio seems to me to simply be a better approach to server:client email. It's down to the bone: message-passing with attachments, and a nice UI.

How about Pond as email replacement?

As a crypto-app, it's targeted at the mainstream, and people who interact with the mainstream. People on this list will have better, more secure ways of communicating, but Nadim (to his credit) excels at making crypto-apps that can appeal to normal users while adding a significant privacy. It's an easier sell from "us" to "them".

I'm curious what you (and others here) think about Keybase, which also seems heavily targeted at normal users. There was some discussion here in mid 2014, but Keybase has been tweaked a lot since then. I'm quite impressed with its usability, but I don't have the expertise to properly evaluate its security. I am uncomfortable with the option of uploading private GnuPG keys, and counting on symmetric encryption for securing them. Better I think would be helping users understand how to properly migrate keys between devices, or perhaps to use smartcards.

On 14/01/15 21:52, Mirimir wrote:

...

On 01/14/2015 01:01 PM, Cathal Garvey wrote:

...

Well, anyone with a brain knows they do, and that statements from a US company are meaningless because nobody wants to go to jail over an NSL.

:)

...

What a top-level observer can see (AFAIK) is who's logged in, probably what their username/keyID is, and how much they're talking to the server.

Because peerio uses miniLock formatted messages, the potential exists for minimal-knowledge service, but from the github docs it seems the server maintains an entry for which user is allowed to access which encrypted files, and therefore reveals to an observer who's the recipient.

So, it's a metadata-rich service, little better in that regard than email.. although the encryption is pretty well designed and unless you set up a "PIN" there's no permanent storage of private keys even on your computer, so it's also quite secure when crossing borders.

So it would be prudent to use pseudonyms, and to access via some mix of VPN(s), JonDonym and Tor (according to ones need for anonymity vs speed). And using devices with removable local storage, there would be no traces to be inspected by adversaries.

Cool. But still, how is peerio more secure spideroak, for example?

...

Also, there is a feature that clearly relies on compliant clients, where you can delete files from the server including copies sent to clients. Obviously if the attached files are downloaded from the system, this can't reach them, but it will destroy any "authenticated" copies of the messages from the server, if it works (you're trusting the server). OPSEC wise, this is a nice feature because it means you can clean up after yourself and keep the authenticated-data-at-rest on either end of a conversation to a minimum.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 tl'dr Look... Cathal, I do like what you've done in the tiny realm of code ~ short, simple, and to the point, some examples being: Deadlock ~ dead simple encryption https://pypi.python.org/pypi/deadlock P2P, serverless microstatus system in 30 lines of pure python https://github.com/cathalgarvey/tinystatus (slooooowwwwww claaaaaaaappssssss) So with that out of the way, I have to say, though, your criticism which has appeared on my TL before of PGP is in my view, unwarranted, because, GnuPGP just aren't getting the funding need(ed) to get what should be done, done. It's been done essentially by one person. And frankly they could use a bit of help in getting out the word. Here's a thoughtful post from bytemark on this subject: (Please read it) https://blog.bytemark.co.uk/2014/12/31/gnupg-funding-drive (from Dec. 31, 2014) Then go on to read this thing: https://gnupg.org/donate/index.html As you see they accept all kinds of payment vehicles (and also bitcoin is one of them) And now here's the kicker: This two-person team which they are trying to get funded, IS NOT FUNDED! Take a look here: https://gnupg.org/index.html Again: NOT. FUNDED. And yes, interfaces like Keybase.io _are_ the future (I've been playing around with it and currently have it in my signature, though I use a different key block (not keybase) for people to use for to import in association with my e-mail), because they make it easier for a larger number of people to access keys either through something like keybase service where they host keys, or through a CLI where you hold all that closely. Merkle tree, blockchain, etc. But this begins in my view with a strong froundation, which we have from the work which was done from Gnupg. (In fact, Keybase.io, and any business like it in the future, relies on Gnupg.) If I was rolling in dough ($$) right now I would dump a giant fat amount of 86,000 € that they are missing so that they would be able to get going on the Gnupg second developer's work right away. So... enough of the rambling on, can someone who knows someone who has benefited from this economic ups and downs, please forward this e-mail on to them and ask them if they'd be willing to contribute to https://gnupg.org/donate/index.html I have absolutely zero financial interest in seeing this happen but I know it would help make a better world. - -O Cathal Garvey:

...

How about Pond as email replacement?

I've looked at Pond long enough to see that it calls upon Tor for most of the anonymity heavy-lifting, and that it is clearly targeted at technical users. Most of the people in my life who I speak privately to are not technical. I don't think trivial UX is near in Pond's development roadmap.

...

I'm curious what you (and others here) think about Keybase, which also seems heavily targeted at normal users. There was some discussion here in mid 2014, but Keybase has been tweaked a lot since then. I'm quite impressed with its usability, but I don't have the expertise to properly evaluate its security. I am uncomfortable with the option of uploading private GnuPG keys, and counting on symmetric encryption for securing them. Better I think would be helping users understand how to properly migrate keys between devices, or perhaps to use smartcards.

Keybase could have been a great way to encourage PGP uptake among normal people years ago when things were accepted to be difficult universally, but PGP's days are behind us. PGP makes a good way to sign code but remains a terrible way to communicate securely, because although it's "uncrackable" when used correctly, it's very easy to accidentally screw up using PGP on either end of the conversation. Also, the lack of PFS ignores parts of the modern threat model that were speculative when PGP was created.

Suffice to say that, even ignoring the issues with Keybase encouraging key escrow by "allowing" or encouraging key upload (!!!), I don't think it helps. Perhaps as a basis on which to build a web-of-trust that can be transposed into newer cryptosystems, but the key escrow part makes falsification of trust a real possibility.

Anyway, maybe that's just me.

- -- http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJUuN5SAAoJEGxwq/inSG8CdKAH/2/gttWAuEztLTgK5OnrGwQR Qe0kBfxRr8rlG64jtVvRp9nJODiCOMZdQczbN1Vs4GvKmTEAfULLj/m3PbRMkfSB lJw6sXZtF2XjjstqWgvrFpi49htRtlxT+xa9kMc26jxatR9ux62mcdQLyKPx78NW sjv/Hhd1xGLGsWm0o2so3f+9SX6cfBJS50OvgxEHyZqX/S/4AK6F+td1lurt0H+K haTAR3VssPVmz2g+jXcakLUoD1EdCW1t57ODFul+93y2QyOBUReLbAvkdLXyY8fl BNu+fQnSIKrUMQScu87XKqews1VBt3BqeEmYmGdacQt1f545RrJTNyzd9tJL/+Q= =ntrD -----END PGP SIGNATURE-----

Dnia piątek, 16 stycznia 2015 10:11:48 Seth pisze:

On Fri, 16 Jan 2015 01:48:02 -0800, odinn

wrote:

...

And now here's the kicker: This two-person team which they are trying to get funded, IS NOT FUNDED!

Take a look here:

https://gnupg.org/index.html

Again:

NOT. FUNDED.

This line of argument seems to imply that throwing money at GnuPG will somehow fix its well-known usability issues. http://secushare.org/PGP

Some of those issues are not easily fixable (or at all, because of how e-mail works); but some of them are fixable, if only the right incentives show up. Maybe we could find a way to fund GnuPG/Enigmail/MailPile in a way that would incentivise good UI/UX? I don't know... we seem to have a _crowd_ here, maybe we could find a way _fund_ such an endaevour? -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147

On 01/16/2015 11:11 AM, Seth wrote:

On Fri, 16 Jan 2015 01:48:02 -0800, odinn wrote:

...

And now here's the kicker: This two-person team which they are trying to get funded, IS NOT FUNDED!

Take a look here:

https://gnupg.org/index.html

Again:

NOT. FUNDED.

This line of argument seems to imply that throwing money at GnuPG will somehow fix its well-known usability issues. http://secushare.org/PGP

OK, I'll bite :) | 1. Downgrade Attack: The risk of using it wrong. ... | The mere existence of an e-mail address in the process is a problem. ... | 2. The OpenPGP Format: You might as well run around the city naked. ... | 3. Transaction Data: Mallory knows who you are talking to. Well, correspondents ought to: 1) always use pseudonyms if they care about attribution; 2) avoid meaningful subject lines; and 3) use VPNs, JonDonym and Tor to obscure network connectivity. Given that, why care that adversaries see OpenPGP? | 4. No Forward Secrecy: It makes sense to collect it all. So what? Just secure your shit properly! | 5. Cryptogeddon: Time to upgrade cryptography itself? Smart folk who care about attribution never put anything online that links their pseudonyms to their real names. Just sayin'. And they rotate their pseudonyms periodically. So stored messages go stale within a year or two, tops. | 6. Federation: Get off the inter-server super-highway. That's prudent for stuff that matters. But OpenPGP is still good within the transport layers. | 7. Discovery: A Web of Trust you can't trust. I've never used WoT, and tend to agree. WoT is especially impractical because I don't at all mix meatspace and online activity. I am starting to like Keybase, however. I don't worry very much about sharing publicly who my conversation partners are. I always use pseudonyms, and so do many of my conversation partners. Sometimes we all use multiple pseudonyms, just for fun :) | 8. PGP conflates non-repudiation and authentication. Again, use those pseudonyms! | 9. Statistical Analysis: Guessing on the size of messages. Having my pseudonyms profiled doesn't worry me greatly. | 10. Workflow: Group messaging with PGP is impractical. Why bother? Just set up a Tor hidden-service forum, or whatever. | 11. Complexity: Storing a draft in clear text on the server I use both IMAP and POP, and I've never seen plaintext drafts stored on the server. I believe that Enigmail's "convenient encryption settings" (in particular "auto send encrypted") prevent this, as long as you have the public key of the person whom you're drafting a message to. It's also prudent to switch to manual mode, and to set "confirm before sending" to "Always". | 12. Overhead: DNS and X.509 require so much work. Who's enslaved? One uses whatever tools are appropriate. | 13. Targeted attacks against PGP key ids are possible This is an advantage of Keybase. Then we're not depending on the KeyID, or even on the fingerprint, but rather on an identity that's multiply and independently authenticated. | 14. TL;DR: I don't care. I've got nothing to hide. I hide in many ways, and don't depend on message encryption ;) My "preferences, habits and political views" are fragmented among multiple unlinked personas. How to do that is one of my key soapbox topics ;) | 15. The Bootstrap Fallacy: But my friends already have e-mail! Again, it's a tool. But of course it's not the only tool.

On 01/17/2015 05:14 PM, Seth wrote:

On Fri, 16 Jan 2015 17:02:40 -0800, Mirimir wrote:

...

OK, I'll bite :)

I was going to do the point by point rebuttal but frankly it gets exhausting and the topic has been beat to death here and on other mailing lists.

:)

My closing points are:

A) GnuPG is powerful and effective crypto tool for technically advanced users _who also_ have the discipline to practice good Opsec.

The Internet embodies poor OPSEC :(

B) It's a terrible crypto tool for anyone else, they're going to phuk it up.

*sigh*

1) third party broad spectrum surveillance from cromnibus.

Metadata wise this is a real problem with the system as currently envisaged, but would frankly apply to any hosted-ciphertext platform.

"Instead of dealing with key storage, Peerio generates a user’s private key from his passphrase every time he or she logs in." from: http://www.wired.com/2015/01/peerio-free-encryption-app/ That may or may not accurately describe the process, however.

This is correct; Peerio uses MiniLock under the hood for crypto, and private keys for minilock are generated deterministically; when you "log out" the key is not stored permanently (although JS can't wipe RAM so a closer-to-metal client would be nice).

3) Free, or not? Apparently there is a paid option, and a free option initially at launch, there is a open source repository on github. To the extent that the crypto is tied to a company (kind of assumed, if there is a paid option and there is an LLC or something like that), then the corporation is vulnerable to being shut down or at the very least "conditioned" ~ being told what to do when "crypto licenses" come

They're in free beta, my understanding is they'll charge for storage. There's not much that can be done to wind back the crypto as it's all client-side, and if their server were shut down, as I've mentioned before, the server behaviour is all documented on Github. One useful way to look at this: GPG is what most recommend for crypto, but it's metadata rich and requires usually closed platforms to distribute ciphertexts (you may not use Yahooglesoft but your recipients will usually). In recent discussions on this list, the use of a centralised key distribution *company*, keybase, has also been accepted to some extent (though I'm not too happy..). miniLock is designed as a spiritual descendent of PGP with many use-case improvements and a much simpler threat model. You can use miniLock instead of GPG across email, and it will leak less metadata than GPG by virtue of using ephemeral keys that don't directly link a message to its sender or recipients. Peerio is like Gmail plus Keybase for miniLock; it serves exactly those purposes. We would all (me emphatically included) rather if it ran on a store/forward PGP mixnet, provided it retained good UX to appeal to the masses, but right now, it's a centralised service that hides the content and format of communications while unavoidably having total access to the metadata of from who, to whom, and when. So yea, centralised and closed ain't good. They are the warts I'd like to see fixed with a federated and/or mixed backend. But the frontend is just as open as GPG is, and we already generally endorse the use of open front-ends to work around closed back-ends. I may be motivated soon to re-implement miniLock in Go as a learning excercise (still a Golang noob here), in which case it could be a short hop from there to a server/client implementation for Peerio, too. But, I'm not committed to that yet and have written not an `iota` of code yet, so by all means beat me to it. On 20/01/15 07:07, odinn wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

no, peerio, problematic due to, in part,

1) third party broad spectrum surveillance from cromnibus. (kind of a serious problem for anything that involves initial setup or later login through website actually) See Title III, Subtitle A, Section 309 http://www.gpo.gov/fdsys/pkg/BILLS-113hr4681enr/pdf/BILLS-113hr4681enr.pdf

this is mitigated in part for such services where keys are not hosted by the service (e.g. w/ keybase you can refuse to have stuff hosted on keybase, and can (if you wish) do commands only from CLI after deciding to host keys on your own machine, but assuming you log in through web-app / website, then you end up subject to this third party stuff mentioned above)

2) If I understand this correctly with peerio (and I don't possibly, since I am unlikely to ever use it as it appears to be a centralized service), but: "Instead of dealing with key storage, Peerio generates a user’s private key from his passphrase every time he or she logs in." from: http://www.wired.com/2015/01/peerio-free-encryption-app/ That may or may not accurately describe the process, however.

3) Free, or not? Apparently there is a paid option, and a free option initially at launch, there is a open source repository on github. To the extent that the crypto is tied to a company (kind of assumed, if there is a paid option and there is an LLC or something like that), then the corporation is vulnerable to being shut down or at the very least "conditioned" ~ being told what to do when "crypto licenses" come into play, which already exist in Russia, for example, are anticipated in the UK (see also Belarus, where the Info Minister thinks that the Internet exists to "serve the Fatherland"), and in the US, where Obama is developing a really warm friendship with Cameron on the anti-crypto front.

Frankly I am just going to stay far away as I can from anything that involves this kind of web-based model. There is too much compromise involved and too much insecurity.

Cathal Garvey:

...

...

So it would be prudent to use pseudonyms, and to access via some mix of VPN(s), JonDonym and Tor (according to ones need for anonymity vs speed). And using devices with removable local storage, there would be no traces to be inspected by adversaries.

Well, I use my real name in most places and communicate a lot with real-world friends and family by email, su using Peerio is therefore a step up in security for me even if I continue to go by my usual name and use my usual IPs.

If you need hard anonymity, this is only a marginal gain over regular email because metadata (when, who, how, where) is a significant threat to anonymity. So yea, use a burner email when setting up a peerio account (no longer required after setup, probably a throwback to email-as-salt in miniLock plus contact discovery by known email address), then use through Tor (do research whether websockets are tor-safe?).

...

Cool. But still, how is peerio more secure spideroak, for example?

Spideroak appears to be more about file storage and sync, whereas Peerio seems to me to simply be a better approach to server:client email. It's down to the bone: message-passing with attachments, and a nice UI.

As a crypto-app, it's targeted at the mainstream, and people who interact with the mainstream. People on this list will have better, more secure ways of communicating, but Nadim (to his credit) excels at making crypto-apps that can appeal to normal users while adding a significant privacy. It's an easier sell from "us" to "them".

On 14/01/15 21:52, Mirimir wrote:

...

On 01/14/2015 01:01 PM, Cathal Garvey wrote:

...

Well, anyone with a brain knows they do, and that statements from a US company are meaningless because nobody wants to go to jail over an NSL.

:)

...

What a top-level observer can see (AFAIK) is who's logged in, probably what their username/keyID is, and how much they're talking to the server.

Because peerio uses miniLock formatted messages, the potential exists for minimal-knowledge service, but from the github docs it seems the server maintains an entry for which user is allowed to access which encrypted files, and therefore reveals to an observer who's the recipient.

So, it's a metadata-rich service, little better in that regard than email.. although the encryption is pretty well designed and unless you set up a "PIN" there's no permanent storage of private keys even on your computer, so it's also quite secure when crossing borders.

So it would be prudent to use pseudonyms, and to access via some mix of VPN(s), JonDonym and Tor (according to ones need for anonymity vs speed). And using devices with removable local storage, there would be no traces to be inspected by adversaries.

Cool. But still, how is peerio more secure spideroak, for example?

...

Also, there is a feature that clearly relies on compliant clients, where you can delete files from the server including copies sent to clients. Obviously if the attached files are downloaded from the system, this can't reach them, but it will destroy any "authenticated" copies of the messages from the server, if it works (you're trusting the server). OPSEC wise, this is a nice feature because it means you can clean up after yourself and keep the authenticated-data-at-rest on either end of a conversation to a minimum.

- -- http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn -----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJUvf6+AAoJEGxwq/inSG8CZx4H/RWY/CBH40KPquXxAUmBL+1a oq2wHzOJ+hYqZAW2VpaBlZXKydk77WloKpgjQg3WzxFn6xiqbL00W0MacgX2fWCD TksPNJSYdE4ZGnzK5FR+0M1aini5+Fc+gI7tliAR0rEetgHStXTHS8a1NhMyRZ66 H+PzbyQg/jfzKym+2dDtexgoUU5Z0t8kfpxnEDV8FBM2DtMJKCuSVuMQv1ct3dxa IZyavMFBL/xUoqHyD/kswWM75+yypfXo1qJqOVDb5bCsxpIy/wp1XHeWa7z52ZIx HMeVDEbtF6jy2yReqrNHW7ODEG1IY0H4/LzHz9UcpknOrpV3JbTg6l+dYBEz6RI= =YqX1 -----END PGP SIGNATURE-----

-- Twitter: @onetruecathal Phone: +353876363185 miniLock: JjmYYngs7akLZUjkvFkuYdsZ3PyPHSZRBKNm6qTYKZfAM peerio.com: Use email or phone. Uses above miniLock key.