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.