Menu
▾
▴
firebird-devel
|
From: Mark R. <ma...@la...> - 2013-05-26 15:53:23
|
If I understand it correctly, the new wire encryption of FB 3 uses RC4, an encryption with known attacks and vulnerabilities. Wouldn't it be better to research other options? http://www.isg.rhul.ac.uk/tls/ Mark -- Mark Rotteveel |
|
From: Jim S. <ji...@ji...> - 2013-05-26 18:05:47
|
From: *Mark Rotteveel* <ma...@la... <mailto:ma...@la...>> > Date: Sun, May 26, 2013 at 11:53 AM > Subject: [Firebird-devel] RC4 for encryption? > To: For discussion among Firebird Developers > <fir...@li... > <mailto:fir...@li...>> > > > If I understand it correctly, the new wire encryption of FB 3 uses RC4, > an encryption with known attacks and vulnerabilities. Wouldn't it be > better to research other options? > > http://www.isg.rhul.ac.uk/tls/ Read the fine print. To break a message, you need 2^30 encrypted versions of a message containing a 256 byte constant block starting at a fixed position. Nice theoretical work, but it isn't a practical attack. Note the chaining algorithm used for AIS stream encryption has also been attacked. I initially implemented NuoDB (then NimbusDB) line encryption with 128 bit AES. The performance hit was about 85%, which just wouldn't fly. Substituting RC4 for AIS dropped this to about 4%. As a result, I left the flexible encryption in place but dropped both AES and plaintext as options, leaving only RC4. RC4 got a bad rep in the WiFi WEP disaster, but the actual problem was an idiotic design where the same short message was encrypted by cycle of partially generated keys. RC4 is pretty much the de facto standard for stream ciphers because of its performance characteristics. Yes, it can be attacked, but only if you sincerely want to be attacked. I don't know what Firebird is now using for password validation, but I strongly suggest that somebody look closely at SRP (secure remote password) to generate session keys. SRP is immune to all but brute force attacks, doesn't require that a server store anything which, if compromised, would allow password (or surrogates) to be computed, and requires a single round trip for authentication. |
|
From: Alex P. <pes...@ma...> - 2013-05-27 06:53:43
|
On 05/26/13 19:53, Mark Rotteveel wrote: > If I understand it correctly, the new wire encryption of FB 3 uses RC4, > an encryption with known attacks and vulnerabilities. Wouldn't it be > better to research other options? RC4 is not more than default wire encryption plugin - if you really do not trust it you can easily write your own. On 05/26/13 21:36, Jim Starkey wrote: > I don't know what Firebird is now using for password validation, but I > strongly suggest that somebody look closely at SRP (secure remote > password) to generate session keys. Use of SRP to generate keys for RC4 is default option in FB3. > SRP is immune to all but brute force attacks, doesn't require that a > server store anything which, if compromised, would allow password (or > surrogates) to be computed, and requires a single round trip for > authentication. > In current network protocol client sends login name and SRP public key to server in connect packet. Server's public key and salt are returned to client accept packet. Hash of session key is sent from client to server in attach (or create) packet as a clumplet in DPB. I.e. no additional roundtrip at this step compared with legacy authentication. Alex. PS. Jim - great thanks to you for all your advices re SRP: they helped much. |
|
From: Mark R. <ma...@la...> - 2013-05-27 07:53:20
|
On Sun, 26 May 2013 13:36:36 -0400, Jim Starkey <ji...@ji...> wrote: > From: *Mark Rotteveel* <ma...@la... <mailto:ma...@la...>> >> If I understand it correctly, the new wire encryption of FB 3 uses RC4, >> an encryption with known attacks and vulnerabilities. Wouldn't it be >> better to research other options? >> >> http://www.isg.rhul.ac.uk/tls/ > > > Read the fine print. To break a message, you need 2^30 encrypted > versions of a message containing a 256 byte constant block starting at a > fixed position. Nice theoretical work, but it isn't a practical attack. > > Note the chaining algorithm used for AIS stream encryption has also been > attacked. Maybe I should have mentioned it explicitly, but I am also thinking of the psychology of "it is new and they use something known to be broken?". > I initially implemented NuoDB (then NimbusDB) line encryption with 128 > bit AES. The performance hit was about 85%, which just wouldn't fly. > Substituting RC4 for AIS dropped this to about 4%. As a result, I left > the flexible encryption in place but dropped both AES and plaintext as > options, leaving only RC4. Was that with or without the use of AES instructions like AES-NI (http://en.wikipedia.org/wiki/AES_instruction_set ) I thought that with use of those instructions AES actually outperformed RC4 (can't find a direct comparison right now though). > RC4 got a bad rep in the WiFi WEP disaster, but the actual problem was > an idiotic design where the same short message was encrypted by cycle of > partially generated keys. > > RC4 is pretty much the de facto standard for stream ciphers because of > its performance characteristics. Yes, it can be attacked, but only if > you sincerely want to be attacked. Ok, good to know. > I don't know what Firebird is now using for password validation, but I > strongly suggest that somebody look closely at SRP (secure remote > password) to generate session keys. SRP is immune to all but brute > force attacks, doesn't require that a server store anything which, if > compromised, would allow password (or surrogates) to be computed, and > requires a single round trip for authentication. Firebird 3 uses SRP. |
|
From: Jim S. <ji...@ji...> - 2013-05-27 15:53:28
|
On 5/27/2013 3:53 AM, Mark Rotteveel wrote: > On Sun, 26 May 2013 13:36:36 -0400, Jim Starkey <ji...@ji...> > wrote: > Read the fine print. To break a message, you need 2^30 encrypted > versions of a message containing a 256 byte constant block starting at a >> fixed position. Nice theoretical work, but it isn't a practical attack. >> >> Note the chaining algorithm used for AIS stream encryption has also been >> attacked. > Maybe I should have mentioned it explicitly, but I am also thinking of the > psychology of "it is new and they use something known to be broken?". Think about that for a minute. RC4 has been around since 1987, has been in widespread use for about a decade and a half, wasn't successfully attacked until this year, and that attack requires 2^30 identical messages encoded with different keys. Anything "new" would require a decade or so rigorous vetting before it could be considered as remotely secure. It is axiomatic in crypto circles that is an algorithm isn't published and subjected to prolonged study, it has be considered as completely insecure. RC4 is based on a 256 byte vector of unique values. Each iteration generates a pseudo-random byte value and swaps two elements. The pseudo-random byte value is XORed with a byte of the cleartext to generate the ciphertext. It should be obvious that an analysis of a very large number of identical encryptions of the same cleartext will expose something about the original cleartext. There are really only three questions here. The first is how many encryptions of a fixed message are required, what is amount of computation necessary to do the analysis, and why would anyone knowing the nature of RC4 be so stupid as to serially encrypt the same message 2^30 times with different keys. If you follow the crypto world, you will find that they tend to get hyper-excited about things that normal folks would find inconsequential. For example, there was a major flap a decode ago when someone decided that if you knew the microsecond that a machine booted (used as a seed in a kernel random number generator) and the number of random numbers generated, you could predict a machine generated session key. All true but also all worthless. But that's what crypto guys are supposed to do, analyze algorithm and design attacks. But a successful attack doesn't mean that the algorithm is necessarily broken or even weak, just that it needs to be used intelligently. Like, say, everything else we use in the real world. > >> I initially implemented NuoDB (then NimbusDB) line encryption with 128 >> bit AES. The performance hit was about 85%, which just wouldn't fly. >> Substituting RC4 for AIS dropped this to about 4%. As a result, I left >> the flexible encryption in place but dropped both AES and plaintext as >> options, leaving only RC4. > Was that with or without the use of AES instructions like AES-NI > (http://en.wikipedia.org/wiki/AES_instruction_set ) I thought that with use > of those instructions AES actually outperformed RC4 (can't find a direct > comparison right now though). It was without -- I didn't have access to a machine with the instruction set. That said, I doubt that it would make a big difference. While the code implementation is going to execute out of the instruction cache and the "instruction" version out of microcode, the amount of computation is the same. The "hardware" would have a clear advantage if the AES algorithm could be parallelized, but a central feature of any crypto algorithm is that it can't. About three years ago I posted the source code for both RC4 and AES transforms for comparisons to firebird-architect. If you'd like to recode the AES transform to use the crypto instruction set compared to C++ version, I would be happy to see the results. I'd do it myself, but I, uh, sold my last implementation and have gotten around to re-implementing the transform library. I also posted Java implementations of SRP and RC4 that anyone working on the JDBC remote might find useful. >> I don't know what Firebird is now using for password validation, but I >> strongly suggest that somebody look closely at SRP (secure remote >> password) to generate session keys. SRP is immune to all but brute >> force attacks, doesn't require that a server store anything which, if >> compromised, would allow password (or surrogates) to be computed, and >> requires a single round trip for authentication. > Firebird 3 uses SRP. > > |
|
From: Mark R. <ma...@la...> - 2013-05-27 18:57:12
|
On 27-5-2013 17:46, Jim Starkey wrote: > On 5/27/2013 3:53 AM, Mark Rotteveel wrote: >>> I initially implemented NuoDB (then NimbusDB) line encryption with 128 >>> bit AES. The performance hit was about 85%, which just wouldn't fly. >>> Substituting RC4 for AIS dropped this to about 4%. As a result, I left >>> the flexible encryption in place but dropped both AES and plaintext as >>> options, leaving only RC4. >> Was that with or without the use of AES instructions like AES-NI >> (http://en.wikipedia.org/wiki/AES_instruction_set ) I thought that with use >> of those instructions AES actually outperformed RC4 (can't find a direct >> comparison right now though). > > It was without -- I didn't have access to a machine with the instruction > set. That said, I doubt that it would make a big difference. While the > code implementation is going to execute out of the instruction cache and > the "instruction" version out of microcode, the amount of computation is > the same. The "hardware" would have a clear advantage if the AES > algorithm could be parallelized, but a central feature of any crypto > algorithm is that it can't. According to some articles like http://www.scottbrownconsulting.com/2011/10/a-look-at-the-performance-impact-of-hardware-accelerated-aes/, the performance improvement of AES-NI over a software implementation is a 3x - 10x (according to Intel), or 4x - 8x (according to TrueCrypt) over a software implementation. The article does mention that in real world application the improvement may be less because these tests ignore all other factors. > About three years ago I posted the source code for both RC4 and AES > transforms for comparisons to firebird-architect. If you'd like to > recode the AES transform to use the crypto instruction set compared to > C++ version, I would be happy to see the results. I'd do it myself, but > I, uh, sold my last implementation and have gotten around to > re-implementing the transform library. http://tech.groups.yahoo.com/group/Firebird-Architect/message/11298 (membership required) That would be an interesting exercise, but my C++ are sufficient enough to be dangerous, but seriously lacking to successfully do that ;) > I also posted Java implementations of SRP and RC4 that anyone working on > the JDBC remote might find useful. As a reminder to myself (and maybe others): http://tech.groups.yahoo.com/group/Firebird-Architect/message/11368 (membership required) I am working on a new implementation of how Jaybird handles the wire protocol to simplify support of new protocol versions (including the one of Firebird 3). But right now I am still working on an implementation of the version 10 protocol and improving/molding the basic class layout I copied from the Firebird .NET provider implementation as a starting point, to better fit with JDBC. When that is done adding new protocol versions (at least upto Firebird 2.5) are next, followed by support for Firebird 3.0. Mark -- Mark Rotteveel |
|
From: Jim S. <ji...@ji...> - 2013-05-27 16:10:48
|
On 5/27/2013 2:53 AM, Alex Peshkoff wrote: > On 05/26/13 19:53, Mark Rotteveel wrote: > >> If I understand it correctly, the new wire encryption of FB 3 uses RC4, >> an encryption with known attacks and vulnerabilities. Wouldn't it be >> better to research other options? > RC4 is not more than default wire encryption plugin - if you really do > not trust it you can easily write your own. > > > On 05/26/13 21:36, Jim Starkey wrote: > >> I don't know what Firebird is now using for password validation, but I >> strongly suggest that somebody look closely at SRP (secure remote >> password) to generate session keys. > Use of SRP to generate keys for RC4 is default option in FB3. > >> SRP is immune to all but brute force attacks, doesn't require that a >> server store anything which, if compromised, would allow password (or >> surrogates) to be computed, and requires a single round trip for >> authentication. >> > In current network protocol client sends login name and SRP public key > to server in connect packet. Server's public key and salt are returned > to client accept packet. Hash of session key is sent from client to > server in attach (or create) packet as a clumplet in DPB. I.e. no > additional roundtrip at this step compared with legacy authentication. > > Is the attach package encrypted with the session key? If so, the hash of the session key isn't necessary. If not, the exchange is susceptible to a man-in-the-middle attack with a buggered DPB. |
|
From: Alex P. <pes...@ma...> - 2013-05-28 10:54:47
|
On 05/27/13 20:10, Jim Starkey wrote: > Is the attach package encrypted with the session key? If so, the hash > of the session key isn't necessary. If not, the exchange is susceptible > to a man-in-the-middle attack with a buggered DPB. > Hops... Though such attack looks at the first glance just theoretically possible, that should be fixed. |
|
From: Jim S. <ji...@ji...> - 2013-05-28 15:31:12
|
I agree completely with your analysis and the contrary conclusion. But
don't feel too bad -- the MySQL security handshake also suffers from a
man-in-the-middle vulnerability wide enough to drive a truck through
that wasn't recognized until I took a critical look at when designing
the NimbusDB security handshake.
There is an SRP validation protocol kicking around, but in my ever
humble opinion, it's ludicrously overbuilt and expensive. I just enable
encryption after the initial message exchange then look very carefully
at the next message after decryption. Due to a change in the
meta-protocol, however, this was a lot easier for me than for Firebird.
Relatively early in NimbusDB development I abandoned all stream
protocols in favor of message based protocols. In specific, each
message is preceded with an unencrypted four byte binary length. This
has all sorts of benefits:
* An extreme long denial-of-service message can be rejected before
allocating resources to receive it
* Message decode can be validated by checking the actual length versus
the deconstructed length
* A store-and-forward messaging proxy becomes trivial (and protocol
independent)
* A multi-socket listening thread / worker threads architecture is
clean, simple, and (almost) bomb-proof (this is a win so big that it
can't be over emphasized)
* Received messages can be easily managed for multiple purposes
(applied, logged, queued, replayed, etc.)
If the new Firebird protocol hasn't switched to counted-packets and it
isn't too late, you might give it some thought.
There are a couple of other things that I have taken to doing that might
be of some interest. One is a standard XML-based initial connection
protocol for all processes. This makes it very easy to add additional
services to a server without resorting to multiple ports. This is much
more important to the NuoDB architecture than Firebird, is almost
certainly too late (it was too late in 1985), but is something to think
about.
The other change is switch to self-describing message encoding. I use
an encoding where the "type" byte encodes both type and length and
sometimes value. There are, for example, type codes for specific
integer between, say, -10 to 32 as well as type codes for integers of
length 1 through 8. When encoding data records, average encoding
lengths were about 60% the length of Firebird's run length encoding.
XDR is getting rather long in tooth, don't you think?
On 5/28/2013 6:54 AM, Alex Peshkoff wrote:
> On 05/27/13 20:10, Jim Starkey wrote:
>
>> Is the attach package encrypted with the session key? If so, the hash
>> of the session key isn't necessary. If not, the exchange is susceptible
>> to a man-in-the-middle attack with a buggered DPB.
>>
> Hops...
> Though such attack looks at the first glance just theoretically
> possible, that should be fixed.
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
|
|
From: Alex P. <pes...@ma...> - 2013-11-07 09:27:27
|
On 05/28/13 19:30, Jim Starkey wrote: > I agree completely with your analysis and the contrary conclusion. But > don't feel too bad -- the MySQL security handshake also suffers from a > man-in-the-middle vulnerability wide enough to drive a truck through > that wasn't recognized until I took a critical look at when designing > the NimbusDB security handshake. > > There is an SRP validation protocol kicking around, but in my ever > humble opinion, it's ludicrously overbuilt and expensive. I just > enable encryption after the initial message exchange then look very > carefully at the next message after decryption. Due to a change in > the meta-protocol, however, this was a lot easier for me than for > Firebird. > > Relatively early in NimbusDB development I abandoned all stream > protocols in favor of message based protocols. In specific, each > message is preceded with an unencrypted four byte binary length. This > has all sorts of benefits: > > * An extreme long denial-of-service message can be rejected before > allocating resources to receive it > * Message decode can be validated by checking the actual length versus > the deconstructed length > * A store-and-forward messaging proxy becomes trivial (and protocol > independent) > * A multi-socket listening thread / worker threads architecture is > clean, simple, and (almost) bomb-proof (this is a win so big that it > can't be over emphasized) > * Received messages can be easily managed for multiple purposes > (applied, logged, queued, replayed, etc.) > > If the new Firebird protocol hasn't switched to counted-packets and it > isn't too late, you might give it some thought. > > There are a couple of other things that I have taken to doing that > might be of some interest. One is a standard XML-based initial > connection protocol for all processes. This makes it very easy to add > additional services to a server without resorting to multiple ports. > This is much more important to the NuoDB architecture than Firebird, > is almost certainly too late (it was too late in 1985), but is > something to think about. > > The other change is switch to self-describing message encoding. I use > an encoding where the "type" byte encodes both type and length and > sometimes value. There are, for example, type codes for specific > integer between, say, -10 to 32 as well as type codes for integers of > length 1 through 8. When encoding data records, average encoding > lengths were about 60% the length of Firebird's run length encoding. > XDR is getting rather long in tooth, don't you think? > I think that such or similar protocol will be in my todo for next FB version. What is probably interesting - when fixing an error I've found that an ability of man-in-the-middle attack was far very from just theoretical due to services. In services API there is wonderful isc_spb_command_line tag, which makes it possible to transfer command line for services utility. Adding something like 'mod sysdba -pw newpassword' for any security database service looks rather interesting for an attacker. And Jim - big thanks for this and all previous advices regarding authorization, encryption and other related things! > On 5/28/2013 6:54 AM, Alex Peshkoff wrote: >> On 05/27/13 20:10, Jim Starkey wrote: >> >>> Is the attach package encrypted with the session key? If so, the hash >>> of the session key isn't necessary. If not, the exchange is >>> susceptible >>> to a man-in-the-middle attack with a buggered DPB. >>> >> Hops... >> Though such attack looks at the first glance just theoretically >> possible, that should be fixed. >> >> >> ------------------------------------------------------------------------------ >> >> Try New Relic Now & We'll Send You this Cool Shirt >> New Relic is the only SaaS-based application performance monitoring >> service >> that delivers powerful full stack analytics. Optimize and monitor your >> browser, app, & servers with just a few lines of code. Try New Relic >> and get this awesome Nerd Life shirt! >> http://p.sf.net/sfu/newrelic_d2d_may >> Firebird-Devel mailing list, web interface at >> https://lists.sourceforge.net/lists/listinfo/firebird-devel > > > > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > > > Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X