Open letter to security freeware developers

Any other tech-related topics
Post Reply
Message
Author
User avatar
webfork
Posts: 10821
Joined: Wed Apr 11, 2007 8:06 pm
Location: US, Texas
Contact:

Open letter to security freeware developers

#1 Post by webfork »

Background: Over time, I've looked through a LOT of programs in my research and, although I see a ton of encryption programs, I very rarely dig into them. Here's what the exceptions have:

Critical: internals
  • Standards - use existing, tested protocols, standards, and code. There are lots of options here but not using them means it's more difficult to say how well tested a program is.
  • Open - if you're going to do it, open the source and pick an open license. Few non-open security solutions seem to get picked up in a broad way. Not going the open route means there's no way to audit the code for backdoors as happened with TrueCrypt.

    Edit: an example of the above two points in action: a variety of security concerns in BitMessage caused by using old standards and that were determined by analyzing the source. Although many of the issues in this tool were addressed, one wonders how many closed-source programs stopped at bad while this program continued.  Since good security is hard, my guess is that it's quite a few.
Important: interface
  • Export - you've got to be able to easily put things in AND take things out of whatever encoded format you've created. This is especially true of text encryption programs, which need to work easily with IM / Email programs.
  • Simple - where possible, just build something that's going to protect 98% of users and put all the extra goodies under the hood. As I've seen with PGP and GPG, anytime you build in security beyond one or two steps, nobody uses it.
  • Drag-and-drop - lets you interact with other programs easily. Again, ease of use is jeopardized if it doesn't work well with the underlying OS.

Nice to Have / Extras
  • Search - if someone really adopts your program, they're going to store a lot of information inside it. Being able to quickly search for what you need is a big help.
  • Backup/recovery tools - security isn't just about encryption, it's also about availability. Knowing that the data is easy to recover in the event of disk failure or otherwise increases feelings of safety.
  • Solid security - encouraging long passwords or use of keyfiles is always good. Cool, cloak and dagger-like extras like deniable encryption, 2-stage passwords, and obfuscation/steganography should all be second to standard safety measures.
  • Documentation - few programs spend time to clearly explain themselves, assuming that most users just understand software. Even a basic help file or intro video is huge.
  • Cross-platform - working for more than just Windows is always a good trick, making it something you can share with others.
  • Challenge - ask people to try and break your encryption somehow. You don't have to offer much because a token reward can work as bragging rights for many talented cryptologists.
  • Command-line tools for batch operations (if applicable).

Post Reply