Show HN: GPG emails for everyone, from everywhere – open sourced | Hacker News Reader

Show HN: GPG emails for everyone, from everywhere – open sourced

kinko.me

84 pointsradiospiel51 comments

Open articleView on HN

The astroturfing on this article is incredible:

https://news.ycombinator.com/threads?id=dreamdweller

https://news.ycombinator.com/threads?id=banpei

https://news.ycombinator.com/threads?id=dramatise

https://news.ycombinator.com/threads?id=kc99

https://news.ycombinator.com/threads?id=conn23

https://news.ycombinator.com/threads?id=Darkpandemic

https://news.ycombinator.com/threads?id=SanktKlaus

https://news.ycombinator.com/threads?id=freemefromthis

https://news.ycombinator.com/threads?id=SimonJester89

It's possible that this one article caused all the above users to sign up at the same time just to add their one and only HN comment. Occam's razor suggests a different conclusion, however.

Not trying to defend anybody but it is really likely that people just learn to know about HN through linking this page in a facebook status update, which is what they did.

And Occam actually would support this, considering it's a much simpler solution than people going about creating accounts, logging in and out of them, to fake positive feedback on a website that matters for technical discussion but not much for marketing value (outside the US).

That's a valid point, but even still if the link was shared on Facebook then why wouldn't those people comment on Facebook instead of going to the trouble of signing up for some site they've never been to and don't plan to participate in? Unless they were asked to sign up and add a comment of support, which isn't much better.

Nice project. A year ago I would have said that there was no market for this; it'll be interesting to see if that has changed in the post-Snowden world.

I have one reservation. From https://kinko.me/faq/ :

The box receives the email and checks that it knows all GnuPG encryption keys needed to forward an encrypted version of the mail. If it does not it rejects the email. Otherwise it encrypts your email and sends it to the receivers’ email accounts.

This makes it sound like a user can only send email to recipients whose GPG keys they have. If this is the case, this is a huge red flag; the past two decades of encrypted email usage has proved conclusively that the huge majority of users do not care about privacy. If as a kinko user I have to get GPG keys for all my friends, this will never take off.

I'd strongly recommend encrypting where possible, but allowing unencrypted copies to be sent where no gpg key is found. Perhaps there could be a warning and resend, eg 'Some of the recipients for this mail have no gpg keys. Please reply to this message to confirm you understand that this message will be sent unencrypted to those recipients'?

Also, if you can solve the user experience problem with generating and using GPG keys, you will be doing the world a great service.

Good luck! Will be following the project with interest.

You are right, the FAQ is probably not right at this point, In fact, the box uses keys it knows about, and tries to get keys when receiving encrypted mail. But of course you can send unencrypted email.

(Otherwise you would have to use a specific email not only for contacts that don't use GnuPG, but also for registration with 99% of all the websites out there.)

As for the business case: yes, it probably is really hard to do something open source on everyday hardware. I don't see big business here - but something to make the world a more private place.

Looks good.

FWIW, GNU Anubis (an MTA) can do gpg signing. Of course, there's a big gap between 'can do' and actually does, which is where this (Kinko) comes in. http://www.gnu.org/software/anubis/manual/anubis.html#SEC64

"Emails are synced from the users’ email accounts via IMAP to the box and are stored in plaintext in a secure storage area on the box"

I've seen a better (opensource) approach to use gpg to securely store email: upon receiving a message, if not already encrypted, use the public key of the account recipient to encrypt it. This way, all email is encrypted with your pgp key. The downside , which this box is trying to solve, is that the (imap) client will need to do the decryption, so it's not transparent to the user. There's also filters for well known MTA (exim,postfix,etc) that will encrypt/decrypt using pgp or s/mime (user/host) keys upon connection.

I see another problem with the 'box' approach, it will need the plain-text passphrase, so if someone steals or has access to your (mail)box, all your email is plain-text and you will have to revoke the pgp key.

Not only that, if you are not aware of the intrusion, someone can impersonate you, since they can sign any message/document with those credentials.

How about redundancy/backups? If the net connection goes down or box/house stops working, what happens to the emails?

The assumption about this box is that it is in a reasonably safe place. Also, everything on the box is stored encrypted, you need a master key to unlock the box and get it running.

Note: This is not spy stuff. This is a reasonably secure environment for your email (and as secure as the average's persons desktop is)

My point was that for a non-pgp aware imap client to read the encrypted emails, the passphrase needs to be somewhere, probably in RAM all the time, making it a target, so if there's an exploit, having it encrypted or not is moot. It solves the 'steal box' problem and since it's not spy stuff, we don't have to worry about cold boot attacks ;)

On a desktop, the pgp credentials either exists momentarily (user input) or through an agent, so at first sight it would seem that would be safer, although then we could also argue that a desktop is probably not as safe as this box due to all the other software that is run by the user.

Ultimately this is a decision between usability and security, and I am afraid there is no good answer here. We still do our best to prevent key theft, even in the case of someone hacking into a running box. There is only one process with access to the keys, which runs in a separate system account (each software component runs under its own account anyways) and which is not accessible from the outside. Still, one could potentially hack into the system and become root.. but this is less likely to happen on a separate box than on a full-blown desktop (with the average user giving out his/her root password whenever some installer asks for it).

A name change is in order due to the fact that Fedex owns the Kinko's trademark for email service.

I thought kinko is fedex'es defunct parcel delivery business? Will check that, thank you.

No it was their very popular printing stores before they renamed:

https://en.wikipedia.org/wiki/FedEx_Office

For decades they were a popular photocopying and printing place in the US. For a while after that they were owned by Fedex but did basically the same stuff. Five or six years ago they lost the "kinko" but it's still very recognizable as the name of a printing service.

So I guess what I'm saying is you could probably use something hipper and less trademark-infingey. How about "an expression of support or encouragement" from Jamaica?

http://www.urbandictionary.com/define.php?term=big%20ups

Instead of "kinko me" and kinkoing one another the kids could give one another "BIG UPS." I see nothing that could go wrong with this plan.

big ups, I like that, but speaking of parcels: isn't UPS just around the corner ;)

Looks like an interesting idea, but why choose a trademarked name? Any amount of popularity will bring attention and you'll have to change the name, thus diluting at least some of your early exposure.

the name is Japanese for safe box

Doing this in hardware is IMHO a great step forward; general purpose computers are just too easy to compromise. Of course, the box has to be secure itself ..

The box is built around an open sourced ARM board. The current prototype is a Olimex LIME. And yes: moving crypto in a separate box should improve security - when you install something on your desktop it doesn't get root there!

I assume this could run on a Raspberry Pi or BeagleBoard?

Yes and no. The first version was on a Raspi, but this didn't perform too well. A beagle board should be fine though. (Also: debian support for Raspi is kind of lacking, though)

Awesome! Thanks for the reply!

I disagree.

Isolating this on a separate piece of hardware might be a good idea. But getting your code on the hardware seems like an obvious and fairly fatal flaw. The possibility of the NSA forcing the single maker to insert some hidden code or even some hidden extra hardware makes this a "single point of failure". They sell servers the size of "wall-warts" - you could run Linux or BSD on that and run your secure email on top of that.

Keeping a general purpose computer secure is always going to be a problem but recent experience seems to pretty say "if you can't trust yourself, you can't trust anyone".

If their stuff is open-source how will they hide backdoors even if forced to insert them? I don't get it.

Only the software is open source, the hardware could still be backdoored. Not to mention unless you plan on compiling the software yourself and installing it on the box, there is no way to be sure that is what you're really getting. I am not too paranoid about that kind of thing being true but I'm also not that excited about this device.

The traditional fears are:

1. Subtle bugs that look OK during code review but actually introduce security problems (like == vs = but with a multi-billion-dollar spy agency behind it).

2. Binaries that don't match the source code (compile with the backdoor present, release code with it removed).

2b. An auto-update mechanism that lets the vendor deploy an update only you receive, which compromises your keys, then releasing another update minutes later which removes the compromise and covers their tracks.

3. The device shipping with an update mechanism that adds a backdoor during update installation, so there's no backdoor when you inspect the update on your computer but there is when running on the device.

[1] http://underhanded.xcott.com/

Yes, having open-source software is a requirement in this case, but it's hardly the whole story.

I see your point. But if this is a viable idea, the competitors with similar solution will appear eventually, which would sort of remove the single point of failure. On the other hand if this fails, nobody will try to get there a nasty backdoor.

Moreover compared to the current state when almost nobody uses gpg because it doesn't work with their favourite cloud provider, this approach would provide a nice alternative.

Interesting project, but I'm not convinced it solves the right problem.

If you trust "magic configuration" to secure your email, you can already have (a lot of) that with just smtp+tls.

As far as I can tell there's no way to know if the email you send will be encrypted or not. So there's no way to know if it can be considered secure or not? Secondly, it appears as if though if the receiver has a public key listed, the email will be encrypted, regardless of whether of the recipient uses gpg normally.

Finally all off-line storage an backup is still plain-text, so if someone, say, gets access to your laptop that you use for reading mail, it's all stored in plaintext on that machine, because it's been retrieved in plaintext from the kinko box.

Fundamentally though, this doesn't help with managing trust, and making trust visible. I agree that is hard, and inconvenient -- but without it I'm not really sure I see the point? Worse than that, I can't see how this won't give a false sense of security.

Maybe I'm the only one, but the wiggling "Early Birds" on this page and the "Top Ten Facts" along with the marquee scroll on the homepage made it difficult for me to concentrate on reading.

Thanks for the feedback. Things like these should help us to improve our website :)

The faq has nothing to say about spam filtering. How does that work?

The box syncs emails from your mail vendors IMAP server, say, at imap.gmail.com, and decrypts it in the process. In that process we are able to check for spam.

finally something that will protect me from the NSA ;) but yeah, accessing email from everywhere and with a sufficient degree of security is something that people stopped believing in

Then it is high times to do something about that, isn't it?

Fool-proof plug-and-play GPG mails for everyone, nice!

The 6th new account (made in the last hour) to make a positive comment on this particular post, nice.

Would love to get some access codes :)

Can you send us an email at contact at kinko.me? You will get one, promise :)

I've actually sent you two emails, one directly through email and one through the website.

When will it be available?

Hmm, we have a working prototype, but the software is not release-ready yet, and we also need to secure funding to have the hardware produced.

For this we are going to crowd fund in a couple of weeks.

Answering your own questions from different accounts. Classy.

Geile Scheisse!!!

in English please! ;)

nice box!

Thanks

interesting. The FAQ has 'lose' misspelled five times. Loose: opposite of tight. Lose: Opposite of find. Good luck with your product!

Lose: Opposite of win.

us germans :) We'll run the FAQ to our friendly spell checking native speaker..

Reply on news.ycombinator.com