Hacker News new | comments | show | ask | jobs | submit login
Show HN: EZing – Mobile email client that looks like Messenger and uses PGP (ezing.de)
45 points by Databay on Feb 8, 2016 | hide | past | web | favorite | 34 comments



I heard* that all smartphones/cellphones are inherently insecure because:

1. By design, the cellular radio controller (called the baseband) accepts important/privileged commands from the cell tower. (For example, "update firmware". Sometimes, there's even "read range of bytes from phone's internal storage".)

2. Portable fake cell towers exist (called Stringrays).

Therefore, unfortunately, it seems unreasonable to claim that private keys generated by this eZing app never leave the phone.

* Probably previously here on HN. Couldn't find the link today.

UPDATE: This pgp-centric secure email is not open source? giggle Where do these people come from?


That doesn't mean developing secure asynchronous messaging apps for smart device platforms is a bad idea (although adopting PGP over libaxolotl seems a tad foolish these days), it only means people should understand their threat model. If your threat model includes an adversary capable of taking over a cell tower or using IMSI catcher, then use a device with no baseband, like a simple tablet.


This is an important conversation people should have when discussing security. The dream is perfect security and trust - something that no singular person could ever have completely, because it basically requires a ton of things to happen:

* You need to audit the blueprints for all hardware.

* You need to verify, physically, the products of manufacturing - the physical hardware you will use - often requiring you to know the design and likewise guarantee the implementation of the fab process.

* You need to audit and verify all firmware and software running on the system - from your flash controller to your chipset to your CPU to your GPU. This is on top of already having trust in the hardware.

* You need to then use software that is secure. Perfect security - mathematically proven security - is probably the most expensive thing you could try in software.

It is already impossible for any one individual to have audited all the hardware parts and the underlying OS and firmware, but then they need to also personally verify or write themselves the software implementations of security they will use.

We all, by using computers, are yielding an immense amount of security in the form of trust. One of the cornerstones of the free software and open hardware movements are how untrustworthy a singular set of eyes upon hardware or software truly are - that having the ability to independently have someone else inspect the code, or most importantly your own ability to do so, is what gives us reasonable expectations of security.

So nothing you ever use you can truly claim to be perfectly secure - you are always trusting that someone else is telling the truth when they say it is secure. In the best case scenario, a lot of unaffiliated people claim it is secure (ie, free software / free hardware). But we are well beyond the point anyone using an Internet based messaging app can presume perfect security, ever. The question is always who you are willing to trust when they claim to offer security - and to recognize when vendors are not promising (legitimate) security at all, as is the case with cell phones.


Zanny, I disagree with your use of the "nothing is completely secure" truism as an argument against "storing private keys inside cellphones is not a good idea".

The local police department has ISMI catchers.

I estimate they won't have the ability to extract a file via the baseband until something like eZing becomes ubiquitous.

At that point, automated private key extraction will just become another feature of the ISMI catchers.

All of this is tangential to the real problem: basebands. Both in cell phones and cable modems. Time to take 'em back. You wouldn't allow OTA updates of your router or PC... Now would you?

I'll anticipate one response: "But, giving consumers control of their PHYs would be hell for the cellular/cable operators!" Well, after a few years, their/our networks (and devices) will be more secure.


> You wouldn't allow OTA updates of your router or PC... Now would you?

Have you booted an internet-connected Windows 7/8 machine recently? "Here, have Windows 10, with all the privacy features built in to it switched off! (In fact we're already downloading ot for ypu even before you agree to install it, so it'll be ready as soon as you agree, isn't that _convenient?_)"


No, I have not. :) Well, the Windows 7 machine under my desk at work is managed by the IT dept.


> > You wouldn't allow OTA updates of your router or PC... Now would you?

> Have you booted an internet-connected Windows 7/8 machine recently?

No, because I use GNU/Linux.


If you're worried about an adversary with access to your phone's baseband, one alternative is to get a 4G hotspot and connect over wifi from an iPod Touch, iPad, or similar.

You're still relying on the wifi stack not having any holes that a compromised hotspot baseband could get through, and for that matter, relying on the whole OS not having any other holes they could attack. Either way, it's a smaller attack surface.


It's true, that's a smaller attack surface.

Under what circumstances would a "phone" manufacturer produce a headset that didn't have the baseband problem?

Which might just mean: a phone that consumers would regularly RTM if it did contain the problem?


"Necessary keys are generated within the app so the private key never leaves the device"

Funny. With my email+PGP setup, my private key never even enters the device - https://grepular.com/An_NFC_PGP_SmartCard_For_Android


I assume, that no app will ever reach a lot of people if it's not convenient. That collides often with security aspects. Your Yubi-key-solution might be a good extension for eZing to still use PGP without storing the keys inside the phone, but being convenient enough to chat like you do with Whatsapp, what's a lot more convenient than using a mailclient.


"It will not be open-source"

Pass.


"... but available in full for a review."

I don't know what this means? A snapshot (i.e. not an updated repository) available to anyone who asks for it?

I don't understand how it could meaningfully be "available in full" without it being equivalent and easier to just open source it.


I expect this means that if you're a security firm with a decent track record, they'll provide you with source code for review purposes.


It won't be free software, but you could probably get them to give you the code with a license that isn't free.


exactly. I don't have a problem with opening the code to ensure the encryption is safe, but that doesn't mean to give everyone access for free.


I'm not sure you understand the meaning of the term "free software". The "free" refers to freedom, not price[1]. Terms like "opening the code" don't actually describe what the status of your software in terms of its freedom are (am I allowed to redistribute it or modify it or even run it for any purpose?).

And besides, I wasn't agreeing that it's a justifiable position, I was trying to highlight the confusion that arises when you use a term like "open source" (which doesn't have any moral backing, so "opening" the code may or may not make the software "open source").

[1]: http://www.gnu.org/philosophy/free-sw.en.html


They could provide the source without it being Open Source, ie., freely redistributable. That was the case for PGP for many years.


Well. Uhm. We don't know us well. I guess this needs some clarification.

We're a "15 year old startup" and we're very active with serveral open source projects. Our decision to not open source the project at the early stages is a decision that serves certain goals for us and the project.

First of all, we see some interest in the technical foundation of eZing. We admit it, we don't want to see a lot of forks and other people making profits based on our work while our initial investments are not covered. Yes, we're selfish like that.

The second goal is that we want eZing to stay. Forever if possible. When we look at successful open source projects, we noticed that quite some of them have had a proprietary or at least a protected "childhood". If open sourced at the right moment, a development community can take the momentum and relevance of the software and lead it to heights a single company is not able to. There are two things that can go wrong: Open source it too early, before the technology is relevant or open source it too late, when the horse is already dead. The approach we choose is of course not a guarantee, but we believe in this approach.

Regarding the review and transparency: We are not willing to limit disclosure of the source code only to security companies or entities like that. We know that trust is not easily earned. If you allow us to dream, then we would - under NDA, see our first goal - disclose the code on a permanent basis to a group of developers that have earned the trust of the community until we finally release it as open source.

We're thankful for your thoughts on this and we would be glad to further discuss solutions so we get eZing off the ground.


Yeah, I don't agree with anything you just said. VLC was free software from day one. FFmpeg was free software from day one. Linux was almost free software from day one (the license was stupid). GNOME was free software from day one. All of GNU was free software from day one. I've covered just a couple of things you probably use all the time.

This doesn't mean you can't work on a prototype before releasing it. Most projects do that. But asking free software developers to sign an NDA isn't going to work. They'll just go off and make a competing free software product.


Quick research on that:

- OpenOffice / LibreOffice (StarOffice) - Firefox (with roots at Netscape) - MySQL - Blender - Joomla (Miro)

So, there are samples for both approaches.

Open source superiority discussions from your local "uber enthusiast echo chamber" should stay exactly there. Here's real world calling.

When it comes to your predictions about no developers signing NDAs... With the perspective for an early influence on a product that WILL go open source, I think it is a bold statement to deny the possibility of a group of people taking such a chance. I am not claiming this is an especially interesting opportunity for hobbyists.


Exactly this. It reads nice and everything, but it misses the whole target audience at this part.


Most people here know about Signal, but if you don't:

https://play.google.com/store/apps/details?id=org.thoughtcri...

Open source, easier to use, much better UI.


And it uses Axolotl (which is an improved version of OTR) which has much better security properties for informal messages (the recipient of a message can be convinced the sender sent it but could not prove this to anyone else). PGP should only be used in cases where you are willing to have your signature be made public.


Signal also has forward security, last I checked.


Definitely a concept I have been considering and am interested in! But it's not open source! Site claims source will be available for review after beta but that is obviously futile, the devs could make an implementation mistake the very day after review is completed and bork the whole security model.

Try again.


Definitely agree, something like this really needs to be open source. This sort of project is way too difficult for just one person or a small group to do on their own.

I love the idea, but I'd never trust this, and I'd never recommend someone use it.


If anyone wants to help do this on desktop, some folks have been building PGP support into a Nylas N1 plugin! https://github.com/nylas/N1/issues/96

(I work at Nylas.)


Which doesn’t help anyone, considering how you continue to refuse to accept pull requests implementing auth solutions, and refuse to provide one in the open source version.

Any hosted service is inacceptable by default for security-conscious users (metadata...), and your product is barely acceptable for selfhosting. Which requires to fork.


I wish the site had a contact address for feedback or an announcement list. It looks like a good idea; I'm looking for more information. Digging for the Kickstarter to look for more information there...


my contact-address is info@ezing.de Thanks for all your feedback. You are absolutely right. The app should be open-source to give everyone the possibility to check every part of the security-relevant codes.


    > The app should be open-source
and yet your website says:

    > It will not be open-source
what's going on? :)


No way to request invite codes?


> eZing is a messaging app that closes follows concepts of well-known messengers to achieve the same comfortable reading and writing of messages.

closely




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: