# Process of Developing Encryption Software for “client” [closed]

I am looking to research the process behind developing encryption software. I am specifically interested in looking at the software process from a Systems Analysis (SA) point of view. After some extensive and exhaustive searches I have been unable to locate sources that discuss encryption software design tactics, methodologies, user elicitation, etc. I have tried every possible combination of Google search terms that I can think of and still; not quite what I am looking for. Perhaps this is the wrong approach in seeking such information, however I feel this may provide some much needed insight.

Specific questions include:

• Which methodology works well with encryption software design? Waterfall or Agile?

• What are the different stages of the development process?

• Are there any industry standards pertaining to encryption algorithm design?

Any help or guidance in the right direction is appreciated.

• What do you mean with "encryption software"? Writing an encryption library? Or using an encryption library within a certain context? Encryption should basically never be implemented by the people who want to use encryption. There are experts for that - and the industry standard (best practice) would be to use those libraries. Designing new encryption algorithms? That's an entirely different topic. – tylo Dec 6 '16 at 13:42
• There is no such thing as crypto software. For instance a password manager could be considered encryption software. But a library such as a TLS implementation is also considered crypto software. Not only is there a completely different interface (API vs GUI), but they act on different layers as well. And then there are things like crypto libraries in Linux that's entirely different, software components to perform authentication, complete one-time authentication solutions, voting software etc. etc. etc. etc. etc.. All require their own specific handling. Using cryptography is not a use case. – Maarten Bodewes Dec 6 '16 at 15:26
• I design and implement crypto in software for fun, there are 2 sides of it, the primitive algorithms and the rest of it. You can screw up either one and break the whole system, but the dev processes for each will be very different, especially when it comes to performance optimization. History has proven that industry standards are insufficient or in some cases completely bogus. The dev method will need to be a hybrid, I end up writing as much comments and documentation as I do code. To do a good job you need to think both like a criminal intent on breaking in, and an idiot end user. – Richie Frame Dec 7 '16 at 1:33
• Are there any industry standards pertaining to encryption algorithm design? - Yes… (1) Do not simply try to "design" your own cryptographic algorithm. Cryptography is not about creativity; it's about (proven) security. Therefore, it is standard to rely on existing, well-vetted algorithms and schemes. (2) Unless you're an experienced cryptographer and/or cryptanalyst, see rule 1. (3) If you decide to "create your own" nevertheless, it is standard to respect Kerkhoffs' Principle to avoid stumbling into worst-case scenarios at later stages. – e-sushi Dec 7 '16 at 4:05

## 1 Answer

The question itself is not precisely well formulated: cryptographic algorithm design is, like most scientific process, is a process of searching for theoretical solution (algorithm) to theoretical problem (set of desired security guarantees), which then has to be proven to be proper solution for the problem (security proof), and only then get implemented in code. Methods of doing such research have been attempted to be formalized many times, but I'm not aware of any good results. Like most hard science, it's thinking, writing formulas, trying and retrying, incrementally improving not some external objects, but author's understanding of the subject, which finally, after Nth attempt translates into cryptographically sound algorithm. Or what seems to author to be one, only yet to be proven faulty by others (see Schneier's law).

However, if you step away from details far enough, it will have some similarity with traditional Waterfall process, because:

• Inception. There are strong formal demands towards algorithm implementations and algorithms themselves; coming up with a solution / algorithm / superposition of algorithms (cryptosystem) can be considered 'writing a technical specification'. However, while in software specification and reality can mismatch a bit, and specification is considered to be a 'general guiding document', in cryptography specification is actually 90% of work in terms of importance. Writing proper crypto code is much less hard when you've got right algorithm with right demands and proper proofs, and is simply pointless when you don't.
• Implementation. When the algorithm is properly described, it gets implemented in a typical waterfall fashion: there isn't space for breaking down things into iterative improvements (which is prerequisite for sucessful Agile process).
• Integration. However, writing integration layer around the core crypto code can be iterative process, and while formal acceptance criteria are much more harsch than in software development (you can't "almost" make it, you either pass the tests / proofs or you don't), the process itself is easily dissectable into sprints, etc.

Consider this a private opinion of person, who participated a lot in applied cryptographic research, design and development, yet never suggested a fundamental algorithm himself (because see Schneier's law).