3 ms·

Perhaps what is needed is a simple standard API that wraps OpenSSL, GNU/TLS, mbed TLS, Polar SSL, et al - that covers a small set of standard use cases.[1] It'

by opless 7y ago

Perhaps what is needed is a simple standard API that wraps OpenSSL, GNU/TLS, mbed TLS, Polar SSL, et al - that covers a small set of standard use cases.[1] It's not /hard/ using a library, but it's hard using it properly. And unless you're a cryptographer, you ABSOLUTELY SHOULD NOT roll your own encryption, and even then you're likely to screw things up. [1] I know PKCS#11 and friends try to do some of this, but no-one fully implements the entire standard(s), and no-one implements a standard set of features either ... which makes finding a provider and a client with overlapping feature sets somewhat interesting. I've done some (proprietary) work in this area, and I think that it ought to be the way to go.

cyborgx7 7y ago
> And unless you're a cryptographer, you ABSOLUTELY SHOULD NOT roll your own encryption, and even then you're likely to screw things up. I agree with this, but given this, how do you build a secure protocol that any programmer can implement themselves? Just saying "don't do it" will lead to posts like these that conclude that security might not be worth sacrificing the self-reliance. But this article also does offer some potential solutions, like tunneling the insecure protocol over a secure channel. I think that would be a better solution for this issue than the library you are proposing.
beefhash 7y ago
> Perhaps what is needed is a simple standard API that wraps OpenSSL, GNU/TLS, mbed TLS, Polar SSL, et al - that covers a small set of standard use cases. You mean like libtls[1], the OpenBSD project's attempt at hiding the guts of LibreSSL/OpenSSL? I'm not sure how well it lends itself to swapping out the backend, however. [1] https://man.openbsd.org/tls_init https://man.openbsd.org/tls_init
yellowapple 7y ago
> unless you're a cryptographer, you ABSOLUTELY SHOULD NOT roll your own encryption I feel like this should be qualified a bit: * If you are not a cryptographer, then you absolutely should not roll your own encryption scheme * If you are not a programmer, then you absolutely should not roll your own encryption implementation That is: cryptographer(s) should be working closely with programmer(s) to both design and implement an encryption scheme. Anything else is how we get things like Heartbleed.

by opless 7y ago

cyborgx7 7y ago

> And unless you're a cryptographer, you ABSOLUTELY SHOULD NOT roll your own encryption, and even then you're likely to screw things up. I agree with this, but given this, how do you build a secure protocol that any programmer can implement themselves? Just saying "don't do it" will lead to posts like these that conclude that security might not be worth sacrificing the self-reliance. But this article also does offer some potential solutions, like tunneling the insecure protocol over a secure channel. I think that would be a better solution for this issue than the library you are proposing.

beefhash 7y ago

> Perhaps what is needed is a simple standard API that wraps OpenSSL, GNU/TLS, mbed TLS, Polar SSL, et al - that covers a small set of standard use cases. You mean like libtls[1], the OpenBSD project's attempt at hiding the guts of LibreSSL/OpenSSL? I'm not sure how well it lends itself to swapping out the backend, however. [1] https://man.openbsd.org/tls_init https://man.openbsd.org/tls_init

yellowapple 7y ago

> unless you're a cryptographer, you ABSOLUTELY SHOULD NOT roll your own encryption I feel like this should be qualified a bit: * If you are not a cryptographer, then you absolutely should not roll your own encryption scheme * If you are not a programmer, then you absolutely should not roll your own encryption implementation That is: cryptographer(s) should be working closely with programmer(s) to both design and implement an encryption scheme. Anything else is how we get things like Heartbleed.