Hacker News Reader

Comment by AnIrishDuck | Hacker News Reader

I see encryption everywhere in the pitch, but nothing about authentication. Doing a little research, the datasheet indicates their crypto module [1] does support HMACs. That said, I'm a little leery of a pitch that (a) doesn't appear to understand the distinction between encryption and authentication and (b) doesn't state they plan on providing both.

Just my 2c.

[1] http://www.atmel.com/Images/Atmel-8740-CryptoAuth-ATSHA204-D...

View on HN

Hey there! I'm the designer of the product (and co-founder). Totally understand, we've been working as hard as we can to provide clear information, and I had a lot more written about encryption and cryptoauthentication before I realized it may be too focused (we want to get regular people excited about building projects). Cryptography is incredibly important to me, and my ultimate plan is for these boards to be useful in creating dark mesh nets so people can communicate freely even when others try to cut them off. The protocol will be lightweight and we support sending arbitrary data, so it shouldn't be hard to patch it into a network. I still remember the cryptocat articles from a couple months back, and the snooping from the NSA has turned me into a crypto evangelist, so I absolutely intend to provide real strong cryptography. I also understand how skeptical people are (and should be) about crypto systems, so as I'm still learning about this stuff I've been careful not to boast too much before I've got the exact system sorted.

Currently the plan is full support for multiple master keys for different purposes (one for firmware updates, one for data, perhaps one for trusted guests, out of 16 total possible keys), per-packet session keys using AES-256, and I'm very curious about ECC, which it appears our system might support, since the encrypt/decrypt are software (though the new radio has an AES-128 hardware engine too).

We'll give a LOT of detailed information on the development of this system as it happens (after the kickstarter). My plan is to design a system that any HN reader would be proud of. We're not going to "let open source do it", we're writing it ourselves and I've loaded my tablet full of crypto e-books so I can genuinely learn from the ground up how to do that. Even if ultimately I don't write the software, I absolutely will not sell a system as cryptographically secure unless I personally understand how it is built and why it is secure.

Your enthusiasm is encouraging, just keep in mind the standard warning that crypto is very easy to do wrong (and wrong in a way that's hard to detect until your platform is blown wide open, see e.g. the PS3 root key disaster). In particular, a ton of academics argue that encryption (e.g. vanilla AES) by itself isn't very useful, and authenticated encryption [1] should be the default offered to standard users. There are multiple ways to achieve this, your hardware may support AE modes like GCM or others.

Keep in mind that crypto's only half the battle, and even "perfectly valid" crypto can still leave your platform vulnerable to things like replay attacks [2]. e.g. lets say someone uses your board as a doorbell: a crafty attacker can sniff the doorbell packet and replay it constantly if you don't use something like a request counter.

Point is: you shouldn't make your users cobble those steps together, they'll get them wrong. You're in fact very likely to get them wrong yourself, if (as you say) you're still learning the ins and outs of crypto. I wish you the best of luck, but keep in mind that you have a long journey ahead of you. I'd particularly recommend you complete the Matasono crypto challenge [3] before you even think of trying your hands on raw crypto primitives.

1. http://en.wikipedia.org/wiki/Authenticated_encryption 2. http://en.wikipedia.org/wiki/Replay_attack 3. http://www.matasano.com/articles/crypto-challenges/

Did you consider using the ATAES instead of the ATSHA? It has onboard authenticated AES (AES-CCM).

Reply on news.ycombinator.com