5 ms·
This may seem a bit off topic, but I do agree that we can't go back. So, I'm asking here. We are building out a software development framework "from scratch" a
by ericHosick 13y ago
This may seem a bit off topic, but I do agree that we can't go back. So, I'm asking here.
We are building out a software development framework "from scratch" and would like to make security a core aspect of the framework.
Where would be a good place to start looking at encryption solutions? For example, would PGP be a good option?
- SoftwareMaven 13y agoAssuming you trust it (e.g. Google), Keyczar[1] is a good starting point. If you don't trust it and you can deal with the GPL, GPG[2] is probably a reasonable way to go, but key management is still a bitch. Of course, these are very high level answers, and neither may actually work for you project, since you don't really talk about what making "security a core aspect" actually means. Cryptography is insanely hard to get right. The more you can leave up to the peer-reviewed experts, the better. 1. http://www.keyczar.org/ http://www.keyczar.org/ 2. http://www.gnupg.org/ http://www.gnupg.org/
- ericHosick 13y agoThanks. We'll check these out. We're creating a development environment based on a visual object language using a fully composable framework. The output of the development environment is blobs of "hooked up" objects. The user's programs are stored on host servers and, in real time, propagated to all people working on the project. Meta-data and data are also part of a program the user is creating. We would like to encrypt the blobs of objects so behavior can not be injected into the program (logic can be injected anywhere - think something like Aspect oriented programming to an extreme). We would like to encrypt any data (program - blobs of objects, meta-data and private user data) that is being persisted and/or propagated.
- stock_toaster 13y agoAlso check out http://nacl.cr.yp.to http://nacl.cr.yp.to there is a more library friendly version called sodium[1]. I don't know how much review has been done of that so far yet though.... [1]: http://labs.umbrella.com/2013/03/06/announcing-sodium-a-new-cryptographic-library/ http://labs.umbrella.com/2013/03/06/announcing-sodium-a-new-...
- ericHosick 13y agoSodium looks really interesting. Thank you.
- einhverfr 13y agoHere's my view. I recently wrote an article on my blog (http://ledgersmbdev.blogspot.com/2013/06/tangent-design-thougths-about-next-gen.html http://ledgersmbdev.blogspot.com/2013/06/tangent-design-thou...) which was on the front page of HN for a while. I want to summarize both my thoughts again and things that have occurred to me after writing it. All of our existing key interchange systems are amazingly brittle. With X509, there's no reason to assume the NSA couldn't order verisign to produce a certificate for any given individual or site which they could then use to orchestrate a MITM attack. Purely synchronic protections (i.e. focused exclusively at the moment of exchange) are obsolete in my view. Similarly purely diachronic protections have problems too, and often aren't well implemented. Suppose you need to rotate ssh host keys. This becomes a problem. I think we need something a lot better. Regarding PGP, the question is what they can break. Could they get a court order to force MIT to help them present that your key on their directory is visible to you but their key is visible to everyone else (allowing them to step in between and conduct another MITM attack of another variety? Even if you add endorsements (web of trust model), how easily can that be attacked? It might be harder but not that much harder. So my thinking is this. Start with a standard PKI model and extend it to require evidence of continuity. The assumptions required to do this are: 1. No external authority issues private keys, and 2. You must retain and continue to use an old private key for an unspecified transition period (possibly spanning several keys). This shows a chain of issuance, and evidence that the same entity controls the same internally issued private keys over time. So suppose you define a transition period of 2 years and a key rotation period of one year. This means that anyone you have been in communication with over the last three years will be able to check that the continuity of key possession has not changed, and three keys would have to be compromised to force a certificate believably (two of those keys can be stored somewhere else and only used for the certificate resigning process) If a MITM attack starts, anyone who has been in contact in that period knows instantly that something is wrong. Newcomers get alerted when the MITM attack stops. I would recommend looking into what we can do to implement a system like that. I am thinking of trying to write it up as an RFC and submit it to the various bodies.
- ericHosick 13y agoI did a search in google for the HN post but couldn't find it. Could you give me the link to that HN post?
- deleted 13y ago[deleted]
- coldpie 13y agoSince the story broke last week, I've been thinking about a PKI-based message program (think email, but not actually email) built on top of Freenet, to remove the need of any central server. I think I have a reasonable idea of how it would work, but I'm not convinced it would help anything. Tools already exist to securely send messages. Someone who truly cares about their security will learn how to use them. People who don't care about security won't bother. Hell, people already put all of their information on the Internet for effectively everybody to view. What would an easy-to-use, secure crypto app help with? I don't know.
- dpatru 13y ago> Someone who truly cares about their security will learn how to use them. Needs are relative. People have a lot of cares in this world and for most people, online anonymity and confidentiality don't rank very high. That's why convenient, cheap solutions are important. Solutions that require people too much won't be used. Think of digital cameras. Most people will use them if they're included free on a phone, but they're not willing to pay $3000 for "quality." Think