Live data from Hacker News

Open-sourcing Tutanota: Why it was important to us

tutanota.de

61–64 of 64 posts

Re: Open-sourcing Tutanota: Why it was important to us

#61
post #60

Earlier quoted context omitted.

The cable is just what he had at his house: a smaller one is better. Not sure why you keep bringing up smartcards as alternative to long cable: two totally different things. Only realistic alternative to his cable w/out extra risk is point-to-point IR transfer: cheap & hard to grab if nearby (unlike Bluetooth/Wifi). It would be nice to get more people on GPG or Linux. It's what I use, too. The problem is their Truste…

> The cable is just what he had at his house: a smaller one is better. Not sure why you keep bringing up smartcards as alternative to long cable: two totally different things. True, a smart card doesn't give you separate input/output terminals. But it can isolate the key and encryption bit. It can be quite secure in case of theft, off-line access. [ed: I wasn't talking about just the cable, I was thinking about all t…

The smartcard can isolate the key. The problem is that they don't need it if they compromise the PC. It's pointless if the goal is to protect the current communication. Far as implants, they're possible with anything. Rule is that enemy can never physically possess your stuff or it's considered compromised.

"but also usability issues (even if you could probably sandwich most of it into a single laptop case. Would be interesting to have two screens side-by-side for input and output)."

You should've seen my old VOIP design: a briefcase of cables, boards, and shit lol. Yeah, it will take up more space and have a learning curve. Any strong solution usually does, though. Be skeptical of anything claiming high usability and high security. ;)

"Sort of as a replacement for the hw in the terminals used here. I didn't mean a full Android software stack. Preferably a system without baseband, networking etc."

If you keep the three nodes, then you can certainly use Android devices. If you condense them, then you loose the protection due to all the attack surface. One drawback with Android is most of them have embedded wireless hardware. Tiny risk maybe but hard to tell if you've disabled it for sure. Android on device w/out wireless chip is fine.

"I'm not sure about your use of "NIX" here. Is this a combined hardware/software platform? Google wasn't very helpful."

UNIX or UNIX-like systems. Many of us called them NIX's for short in the old days. Their complexity and security track record make them untrustworthy for defending against strong attackers. They're a last resort you use while still monitoring for compromise. Unfortunately for that crowd, the systems with high security are all proprietary (often defense-only) and similar open-source systems have less assurance and usability. They're all alpha stage, actually.

"So it would seem that using a dedicated (mostly) air-gapped laptop would practically be as secure."

It's lower risk than most things. It's why most of us use that strategy. Your risk is being hit in the kernel stacks, the drivers, or peripheral firmware. If data goes back and forth, then the risk goes up. To be clear, this is a targeted attack by professionals that know what they're doing. Average hacker doesn't do this.

re cascade

They haven't shown evidence of this for years past the meet in the middle. So, it seems fine long as I avoid that. Far as adding risk, it's unlikely given this is merely a basic algorithm application. If you said protocol engines, I'd totally agree. With algorithms though, you can usually get three right if you can get one right. Still want a specialist coding them, though.

re other stuff

The system in question must be evaluated by security pro's before we can trust it. Meanwhile, GPG + air gapped machine is your best bet outside TFC. As for hardware subversion, they might do anything so acquire your hardware in different, unpredictable places or have others order it for you. Far as screen, the monitor cable is the best place for leak. I proposed long ago a shielded cable that works except amplifies signal along unused frequency. Later on, TAO catalog leaked and there's a VGA cable modified to do exactly that. So, there you go.... ;)

Re: Open-sourcing Tutanota: Why it was important to us

#62
post #60

Earlier quoted context omitted.

> The cable is just what he had at his house: a smaller one is better. Not sure why you keep bringing up smartcards as alternative to long cable: two totally different things. True, a smart card doesn't give you separate input/output terminals. But it can isolate the key and encryption bit. It can be quite secure in case of theft, off-line access. [ed: I wasn't talking about just the cable, I was thinking about all t…

The smartcard can isolate the key. The problem is that they don't need it if they compromise the PC. It's pointless if the goal is to protect the current communication. Far as implants, they're possible with anything. Rule is that enemy can never physically possess your stuff or it's considered compromised. "but also usability issues (even if you could probably sandwich most of it into a single laptop case. Would be…

> UNIX or UNIX-like systems.

Thank you. I usually use, see *nix. Arguably Android sans Google apps, over-the-air updates fit into that box.

The idea of three nodes, trivially separated and air-gapped is interesting.

One should be able to do the input with an adruino or something (most obvious choice, a keyboard, but could also tack on a mic/camera for audio/video).

Link that with a "one-way" cable to a rpi2 (the "compromised"/networked node), and a cheap android tablet w/o baseband/gsm chips -- and perhaps solder off the antennas/kill the wlan/bluetooth. Preferably one w/o NFC. Use the tablet as the screen, and the "out" node.

Use lobotomized usb-cable for power from the Android-devices battery, and run everything off that.

I do like the idea of having the separation be obvious and simple -- easy to audit.

Suppose one might as well run freedos on the two nodes -- but Linux/BSD is probably less painful.

Re: Open-sourcing Tutanota: Why it was important to us

#63
post #62

Earlier quoted context omitted.

The smartcard can isolate the key. The problem is that they don't need it if they compromise the PC. It's pointless if the goal is to protect the current communication. Far as implants, they're possible with anything. Rule is that enemy can never physically possess your stuff or it's considered compromised. "but also usability issues (even if you could probably sandwich most of it into a single laptop case. Would be…

> UNIX or UNIX-like systems. Thank you. I usually use, see *nix. Arguably Android sans Google apps, over-the-air updates fit into that box. The idea of three nodes, trivially separated and air-gapped is interesting. One should be able to do the input with an adruino or something (most obvious choice, a keyboard, but could also tack on a mic/camera for audio/video). Link that with a "one-way" cable to a rpi2 (the "com…

Now you're thinking on the right lines! All of that should be fine. Didn't think about using USB for power: just had a strip in the design. Will have to think on it. Standardizing on Linux/BSD is wise, too, as it lets us easily adapt it to new software applications.

And, in case I forgot, you can modify this architecture for voice or video but will need to replace serial cable with higher bandwidth line. Risk starts to go up there. You either need a real data diode or must physically modify Ethernet/Fiber cables and/or cards to do one-way transmission. Might take custom, microcontroller board to be sure it's done right.

It's a bigger project to say the least. There's examples online but the security is debatable. That's why the defense sector builds and certifies the big guns [1]. That it takes them that much hardware & they mention TEMPEST hints at how much work goes into this one, tiny problem.

[1] http://www.nexor.com/sites/default/files/Nexor%20Datasheet%2...

Re: Open-sourcing Tutanota: Why it was important to us

#64
post #15

Earlier quoted context omitted.

While fastmail's interface may indeed be a bit clunky they are certainly not US owned or based as you've stated.

> clunky Just curious. Are you referring to the classic interface, or our super slick Ajax interface?

The more modern one - it just looks quite dated. Don't get me wrong - I'm glad I'm using Fastmail but there are certainly areas that need improving such as the calendaring / contacts management / load times. I know that the backend is really solid - the UI just needs a bit of a spruce up in my opinion.
Post reply on HN