| View previous topic :: View next topic |
| Author |
Message |
VinzC
Watchman
Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood
|
 Posted: Mon Jul 28, 2014 2:23 pm Post subject: Is there a unified user space cryptography? |
 |
|
Hi all.
It's just out of curiosity that I am asking. I was browsing the source tree of directvnc and I came across a 3des encryption source file, which implements... well, 3DES encryption, who'd have guessed! I have browsed now a certain amount of source files and I wonder why most project re-implement the same routines ever and ever again while those cryptographic routines exist in the kernel. Is there a reason for that?
Is it possible to use the kernel crypto routines instead of re-implementing the code? IMHO the advantage of using the kernel implementation is at least twofold: a) unification and b) adapted to the CPU the program runs on.
Any thoughts on that?
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
| Back to top |
|
 |
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10589
Location: Somewhere over Atlanta, Georgia
|
| Posted: Mon Jul 28, 2014 4:20 pm Post subject: |
|
|
Two thoughts, actually. First, the kernel is a lousy place for shared library code to exist. All other thing being equal (i.e., the kernel isn't supporting a hardware acceleration driver), then kernel-based crypto will be slower than the equivalent userspace routines because of the context switch overhead. Secondly, in a standard Gentoo environment, userspace code is typically more (and certainly no less) optimized for the target CPU.
On your central point, though, I agree with you: neither of the above is a good reason to reinvent the wheel. Using something standard and ubiquitous (e.g., libcrypto) would be strongly preferred.
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Jul 28, 2014 8:14 pm Post subject: |
|
|
1. Many projects should run on many systems, not just on linux.
2. Security is always a special issure. For instamce, if you call a kernel encryption function, how easy is it for other processes to guess from some delay some bits of information? How about electromagnetic radiation which somebody closeby might be able to measure? Etc. (I am not enough a specialist to answer these questions positively or negatively, but all these should be taken into account by good programs.)
3. Sometimes it is just overkill. For instance, eix needs to calculate an md5 checksum over some files. Is it worth just for this little task to make a dependency on a full-blown cryptographic library or on the linux kernel (even with certain options being activated)? |
|
| Back to top |
|
|
VinzC
Watchman
Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood
|
| Posted: Mon Jul 28, 2014 11:46 pm Post subject: |
|
|
| mv wrote: | 1. Many projects should run on many systems, not just on linux.
2. Security is always a special issure. For instamce, if you call a kernel encryption function, how easy is it for other processes to guess from some delay some bits of information? How about electromagnetic radiation which somebody closeby might be able to measure? Etc. (I am not enough a specialist to answer these questions positively or negatively, but all these should be taken into account by good programs.)
3. Sometimes it is just overkill. For instance, eix needs to calculate an md5 checksum over some files. Is it worth just for this little task to make a dependency on a full-blown cryptographic library or on the linux kernel (even with certain options being activated)? |
Well, I think there would be several ways to achieve that...- What about copying (borrowing) code from the kernel tree? Or a general-purpose library that the kernel and application would use?
- An advantage of centralising crypto is that once the code is patched to fix such an issue, everyone would benefit from it instead of re-writing his code. Hence what about applications that run with an older, unpatched code? In such case centralised crypto code would allow a non-maintainer to recompile the application with the fix.
- Is a full-blown library the only way? Why not make it modular?
The bottom line is that once a good piece of code is known, let it be used by everyone. IMHO it's even more true for security where the reference code has to be efficient and quickly updated.
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
| Back to top |
|
|
miket
Guru
Joined: 28 Apr 2007
Posts: 488
Location: Gainesville, FL, USA
|
| Posted: Mon Jul 28, 2014 11:52 pm Post subject: |
|
|
| Well, there's one more wrinkle. You could well build a kernel that omits whatever nice cryptographic function a program might want. I think you're much better depending on a library. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3135
|
| Posted: Tue Jul 29, 2014 6:05 am Post subject: |
|
|
| Quote: | | . Security is always a special issure. For instamce, if you call a kernel encryption function, how easy is it for other processes to guess from some delay some bits of information? How about electromagnetic radiation which somebody closeby might be able to measure? Etc. (I am not enough a specialist to answer these questions positively or negatively, but all these should be taken into account by good programs.) |
just as easily as with userspace tools or usig specialised crypto device (power consumption/heat generated by crypto card). Not like it was actually easy.
| Quote: | | Sometimes it is just overkill. For instance, eix needs to calculate an md5 checksum over some files. Is it worth just for this little task to make a dependency on a full-blown cryptographic library or on the linux kernel (even with certain options being activated)? |
Anyway, old, unix rule comes to my mind:
Do one thing, but do it well.
If eix needs to run md5 over some files, why not make a program md5sum it's dependency?
If some program needs compression, why not make gzip it's dependency?
If you need encryption, why not to stuff AES algorithm into standalone filter program and make it dependency? Not a library, a program. Executable you can pipe datastream into and collect the results. Standard interface means you are not even bound to any particular programing language.
This way works so well with so many tools related to data processing, so why change it? |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue Jul 29, 2014 6:58 am Post subject: |
|
|
| szatox wrote: | Anyway, old, unix rule comes to my mind:
Do one thing, but do it well. |
This is the rule for tools so that you can combine them. It is not necessarily the rule how bigger projects need to be implemented for which the "one thing" is a complex issue.
| Quote: | | If eix needs to run md5 over some files, why not make a program md5sum it's dependency? |
You would not like to see the speed if it would setup pipes and call an external program whenever it needs this task.
| Quote: | | If some program needs compression, why not make gzip it's dependency? |
gzip/bzip is a different thing, because there are libraries which do just this (eix indeed had such a dependency when it was needed for some task).
Libraries containing md5 are usually full crypto libraries and such overkill. It would be justified if eix really would need security and thus would need to take care about the other points mentioned earlier; however, md5 is only needed to check whether certain files have changed compared to a cache. No, it is just more natural to rewrite this small piece of code than to jump hoops for code reusage which in any case would bring inconvenience to some users (e.g. on embedded devices).
| Quote: | | Not a library, a program |
Speed and security is an issue here. Communication over pipes is certainly easier to observe (at least by root) than a call within a program. And once more: speed. We are talking about tasks like encryption for every disk access or every network access (vpn). You do not want to slow this down more than absolutely necessary.
Of course, all these thnigs already exist: openssl is a command line tool as well as a library. And of course, it is used, e.g. by openssh.
The recent bugs in it show you some of the reasons why not everybody is using it: Security is always somewhat special.
In case it is unclear: The linux kernel needs encryption and must not use a library or program (in any standard format except the very special kernel library format). |
|
| Back to top |
|
|
Genone
Retired Dev
Joined: 14 Mar 2003
Posts: 9527
Location: beyond the rim
|
| Posted: Tue Jul 29, 2014 7:17 am Post subject: |
|
|
| VinzC wrote: | Well, I think there would be several ways to achieve that...- What about copying (borrowing) code from the kernel tree? Or a general-purpose library that the kernel and application would use?
|
No offense, but now we're going from "not a great idea" to "really braindead". Kernel code is quite different from userspace as it has to follow a different set of rules for almost everything (not even talking about ABI issues here). Mixing kernel and userspace should only be done if absolutely necessary.
| Quote: | | An advantage of centralising crypto is that once the code is patched to fix such an issue, everyone would benefit from it instead of re-writing his code. Hence what about applications that run with an older, unpatched code? In such case centralised crypto code would allow a non-maintainer to recompile the application with the fix. |
That works both ways though (Heartbleed). Sure, in most cases it's better to have only one central place to fix. But if you have a proven implementation of an algorithm and you only need that algorithm then using an inline copy isn't a big deal.
| Quote: | | Is a full-blown library the only way? Why not make it modular?The bottom line is that once a good piece of code is known, let it be used by everyone. IMHO it's even more true for security where the reference code has to be efficient and quickly updated. |
Have you ever implemented / depended on a modular system in a coding project that is deployed on unknown end-user systems? "Modular" can cause more headaches and introduce more complexity than you'd think. Again remember we're talking about upstream projects here, so solutions will have to work on very different platforms (often without a good dependency management).
Regarding security implementations, the most important thing is that it is "correct", efficiency is secondary to that (in many cases you don't need or even want a highly efficient solution anyway). |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
