# 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.

## closed as too broad by otus, Biv, tylo, Maarten Bodewes♦, e-sushiDec 7 '16 at 3:59

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

• 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