Use static DHCP on your DHCP server and a UDP port forward. Your IP won't change (due to static DHCP which always gives the same IP address to a given Ethernet address) so it should never need to be updated. This is pretty straight forward with Tomato firmware.
An OpenSSL written in Java would be a complete non-starter. Nobody would use it because it would be too slow.
For most applications, you are right that safety outweighs performance concerns. However, OpenSSL is in that 1% of applications where performance outweighs everything. It is a crypto library. Crypto is extremely CPU intensive.
OpenSSL is expected to run as fast as possible, to the point where parts of it aren't even written in C. The core bignum and hashing routines are written in assembly language for various platforms.
You even mentioned this caveat: if you're not writing an OS, a game, or a calculation based app (lapack, etc...)
But you didn't seem to realize that this caveat certainly applies to OpenSSL (if ever there were a calculation based app, this is it).
You only need to recompile things that use the SSL part of the OpenSSL(like mod_ssl). You do not have to recompile things that only link the crypto part of OpenSSL (OpenSSH only uses the crypto part of OpenSSL).
You can see what is used by doing an ldd on the binary. If you see libssl listed, you need to recompile. If you only see libcrypto, you do not.
Note that this ldd trick only works on dynamically linked binaries. If the binary is statically linked, you won't see either library listed no matter what (in which case you will need to do more research to figure out what to rebuild).
OpenSSH is not affected by these problems on any platform. OpenSSH uses only the crypto part of OpenSSL (not the SSL stack). These bugs are in the SSL stack.
Yet we don't see Linux distributers refusing to include products with those licenses.
You seem to imply that the Linux distributors don't care about those licenses and their GPL interactions, which is not true. The problem is that GPL programs cannot be linked to code (like libraries) that has advertising clauses.
I know that at least Debian is very careful to respect this restriction (GPL Ethereal is not linked with OpenSSL even though it loses functionality).
The real issue why this is a problem is that a lot of XFree86 is in the form of libraries (xlib). So any app that needs to link xlib cannot be GPLed.
This screws up Qt, KDE, and many other things (basically any GPL app with a GUI).
It isn't as much of a problem with the things you name for a few reasons. A lot of old BSD licensed code got a licensing change (from the Regents) that removed the advertising clause. More importantly, a lot of the things you name (Apache, Mozilla) are not libraries so you don't have as much of a problem there.
This is a big problem and David Dawes and company have just made themselves irrelevant. They will have to back down (revert the license) or their project will be ignored from here on out. Distros will adopt other projects or do their own work on XFree 4.3.
Debian has to support around a dozen different platforms. The excellent hardware detection in Knoppix is unfortunately x86 specific, so its not a drop-in replacement for what they need to have.
The Debian people are rewriting their installer right now for the upcoming release. One of the big goals is improved auto-detection of hardware. I'm not sure if they are pulling things from Knoppix, but hopefully so for the x86 platform.
There is a section on their website called Documentation with some good material in it. There is also a link to various books about Debian (I haven't read any of them though).
If you don't want to change things around a lot, Debian is good for you. While the initial install can be a bit difficult, you will only need to install it once in your life (upgrades are seamless; especially compared to Red Hat's). Also, they are doing significant work on Sarge's installer right now so it should be much improved when it comes out.
If Sarge were out (it was originally scheduled for this month, but it is behind schedule), I would recommend using it. The stable release is very stable, but can get old since they don't release frequently. Testing is as stable as most other distros (the scripts that generate it automatically prevent obviously broken things from creeping into it from unstable).
My advice would be to read the documentation about the install on their web site. It is less intimidating if you know exactly what to expect. Also, the best advice I can give is to skip dselect entirely during the install (if you get in there, just exist without installing any packages). Once you are up and running use apt-get (or aptitude or synaptic) instead.
After that, if you find things are too old for you (most people do for desktops since it is KDE 2 and Gnome 1), you should either upgrade to testing (Sarge) now or use backports of relevant packages that are targeted for Woody (KDE, Gnome, OpenOffice).
Once installed, maintenance is very easy. Security updates for stable releases will come for years (instead of the months Red Hat seems to be offering per stable release these days). Upgrades to the next stable releases will be very simple (my machine has been upgraded through three major releases at this point).
OpenBSD is a better firewall (pf is very nice), but NetBSD is a bit more portable (in the unlikely event that OpenBSD won't run on it). I think the platform you are looking for is called mac68k or m68k.
I think it is Vermont that has outlawed the sleasiest version of this practice (advertising very low prices and requiring complicated error prone mail-in-rebates to get it).
The law says that if they factor a rebate into the advertised price, they have to give you the rebate money at the cash register. Essentially it outlaws the practice of factoring in mail-in rebates in advertised prices. More states need to follow their lead.
This will be the installer you get with the upcoming stable release of Debian (Sarge). Right now it is still in development. If you want to wait until this is deployed, wait for the announcement that Sarge is released and then go try it out.
I don't know the exact details of how it is more efficient. It was explained to me once in a quantum computation course (where among other things they were using equations to relate energy to information).
So I don't know how to explain in terms of currents and transistors, but it is similar to what mikee is saying in this thread (that thermodynamic laws say that destroying information will always consume energy).
The reason quantum computation guys tend to know about this area is because all logical operations on a quantum computer (except for the measurement at the end) are reversible operations.
This is more practical than quantum computers because it is much easier to build and can be used for general purpose things other than search and factoring.
The idea is to (down at the gate level) keep everything reversible. For example, current OR gates are not reversible (given a true output you can't definitively tell what either input was individually). If you have two outputs on the gate instead of one, you make the gate reversible. However, since you are just using it for OR, you are free to ignore the second bit you added on to make it reversible.
The bit doesn't help your computation in the sense of the answer you are looking for, but it can make things more energy efficient at the gate level.
The main reason Cross Site Scripting is abbreviated XSS (instead of CSS) is to avoid confusing it with Cascading Style Sheets (this confusion is likely to happen since both of these things are related to web pages).
Although the most talked about application is factoring (breaking RSA), you can also do certain kinds of search in a similarly radical amount of time.
Let's say you have the numbers 1 through n in an unsorted list. On a classical computer, you would need O(n) tries to find a specific number (on average you would search half of the list). On a quantum computer, you can do this in O(sqrt(n)) which is significantly better for large n.
As an MIT CS major who was forced to take this class (6.002), I definitely agree that this is a much needed change.
6.002 was basically hundreds and hundreds of circuit diagrams where you would use loop rules and differential equations to solve for whichever value they didn't supply in the diagram. There was no talk about what the circuit was actually doing, or why you would want such a circuit. A more real-world approach would bring some much-needed balance to the class.
Actually, the other reason this new class probably seems better is because it has 10x less students per professor (vs. traditional 6.002). They could solve most of that problem by not forcing CS majors to take 6.002. Due to the fact that EE and CS are the same departments at MIT, CS majors have to take this and EE majors have to take Scheme programming. Students on both sides are unhappy about these requirements. I've never had to use 6.002 since its final exam, and I'm sure most EEs have never had to write a line of Scheme since 6.001.
Yes, I agree whole-heartedly about how bad/complicated the ASN.1 string situations is and that it didn't exactly help X.509's complexity problems. However, X.509 can't blame all of its woes on ASN.1 (certificate policy? what were they thinking?).
I disagree though about your negative characterization of SSL. SSLv2 was a bad (unsafe) half-baked protocol thrown together by a Netscape engineer with little cryptography knowledge. SSLv3, however, was a complete redesign done mainly by Paul Kocher, a very knowledgeable cryptographer. SSLv3 was basically sound, so when it came time to make TLS (the RFC-blessed one), very few tweaks were necessary. There are no really "bone-headed" mistakes in SSLv3 or TLS, but there are many in SSLv2.
The SSH standard is indeed quite different from the original SSH.com stuff, but the with the standard now in place (after the technology was developed), it is easy for say OpenSSH and SSH.com to interoperate by following the standard.
Also. the expert bake-off is indeed a good way to make a standard (much better than having a committee design). The AES competition is a very good example of this.
Even the language I use to post this reply is a standard.
Yes it is, but you are missing his point. A standards body did not come up with the language one day out of the blue. People were speaking the language for a long time before it was standardized officially.
The article is not against standards, but against the idea that a committee is going to come up with a standard technology all on its own.
I think he has some very good points, the best one being that a standards committee is not the place to design a technology. When committees design things from scratch you get horrendously overcomplicated things like X.509 and IKE (IPsec's key agreement protocol).
He's not saying that standards are bad, as much as he's saying that it may be better to take existing useful technology and then standardize it (think SSH and SSL, protocols that were standardized after initial deployment).
In the cases designed by committees, they ended up with something so complicated that nobody has ever implemented it fully (X.509*). In the cases that were implemented and later standardized, deployments with full features are widespread.
(*At first glance, the statements about X.509 seem contradicted by the fact that X.509 is used in SSL. The fact is that SSL stacks use about 1% of the features described in RFC 2459 (X.509v3). This is what I'm talking about: ridiculously overcomplicated committee designs)
I think it is somewhat unreasonable to expect a big number (BN) library to be completely transparent on a casual reading. Public key (BN) operations in software are very slow. The OpenSSL implementation uses every optimisation it can to speed up its BN operations, just like compiler writers do everything they can to optimize the compiler output.
Did you write your own compiler? No, well have you read every line of gcc? Especially all of the complicated optimizer that makes the binary run faster? Even if you wrote a very dumb BN library that was easier to read, you would still have to worry about an "overflow on line 8 billion of some underlying library" (your compiler in this case).
I agree that OpenSSL's BN library could be better documented internally, but I don't think they should unoptimize it for clarity. People want transparent crypto, meaning they don't like experiencing 100-fold slowdowns when they add crypto to their application. BN optimization is critical in minimizing this slowdown (CRT, Montgomery reduction, sliding windows, Karatsuba, etc.).
HLL's can be misused just as effectively as LLL's.
Agreed. This guy mentions recent bugs in OpenSSL to try to bolster his argument. Of those three bugs, exactly zero of them would have been prevented by using a high-level language.
Lasec CBC attack
This was a timing attack based on the fact that certain errors would cause OpenSSL to return before computing a MAC. Nothing to do with language choice.
RSA timing attack
This was a timing attack based on how long it takes to decrypt a given RSA ciphertext. Again, nothing to do with language choice.
Modified Bleichenbacher attack
This was an attack based on different error codes coming back depending on different decryption results. Again, nothing to do with language choice.
Basically, by choosing these examples, this guy refutes the very point he is trying to make. In fact, for the first two bugs, a slower language like Java would make it even easier to mount a timing attack (since each crypto operation would go much slower, an operation's absense would be more detectable).
Migrating away from C may solve buffer overflows, but it is not a panacea. I'd rather use code written in C by security-minded coders than HLL code written by somebody clueless.
You are correct that they didn't need to change the alert code to fix the problem. I mispoke due to confusion from reading their code before yesterday's fix. Even before the fix, their code made sure to return the same alert in both cases, but there was still a timing difference because of the MAC computation.
Although returning the different alert codes isn't specifically what opens you up to vulnerability (because as you noted the alert codes are encrypted), the fact that the RFC has different alert codes for these scenarios leads the implementer down the path of handling them differently (which will easily lead to timing differences if you aren't careful). There is no good reason to have two different error codes for these two conditions in TLS (SSLv3 got it right here and only had a single MAC error code). Two separate error codes leads implementers towards vulnerable implementations.
An analagous attack is the Bleichenbacher attack. The TLS RFC explicitly states what implementers should do to avoid that attack (treat bad PKCS#1 padding just like a bad Finished message). However, instead of having some helpful note about this, the RFC has a very unhelpful suggestion to send a separate alert code for a condition that needs to be treated identically in terms of timing.
No, they didn't know this attack then, but they violated the principle of not revealing more error information than is necessary. They went into detail describing how not to leak to much information about PKCS#1 padding, but then they did not follow their own advice about block cipher padding.
RC4 has a history of implementation flaws. It is a good algorithm but it is quite often applied to the wrong problem and IMO anything that is not classic stream and has known plaintext fragments is a "wrong problem". The results of such misapplications are well knonw. MSFT 40 bit PPTP, WEP are just a few fine examples.
Those are examples of crypto protocols that were designed by non-cryptographers. SSL/TLS does not fall into that category. Those vulnerabilities were due to very stupid key derivation algorithms ("let's add three to the last RC4 key and use that...").
SSL's use of a PRF to generate the key material gets around the RC4 key derivation problems present in WEP and in PPTP. The last couple of SSL protocol problems have had to do with block ciphers. RC4 would have protected you in all cases; both this one, as well as an arlier theoretical result about mac-then-encrypt security protocols.
Slashdot Mirror
Use static DHCP on your DHCP server and a UDP port forward. Your IP won't change (due to static DHCP which always gives the same IP address to a given Ethernet address) so it should never need to be updated. This is pretty straight forward with Tomato firmware.
That is incorrect. They encouraged taping and non-commercial trading. Selling of the tapes is/was prohibited.
For most applications, you are right that safety outweighs performance concerns. However, OpenSSL is in that 1% of applications where performance outweighs everything. It is a crypto library. Crypto is extremely CPU intensive.
OpenSSL is expected to run as fast as possible, to the point where parts of it aren't even written in C. The core bignum and hashing routines are written in assembly language for various platforms.
You even mentioned this caveat:
if you're not writing an OS, a game, or a calculation based app (lapack, etc...)
But you didn't seem to realize that this caveat certainly applies to OpenSSL (if ever there were a calculation based app, this is it).
You can see what is used by doing an ldd on the binary. If you see libssl listed, you need to recompile. If you only see libcrypto, you do not.
Note that this ldd trick only works on dynamically linked binaries. If the binary is statically linked, you won't see either library listed no matter what (in which case you will need to do more research to figure out what to rebuild).
OpenSSH is not affected by these problems on any platform. OpenSSH uses only the crypto part of OpenSSL (not the SSL stack). These bugs are in the SSL stack.
The previous poster is incorrect. BitTorrent has nothing to do with Kazaa (0 lines of code in common).
BitTorrent is open source (MIT license) and written in Python.
Kazaa is closed source, spyware-ridden dreck that was probably written in C++.
You seem to imply that the Linux distributors don't care about those licenses and their GPL interactions, which is not true. The problem is that GPL programs cannot be linked to code (like libraries) that has advertising clauses.
I know that at least Debian is very careful to respect this restriction (GPL Ethereal is not linked with OpenSSL even though it loses functionality).
The real issue why this is a problem is that a lot of XFree86 is in the form of libraries (xlib). So any app that needs to link xlib cannot be GPLed. This screws up Qt, KDE, and many other things (basically any GPL app with a GUI).
It isn't as much of a problem with the things you name for a few reasons. A lot of old BSD licensed code got a licensing change (from the Regents) that removed the advertising clause. More importantly, a lot of the things you name (Apache, Mozilla) are not libraries so you don't have as much of a problem there.
This is a big problem and David Dawes and company have just made themselves irrelevant. They will have to back down (revert the license) or their project will be ignored from here on out. Distros will adopt other projects or do their own work on XFree 4.3.
The Debian people are rewriting their installer right now for the upcoming release. One of the big goals is improved auto-detection of hardware. I'm not sure if they are pulling things from Knoppix, but hopefully so for the x86 platform.
If you don't want to change things around a lot, Debian is good for you. While the initial install can be a bit difficult, you will only need to install it once in your life (upgrades are seamless; especially compared to Red Hat's). Also, they are doing significant work on Sarge's installer right now so it should be much improved when it comes out.
If Sarge were out (it was originally scheduled for this month, but it is behind schedule), I would recommend using it. The stable release is very stable, but can get old since they don't release frequently. Testing is as stable as most other distros (the scripts that generate it automatically prevent obviously broken things from creeping into it from unstable).
My advice would be to read the documentation about the install on their web site. It is less intimidating if you know exactly what to expect. Also, the best advice I can give is to skip dselect entirely during the install (if you get in there, just exist without installing any packages). Once you are up and running use apt-get (or aptitude or synaptic) instead.
After that, if you find things are too old for you (most people do for desktops since it is KDE 2 and Gnome 1), you should either upgrade to testing (Sarge) now or use backports of relevant packages that are targeted for Woody (KDE, Gnome, OpenOffice).
Once installed, maintenance is very easy. Security updates for stable releases will come for years (instead of the months Red Hat seems to be offering per stable release these days). Upgrades to the next stable releases will be very simple (my machine has been upgraded through three major releases at this point).
OpenBSD is a better firewall (pf is very nice), but NetBSD is a bit more portable (in the unlikely event that OpenBSD won't run on it). I think the platform you are looking for is called mac68k or m68k.
The law says that if they factor a rebate into the advertised price, they have to give you the rebate money at the cash register. Essentially it outlaws the practice of factoring in mail-in rebates in advertised prices. More states need to follow their lead.
This will be the installer you get with the upcoming stable release of Debian (Sarge). Right now it is still in development. If you want to wait until this is deployed, wait for the announcement that Sarge is released and then go try it out.
So I don't know how to explain in terms of currents and transistors, but it is similar to what mikee is saying in this thread (that thermodynamic laws say that destroying information will always consume energy).
The reason quantum computation guys tend to know about this area is because all logical operations on a quantum computer (except for the measurement at the end) are reversible operations.
The idea is to (down at the gate level) keep everything reversible. For example, current OR gates are not reversible (given a true output you can't definitively tell what either input was individually). If you have two outputs on the gate instead of one, you make the gate reversible. However, since you are just using it for OR, you are free to ignore the second bit you added on to make it reversible.
The bit doesn't help your computation in the sense of the answer you are looking for, but it can make things more energy efficient at the gate level.
The main reason Cross Site Scripting is abbreviated XSS (instead of CSS) is to avoid confusing it with Cascading Style Sheets (this confusion is likely to happen since both of these things are related to web pages).
Let's say you have the numbers 1 through n in an unsorted list. On a classical computer, you would need O(n) tries to find a specific number (on average you would search half of the list). On a quantum computer, you can do this in O(sqrt(n)) which is significantly better for large n.
6.002 was basically hundreds and hundreds of circuit diagrams where you would use loop rules and differential equations to solve for whichever value they didn't supply in the diagram. There was no talk about what the circuit was actually doing, or why you would want such a circuit. A more real-world approach would bring some much-needed balance to the class.
Actually, the other reason this new class probably seems better is because it has 10x less students per professor (vs. traditional 6.002). They could solve most of that problem by not forcing CS majors to take 6.002. Due to the fact that EE and CS are the same departments at MIT, CS majors have to take this and EE majors have to take Scheme programming. Students on both sides are unhappy about these requirements. I've never had to use 6.002 since its final exam, and I'm sure most EEs have never had to write a line of Scheme since 6.001.
I disagree though about your negative characterization of SSL. SSLv2 was a bad (unsafe) half-baked protocol thrown together by a Netscape engineer with little cryptography knowledge. SSLv3, however, was a complete redesign done mainly by Paul Kocher, a very knowledgeable cryptographer. SSLv3 was basically sound, so when it came time to make TLS (the RFC-blessed one), very few tweaks were necessary. There are no really "bone-headed" mistakes in SSLv3 or TLS, but there are many in SSLv2.
The SSH standard is indeed quite different from the original SSH.com stuff, but the with the standard now in place (after the technology was developed), it is easy for say OpenSSH and SSH.com to interoperate by following the standard.
Also. the expert bake-off is indeed a good way to make a standard (much better than having a committee design). The AES competition is a very good example of this.
Yes it is, but you are missing his point. A standards body did not come up with the language one day out of the blue. People were speaking the language for a long time before it was standardized officially.
The article is not against standards, but against the idea that a committee is going to come up with a standard technology all on its own.
He's not saying that standards are bad, as much as he's saying that it may be better to take existing useful technology and then standardize it (think SSH and SSL, protocols that were standardized after initial deployment).
In the cases designed by committees, they ended up with something so complicated that nobody has ever implemented it fully (X.509*). In the cases that were implemented and later standardized, deployments with full features are widespread.
(*At first glance, the statements about X.509 seem contradicted by the fact that X.509 is used in SSL. The fact is that SSL stacks use about 1% of the features described in RFC 2459 (X.509v3). This is what I'm talking about: ridiculously overcomplicated committee designs)
Bugtraq didn't trash anything. This all happened on ntbugtraq which is not affiliated with bugtraq.
Did you write your own compiler? No, well have you read every line of gcc? Especially all of the complicated optimizer that makes the binary run faster? Even if you wrote a very dumb BN library that was easier to read, you would still have to worry about an "overflow on line 8 billion of some underlying library" (your compiler in this case).
I agree that OpenSSL's BN library could be better documented internally, but I don't think they should unoptimize it for clarity. People want transparent crypto, meaning they don't like experiencing 100-fold slowdowns when they add crypto to their application. BN optimization is critical in minimizing this slowdown (CRT, Montgomery reduction, sliding windows, Karatsuba, etc.).
Agreed. This guy mentions recent bugs in OpenSSL to try to bolster his argument. Of those three bugs, exactly zero of them would have been prevented by using a high-level language.
Basically, by choosing these examples, this guy refutes the very point he is trying to make. In fact, for the first two bugs, a slower language like Java would make it even easier to mount a timing attack (since each crypto operation would go much slower, an operation's absense would be more detectable).
Migrating away from C may solve buffer overflows, but it is not a panacea. I'd rather use code written in C by security-minded coders than HLL code written by somebody clueless.
Although returning the different alert codes isn't specifically what opens you up to vulnerability (because as you noted the alert codes are encrypted), the fact that the RFC has different alert codes for these scenarios leads the implementer down the path of handling them differently (which will easily lead to timing differences if you aren't careful). There is no good reason to have two different error codes for these two conditions in TLS (SSLv3 got it right here and only had a single MAC error code). Two separate error codes leads implementers towards vulnerable implementations.
An analagous attack is the Bleichenbacher attack. The TLS RFC explicitly states what implementers should do to avoid that attack (treat bad PKCS#1 padding just like a bad Finished message). However, instead of having some helpful note about this, the RFC has a very unhelpful suggestion to send a separate alert code for a condition that needs to be treated identically in terms of timing.
No, they didn't know this attack then, but they violated the principle of not revealing more error information than is necessary. They went into detail describing how not to leak to much information about PKCS#1 padding, but then they did not follow their own advice about block cipher padding.
Those are examples of crypto protocols that were designed by non-cryptographers. SSL/TLS does not fall into that category. Those vulnerabilities were due to very stupid key derivation algorithms ("let's add three to the last RC4 key and use that...").
SSL's use of a PRF to generate the key material gets around the RC4 key derivation problems present in WEP and in PPTP. The last couple of SSL protocol problems have had to do with block ciphers. RC4 would have protected you in all cases; both this one, as well as an arlier theoretical result about mac-then-encrypt security protocols.