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