peerio.com

[Cathal Garvey]

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