Re: [Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSessionforPharo/Squeak and other Smalltalk implementations
"Miguel Cobá"<miguel.coba@gmail.com> wrote:
But the performance is an issue. And I think that there was a discussion several years ago that lead to choice a plugin instead of the all-smalltalk code (independently of the queality of the smalltalk code). Also a point was made about the maintainability of the smalltalk code with respect to a library of the underlying OS, with respect to CERT issues and 0-day exploits. given the few resources in the community for simpler (relative to crypto) projects like *completion, RB and so, I think is a wise decision to use the proved, tested and maintained OS libraries through a plugin part of the standard VM. Of course, the smalltalk implementation can be used as a fallback for platforms where a plugin isn't available.
These are certainly important things to consider, but I think the arguments need to be more specific and thought through. There are probably dozens of tried and proven libraries for pretty much anything out there, so does that mean there's no point implementing anything? Moreover an external interface is not maintenance free either, they can be surprisingly brittle in many ways and libraries tend to have their own quirks that you may need to accommodate. Anyway, I'd like to focus on the SSL performance argument here. The primary bottleneck of an all-smalltalk SSL implementation are the hashes and symmetric ciphers, which have to chew on every byte of data going through a connection and are too slow in Smalltalk (orders of magnitude slower). The public key algorithms would be the second bottleneck but those are not nearly as bad (more like 5 - 10 times slower depending on the size of the key, and that's primarily because of lack of efficient Integer>>raisedTo:modulo: primitive that peforms well for large integers). Moreover the public key operations happen when a connection is being established, they are not involved in actual data transfer, so long lasting heavily used connections will offset their cost quite easily. To sum up the pub-key ops are no concern on the client, they will likely be a concern on a server (unless it doesn't need to handle many concurrent connections in rapid sequence). So with all that said, I'm confident that a Smalltalk implementation of SSL/TLS can perform as well as any other as long as the hashes and ciphers are farmed out (http://www.cincomsmalltalk.com/userblogs/cst/blogView?printTitle=Xtreams-SSH...). Of course that doesn't automatically mean that is should be implemented in Smalltalk. Given that you currently have both available in Squeak (native, Cryptography, and external, SqueakSSL) see how they stack up to each other. How easy are they to configure and use, where do they work and where they don't, do they provide the same features. I'd be curious how the external implementation deals with the issue of verification of the server certificate (I don't mean checking that it's valid, the library can presumably do that for you, but how does the application check that the certificate identifies the entity that it wants to reach?). What about session management (caching, resumption control, load-balancing etc)? Anyway, lots of things to consider indeed. One thing that wrapping an external library usually doesn't give you is thorough understanding of the mechanics and capabilities of the protocol, which is double-plus important with security. You won't get a secure connection if you don't configure/use the protocol correctly. And you have to configure it to some degree, there isn't an appropriate one-size fits all default. Arguably you shouldn't need to actually implement one to get that understanding, but it sure does help a lot :-). My 2c, Martin
2011/5/14 <mkobetic@gmail.com>:
"Miguel Cobá"<miguel.coba@gmail.com> wrote:
But the performance is an issue. And I think that there was a discussion several years ago that lead to choice a plugin instead of the all-smalltalk code (independently of the queality of the smalltalk code). Also a point was made about the maintainability of the smalltalk code with respect to a library of the underlying OS, with respect to CERT issues and 0-day exploits. given the few resources in the community for simpler (relative to crypto) projects like *completion, RB and so, I think is a wise decision to use the proved, tested and maintained OS libraries through a plugin part of the standard VM. Of course, the smalltalk implementation can be used as a fallback for platforms where a plugin isn't available.
These are certainly important things to consider, but I think the arguments need to be more specific and thought through. There are probably dozens of tried and proven libraries for pretty much anything out there, so does that mean there's no point implementing anything? Moreover an external interface is not maintenance free either, they can be surprisingly brittle in many ways and libraries tend to have their own quirks that you may need to accommodate. Anyway, I'd like to focus on the SSL performance argument here.
The primary bottleneck of an all-smalltalk SSL implementation are the hashes and symmetric ciphers, which have to chew on every byte of data going through a connection and are too slow in Smalltalk (orders of magnitude slower). The public key algorithms would be the second bottleneck but those are not nearly as bad (more like 5 - 10 times slower depending on the size of the key, and that's primarily because of lack of efficient Integer>>raisedTo:modulo: primitive that peforms well for large integers). Moreover the public key operations happen when a connection is being established, they are not involved in actual data transfer, so long lasting heavily used connections will offset their cost quite easily. To sum up the pub-key ops are no concern on the client, they will likely be a concern on a server (unless it doesn't need to handle many concurrent connections in rapid sequence). So with all that said, I'm confident that a Smalltalk implementation of SSL/TLS can perform as well as any other as long as the hashes and ciphers are farmed out (http://www.cincomsmalltalk.com/userblogs/cst/blogView?printTitle=Xtreams-SSH...).
I accelerated raisedTo:modulo: a bit with a primitive (http://bugs.squeak.org/view.php?id=7120) but that's not enough Nicolas
Of course that doesn't automatically mean that is should be implemented in Smalltalk. Given that you currently have both available in Squeak (native, Cryptography, and external, SqueakSSL) see how they stack up to each other. How easy are they to configure and use, where do they work and where they don't, do they provide the same features. I'd be curious how the external implementation deals with the issue of verification of the server certificate (I don't mean checking that it's valid, the library can presumably do that for you, but how does the application check that the certificate identifies the entity that it wants to reach?). What about session management (caching, resumption control, load-balancing etc)?
Anyway, lots of things to consider indeed. One thing that wrapping an external library usually doesn't give you is thorough understanding of the mechanics and capabilities of the protocol, which is double-plus important with security. You won't get a secure connection if you don't configure/use the protocol correctly. And you have to configure it to some degree, there isn't an appropriate one-size fits all default. Arguably you shouldn't need to actually implement one to get that understanding, but it sure does help a lot :-).
My 2c,
Martin
I accelerated raisedTo:modulo: a bit with a primitive (http://bugs.squeak.org/view.php?id=7120) but that's not enough Nicolas
do you know why it was not integrated? It is a good candidate to check the build system of the VM and their evolution. Igor (I gave the windows distribution) to the arnaud so I hope that soon we will get a new windows slave for jenkins. Stef
2011/5/14 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I accelerated raisedTo:modulo: a bit with a primitive (http://bugs.squeak.org/view.php?id=7120) but that's not enough Nicolas
do you know why it was not integrated? It is a good candidate to check the build system of the VM and their evolution. Igor (I gave the windows distribution) to the arnaud so I hope that soon we will get a new windows slave for jenkins.
Stef
Don't know. I also have my modest bitShift: improvments pending (http://bugs.squeak.org/view.php?id=7109). Maybe I haven't performed enough tests to assert the performance gain. The changes are reliable, I run a VM with both improvments without crash for months. I could try to further improve the exponentiation algorithm by mixing a sliding window exponentiation with Montgomery multiplication. There would be other optimisations possible : each modular product fits on a given number of bytes so we could recycle allocated LargeInteger for storing intermediate results rather than letting vm do it. Nicolas
Here is what I suggest. - Keep a log of these fixes may be on the cog vm - did you publish your fixes using the git infrastructure we put in place - because without it we will not work. - Write some tests - Soon igor will resume his work on vm building with hudson and we should get some regression testing tests. - Soon we should be able to introduce these changes and evaluate their impact. - we should push the git infrastructure. Stef On May 14, 2011, at 1:13 PM, Nicolas Cellier wrote:
2011/5/14 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I accelerated raisedTo:modulo: a bit with a primitive (http://bugs.squeak.org/view.php?id=7120) but that's not enough Nicolas
do you know why it was not integrated? It is a good candidate to check the build system of the VM and their evolution. Igor (I gave the windows distribution) to the arnaud so I hope that soon we will get a new windows slave for jenkins.
Stef
Don't know. I also have my modest bitShift: improvments pending (http://bugs.squeak.org/view.php?id=7109). Maybe I haven't performed enough tests to assert the performance gain. The changes are reliable, I run a VM with both improvments without crash for months.
I could try to further improve the exponentiation algorithm by mixing a sliding window exponentiation with Montgomery multiplication. There would be other optimisations possible : each modular product fits on a given number of bytes so we could recycle allocated LargeInteger for storing intermediate results rather than letting vm do it.
Nicolas
2011/5/14 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Here is what I suggest. - Keep a log of these fixes may be on the cog vm - did you publish your fixes using the git infrastructure we put in place - because without it we will not work.
No, this is just 3 or 4 methods to be change in VMMaker, no external C code, only slang.
- Write some tests
bitShift has tests, for Montgomery I don't remember, but that's easy.
- Soon igor will resume his work on vm building with hudson and we should get some regression testing tests. - Soon we should be able to introduce these changes and evaluate their impact. - we should push the git infrastructure.
I just need a commit right in VMMaker if we want to push this. Nicolas
Stef
On May 14, 2011, at 1:13 PM, Nicolas Cellier wrote:
2011/5/14 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I accelerated raisedTo:modulo: a bit with a primitive (http://bugs.squeak.org/view.php?id=7120) but that's not enough Nicolas
do you know why it was not integrated? It is a good candidate to check the build system of the VM and their evolution. Igor (I gave the windows distribution) to the arnaud so I hope that soon we will get a new windows slave for jenkins.
Stef
Don't know. I also have my modest bitShift: improvments pending (http://bugs.squeak.org/view.php?id=7109). Maybe I haven't performed enough tests to assert the performance gain. The changes are reliable, I run a VM with both improvments without crash for months.
I could try to further improve the exponentiation algorithm by mixing a sliding window exponentiation with Montgomery multiplication. There would be other optimisations possible : each modular product fits on a given number of bytes so we could recycle allocated LargeInteger for storing intermediate results rather than letting vm do it.
Nicolas
On Sat, May 14, 2011 at 01:27:11PM +0200, Nicolas Cellier wrote:
2011/5/14 St?phane Ducasse <stephane.ducasse@inria.fr>:
On May 14, 2011, at 1:13 PM, Nicolas Cellier wrote:
2011/5/14 St?phane Ducasse <stephane.ducasse@inria.fr>:
I accelerated raisedTo:modulo: a bit with a primitive (http://bugs.squeak.org/view.php?id=7120) but that's not enough Nicolas
do you know why it was not integrated? It is a good candidate to check the build system of the VM and their evolution. Igor (I gave the windows distribution) to the arnaud so I hope that soon we will get a new windows slave for jenkins.
Stef
Don't know. I also have my modest bitShift: improvments pending (http://bugs.squeak.org/view.php?id=7109). Maybe I haven't performed enough tests to assert the performance gain. The changes are reliable, I run a VM with both improvments without crash for months.
I could try to further improve the exponentiation algorithm by mixing a sliding window exponentiation with Montgomery multiplication. There would be other optimisations possible : each modular product fits on a given number of bytes so we could recycle allocated LargeInteger for storing intermediate results rather than letting vm do it.
Nicolas
Here is what I suggest. - Keep a log of these fixes may be on the cog vm - did you publish your fixes using the git infrastructure we put in place - because without it we will not work.
No, this is just 3 or 4 methods to be change in VMMaker, no external C code, only slang.
Nocolas, sorry I overlooked M7120. The issue had been assigned to tim in 2008, so I just reassigned it to lewis.
- Write some tests
bitShift has tests, for Montgomery I don't remember, but that's easy.
A couple of test or example doits would help, because we should verify that the primitive works on 32/64 bit HOST/IMAGE combinations.
- Soon igor will resume his work on vm building with hudson and we should get some regression testing tests. - Soon we should be able to introduce these changes and evaluate their impact. - we should push the git infrastructure.
I just need a commit right in VMMaker if we want to push this.
Please mention on vm-dev if you want to be added to SqS/VMMaker. Thanks, Dave
On Sat, May 14, 2011 at 01:13:29PM +0200, Nicolas Cellier wrote:
2011/5/14 St?phane Ducasse <stephane.ducasse@inria.fr>:
I accelerated raisedTo:modulo: a bit with a primitive (http://bugs.squeak.org/view.php?id=7120) but that's not enough Nicolas
do you know why it was not integrated? It is a good candidate to check the build system of the VM and their evolution. Igor (I gave the windows distribution) to the arnaud so I hope that soon we will get a new windows slave for jenkins.
Stef
Don't know.
Nicolas, I added your LargeIntegersPlugin>>primMontgomeryTimes:modulo:mInvModB: in SqS/VMMaker/VMMaker-dtl.233 (interpreter VM only, not Cog), and added some notes to http://bugs.squeak.org/view.php?id=7120. It compiles and runs correctly on both 32 and 64 bit platforms, but I cannot confirm the performance gain, so examples or tests would be helpful. On my system I built 32 and 64-bit versions, and I can confirm that the primitive runs and that the results are as expected: 12345678907 raisedTo: 3 modulo: 12345678917 ==> 12345677917 12345678907 montgomeryRaisedTo: 3 modulo: 12345678917 ==> 12345677917 But performance is not good in the example I came up with. On an interpreter VM (not Cog): Time millisecondsToRun: [100000 timesRepeat: [12345678907 raisedTo: 3 modulo: 12345678917]] ==> 633 Time millisecondsToRun: [100000 timesRepeat: [12345678907 montgomeryRaisedTo: 3 modulo: 12345678917]] ==> 1415
Don't know. I also have my modest bitShift: improvments pending (http://bugs.squeak.org/view.php?id=7109). Maybe I haven't performed enough tests to assert the performance gain. The changes are reliable, I run a VM with both improvments without crash for months.
I have not looked at http://bugs.squeak.org/view.php?id=7109 yet but will do so. Dave
2011/5/16 David T. Lewis <lewis@mail.msen.com>:
On Sat, May 14, 2011 at 01:13:29PM +0200, Nicolas Cellier wrote:
2011/5/14 St?phane Ducasse <stephane.ducasse@inria.fr>:
I accelerated raisedTo:modulo: a bit with a primitive (http://bugs.squeak.org/view.php?id=7120) but that's not enough Nicolas
do you know why it was not integrated? It is a good candidate to check the build system of the VM and their evolution. Igor (I gave the windows distribution) to the arnaud so I hope that soon we will get a new windows slave for jenkins.
Stef
Don't know.
Nicolas,
I added your LargeIntegersPlugin>>primMontgomeryTimes:modulo:mInvModB: in SqS/VMMaker/VMMaker-dtl.233 (interpreter VM only, not Cog), and added some notes to http://bugs.squeak.org/view.php?id=7120.
It compiles and runs correctly on both 32 and 64 bit platforms, but I cannot confirm the performance gain, so examples or tests would be helpful.
On my system I built 32 and 64-bit versions, and I can confirm that the primitive runs and that the results are as expected:
 12345678907 raisedTo: 3 modulo: 12345678917 ==> 12345677917  12345678907 montgomeryRaisedTo: 3 modulo: 12345678917 ==> 12345677917
But performance is not good in the example I came up with. On an interpreter VM (not Cog):
 Time millisecondsToRun: [100000 timesRepeat: [12345678907 raisedTo: 3 modulo: 12345678917]] ==> 633  Time millisecondsToRun: [100000 timesRepeat: [12345678907 montgomeryRaisedTo: 3 modulo: 12345678917]] ==> 1415
Yes, there is a little overhead at method startup, so if the power is small, there is no gain in using Montgomery. You must increase the power. Nonetheless, the results with classical VM were mitigated as I wrote in the mantis issue with kind of random performance gains. Note that the results are different with COG: Time millisecondsToRun: [100000 timesRepeat: [12345678907 raisedTo: 3 modulo: 12345678917]] ==> 508 Time millisecondsToRun: [100000 timesRepeat: [12345678907 montgomeryRaisedTo: 3 modulo: 12345678917]] ==> 646 And when we increase the power, Montgomery generally wins by about a factor 2: Time millisecondsToRun: [10000 timesRepeat: [12345678907 raisedTo: 30000 modulo: 12345678917]] ==> 534 Time millisecondsToRun: [10000 timesRepeat: [12345678907 montgomeryRaisedTo: 30000 modulo: 12345678917]] ==> 255 Nicolas
Don't know. I also have my modest bitShift: improvments pending (http://bugs.squeak.org/view.php?id=7109). Maybe I haven't performed enough tests to assert the performance gain. The changes are reliable, I run a VM with both improvments without crash for months.
I have not looked at http://bugs.squeak.org/view.php?id=7109 yet but will do so.
Dave
On Sun, May 15, 2011 at 07:02:56PM -0400, David T. Lewis wrote:
On Sat, May 14, 2011 at 01:13:29PM +0200, Nicolas Cellier wrote:
I also have my modest bitShift: improvments pending (http://bugs.squeak.org/view.php?id=7109). Maybe I haven't performed enough tests to assert the performance gain. The changes are reliable, I run a VM with both improvments without crash for months.
I have not looked at http://bugs.squeak.org/view.php?id=7109 yet but will do so.
Dave
The bitShift: improvements are now in SqS/VMMaker VMMaker-dtl.234 (but not yet in oscog). All tests green for 32 and 64-bit platforms, and also for 64-bit image. Dave
participants (4)
-
David T. Lewis -
mkobetic＠gmail.com -
Nicolas Cellier -
Stéphane Ducasse