3 ms·

I know that it is considered suicidally hubristic to use homegrown cryptography; does that apply to writing your own implementation of a trusted protocol? It s

I know that it is considered suicidally hubristic to use homegrown cryptography; does that apply to writing your own implementation of a trusted protocol? It seems like it'd be a cool project, but I don't want my github profile to advertise that I'm the kind of fool that rolls his own crypto.

Joona 11y ago
Yes, use existing libraries.
- an_account_name 11y ago
  If you feel the need to experiment, that's great - it's a fun exercise. Just don't use it in production, and call your repo something like "brokencrypto" so nobody else tries to use it.
  - sneak 11y ago
    Or "Cryptocat".
Xorlev 11y ago
> does that apply to writing your own implementation of a trusted protocol? As long as your README says that you're playing around with crypto and it's not production crypto, go wild -- nobody will care. Anyone who does isn't worth listening to, playing around never hurt anyone as long as at the end of the day you use real implementations by seasoned crypto developers.
FeepingCreature 11y ago
I recommend libsodium (http://doc.libsodium.org/ http://doc.libsodium.org/).
baruch 11y ago
At the simple side of things you can write your own implementation and use known test vectors to verify that your implementation is acting the same as other implementations. That should cover interoperability. Some of the issues in cryptography implementation are subtle things that can affect it like timing concerns, if you have a time optimization it can be exploited to leak information on the data or the key. This is one thing that a less experienced developer may fall into. There are other side channel attacks as well that one needs to be cautious about. Optimizations for power usage may also leak information. Part of writing crypto is to optimize for security on the expense of time and power.
ReidZB 11y ago
In cryptography, every layer of the stack has a set of possible vulnerabilities associated with it. In the rarest case, primitives (like ciphers and hash functions) are broken; more commonly, the protocol is ill-designed and flawed; but most common of all, the actual implementation itself has security flaws, like side channel attacks. The issues associated with every layer are considered extremely subtle and tricky to both identify and fix. But I would say this is especially true for implementation attacks, which are not really addressed by cryptographic theory. So, no, writing your own protocol implementation is not secure, even if you trust the design of the protocol. You are still vulnerable to the trickiest class of security flaws. However, so long as you clearly label your project as "learning only" or "insecure," no one will think worse of you for having your own protocol implementation. In fact, I'd say re-implementing TLS is one of the few ways to become intimately familiar with its internals.
saalweachter 11y ago
Writing your own crypto implementation is just like every other instance of reinventing the wheel, but more so. Namely, don't be a dilettante. It's actually perfectly OK to reinvent wheels. Reinventing wheels is how people learn to build wheels and eventually invent new, never before seen wheels. Where we as programmers get in trouble is that we frequently reinvent a wheel once, and then drive around on it for the rest of our lives. If you find cryptography interesting, try your hand at it. But don't just code up the first implementation once, slap it on a web app, and use it to protect your customers PII. Don't be a dilettante. Write lots of crypto implementations, and try to find the flaws in them. Read lots of books, read lots of other people's implementations. Whenever a new exploit of one comes out, try to understand it and try to find similar problems in your own code or other implementations (or figure out why a particular implementation doesn't have that flaw). Write more implementations, read more books, talk to other cryptographers. It's not a crime to be interested in difficult things, but it is important to recognize that difficult things take a certain level of skill and devotion. Each of us has to decide which difficult things we want to devote our time to and which we want to casually watch from the sidelines.
- deleted 11y ago
  [deleted]
- lfowles 11y ago
  To further the analogy: Most of us don't have the resources or knowledge to properly test our wheels after we reinvent them.

Joona 11y ago

Yes, use existing libraries.

an_account_name 11y ago
If you feel the need to experiment, that's great - it's a fun exercise. Just don't use it in production, and call your repo something like "brokencrypto" so nobody else tries to use it.
- sneak 11y ago
  Or "Cryptocat".

Xorlev 11y ago

> does that apply to writing your own implementation of a trusted protocol? As long as your README says that you're playing around with crypto and it's not production crypto, go wild -- nobody will care. Anyone who does isn't worth listening to, playing around never hurt anyone as long as at the end of the day you use real implementations by seasoned crypto developers.

FeepingCreature 11y ago

I recommend libsodium (http://doc.libsodium.org/ http://doc.libsodium.org/).

baruch 11y ago

At the simple side of things you can write your own implementation and use known test vectors to verify that your implementation is acting the same as other implementations. That should cover interoperability. Some of the issues in cryptography implementation are subtle things that can affect it like timing concerns, if you have a time optimization it can be exploited to leak information on the data or the key. This is one thing that a less experienced developer may fall into. There are other side channel attacks as well that one needs to be cautious about. Optimizations for power usage may also leak information. Part of writing crypto is to optimize for security on the expense of time and power.

ReidZB 11y ago

In cryptography, every layer of the stack has a set of possible vulnerabilities associated with it. In the rarest case, primitives (like ciphers and hash functions) are broken; more commonly, the protocol is ill-designed and flawed; but most common of all, the actual implementation itself has security flaws, like side channel attacks. The issues associated with every layer are considered extremely subtle and tricky to both identify and fix. But I would say this is especially true for implementation attacks, which are not really addressed by cryptographic theory. So, no, writing your own protocol implementation is not secure, even if you trust the design of the protocol. You are still vulnerable to the trickiest class of security flaws. However, so long as you clearly label your project as "learning only" or "insecure," no one will think worse of you for having your own protocol implementation. In fact, I'd say re-implementing TLS is one of the few ways to become intimately familiar with its internals.

saalweachter 11y ago

Writing your own crypto implementation is just like every other instance of reinventing the wheel, but more so. Namely, don't be a dilettante. It's actually perfectly OK to reinvent wheels. Reinventing wheels is how people learn to build wheels and eventually invent new, never before seen wheels. Where we as programmers get in trouble is that we frequently reinvent a wheel once, and then drive around on it for the rest of our lives. If you find cryptography interesting, try your hand at it. But don't just code up the first implementation once, slap it on a web app, and use it to protect your customers PII. Don't be a dilettante. Write lots of crypto implementations, and try to find the flaws in them. Read lots of books, read lots of other people's implementations. Whenever a new exploit of one comes out, try to understand it and try to find similar problems in your own code or other implementations (or figure out why a particular implementation doesn't have that flaw). Write more implementations, read more books, talk to other cryptographers. It's not a crime to be interested in difficult things, but it is important to recognize that difficult things take a certain level of skill and devotion. Each of us has to decide which difficult things we want to devote our time to and which we want to casually watch from the sidelines.

deleted 11y ago
[deleted]
lfowles 11y ago
To further the analogy: Most of us don't have the resources or knowledge to properly test our wheels after we reinvent them.