Suggestions for developers in the post-NSA era

I have a couple of suggestions that maybe make sense:

1) We should not use C/C++ in our softwares since, for its own nature, it is very error-prone and also it makes things more complex than what they need to be. More complexity means more chances to make mistakes. C/C++ were two good languages but as the time goes by they are getting a little bit too old for today's need. For instance GO (from Google) seems a good alternative to C/C++, the code is cleaner, shorter, it has its own garbage collector and no pointer's arithmetic (no worries about memory leaks), it also has strong, language-level, easy-to-use, support for multi-treading done right (with less chances to end up in deadlocks and so on) which makes it a more modern programming language that can take advantage of current CPUs and the speed of compiled softwares is almost as fast as C/C++. I really believe that if we used a better/cleaner/easier language than C/C++ several exploitable/exploited bugs in our softwares (the one used by the FBI against Freedom Hosting comes to my mind) could be avoided altogether. Clarity and simplicity in our source-code should be a priority so lets avoid old languages that make things harder to understand and that made sense 20/30 years ago when the computers where isolated boxes with single CPUs and zero multi-threading. This would in fact help us spot much easily mistakes and/or back-doors in our code.

2) Our code should be VERY WELL commented. I frequently find myself trying to study/learn from open-source softwares that are almost impossible to understand because of the lack of comments. Whole classes/source-files are frequently left without a line of comment (or with useless comments) and frequently it is even hard to understand the purpose of that class/file. The projects should also have a separate text-file with an outline of which are the main parts that make the project, which standards it uses, and, possibly, what are the main classes/files to look at with a general description that tells us what's their purpose and what they do inside our software. I understand that this seems like a lot of work, but it would really help to understand much better the source code of our projects and so have many more persons involved in the development and, in turn, this would make it much easier to spot problems who could lead to weaknesses or other serious problems. It is clear now that we cannot put aside security anymore, it has not to be a second class citizen in our softwares. Logging should be disabled by default, encryption enabled by default and so on.

3) Books about this or that programming language should have a section about security. There are several books about (for instance) PHP but not many of them tell you how you should encrypt and store the passwords of your users inside the database. This has lead to several websites who don't even bother to encrypt the passwords of their users and, in turn, this can damage our users in several ways (especially because many users use the same username/passwords in many different services and this means that by breaking our insecure WEB-apps we are literally giving to the attackers the means to break into these user's emails/bank accounts/social networks/computers/...). Books have ignored for a long time security... this should change, especially when dealing with programming languages and techniques for the WEB.

4) Since we don't know if AES or other algorithms/ciphers are broken we should nest/concatenate them. So, for instance, to encrypt a plaintext T we should concatenate several algorithms together. Like this: E = AES(Twofish(Salsa20(T))) where of course E is the encrypted message and T is the plaintext message. In this way if AES (or Twofish, or whatever) is broken we still have other "backups". This could apply to public key cryptography too. If possible the user should be able to pick any number of ciphers (from the available set) and concatenate them as s/he likes. This is for instance already done (on request) on Truecrypt. We should not trust a single cipher or a single algorithm from now on. Yes, this would make our softwares/communication a bit slower, but i am quite sure that in most cases speed doesn't really matter. I am running (from several years now) Truecrypt in full-disk encryption with several concatenated ciphers on my machine right now and i don't notice any particular slow-down (and my PC is an old Pentium 4 without any encryption hardware built into the processor).

These are my two cents.

- Wakko Warner