I have empathy for people who end up stuck in the in-between areas, where out-of-the-box building blocks solve part of their problem, but how to glue them together can still get tricky.
For one example, you've got a shared secret. Can you use it as a secret key? Do you have to feed it through a KDF first? Can you use the same key for both encryption and signing? Do you have to derive separate keys?
I'm in that boat. I'm watching all of Christoph Paar's cryptography lecture series on YouTube -- it was recorded in 2010, so I do wonder if it's missing any new state of the art / best practises.
I'm like 18 lectures in, two out of three semesters. And I still feel like I have only the vaguest ideas what the primitives are, how they work, what they're for, and their weaknesses. I'm having to follow all the mathematics as someone not mathematically inclined (Prof Paar did do a good job of making the mathematics fairly accessible though).
All of this so I can have a bit more confidence in proposing E2E for a project at some point in future (before somebody asks us to, too late).
And my use-case makes it difficult to follow the most trodden paths so I can't just plug in a handshake protocol and MACs and elliptic curves or "just use PGP" or whatever.
As a software dev, I have all these boxes I could use, that come with so many caveats "if you do this, but don't do this, no do that, don't do that"... It's very tricky trying to work out how to glue the pieces together without already being in the field of crypto. Feels like I'll always be missing some crucial piece of information I'd get if I pored over hundreds of textbooks and papers but I don't have the resources to do so!
I'd love if someone did like, a plain English recipe book for cryptography! Give the mathematical proof of stuff, but also explain the strengths/weaknesses/possible attacks to laypeople without the prerequisite that you need to understand ring modulus or Galois fields or whatever first. Or, like, flowcharts to follow!
>As a software dev, I have all these boxes I could use, that come with so many caveats "if you do this, but don't do this, no do that, don't do that"... It's very tricky trying to work out how to glue the pieces together without already being in the field of crypto
Until you know more, strongly consider suggesting the company just hires someone who knows that. Just because you're available to do it, doesn't mean you should just yet.
> Until you know more, strongly consider suggesting the company just hires someone who knows that. Just because you're available to do it, doesn't mean you should just yet.
This is a fair point. We'd always find it difficult to hire someone who was 100% specialising in software security / crypto etc, but a software eng who has some experience would probably be palatable... But funding for new hires could be a couple of years out. That, or we find a way to turn it into a research proposal we can sic a PhD on.
Still, I think it benefits us to have a strong baseline knowledge of crypto systems as a team, "bus factor" and all that. Maybe one day we have a colleague that can teach us that, but until then we may as well crack on with self-teaching :-)
For one example, you've got a shared secret. Can you use it as a secret key? Do you have to feed it through a KDF first? Can you use the same key for both encryption and signing? Do you have to derive separate keys?