If we're going to hack a protocol (really? DNS? Why not just implement TLS over DNS while we're at it? Then captive portals will just block *everything*) we might as well hack SSL. I didn't say root CAs would have to be paid CAs. Any notary could be a CA just as easily, the *only* security difference is that there's now a variable level of trust that the user controls. In practical terms, a PKI infrastructure based on certificates is also more scalable. What happens when there are two billion sites (like Moxie hoped) that all need to be queried once a day by every notary? Who pays those bandwidth bills? Certificates also have a major advantage in that they can be signed securely, offline, by hardware if necessary, and then distributed by untrusted servers. Notaries will require the entire software stack to be trusted at all times.
There is one other aspect of notaries that is nice at first glance, and that's the fact that users are in control of which notaries they trust and site admins basically don't have to do anything. The subtle problem, of course, is that some server in China has no chance of getting its real certificate out to any notaries. The Great Firewall will MITM every single connection if the government so chooses. One might argue that this situation is unwinnable; if China never lets the real certificate through it's an effective denial of service attack. It would be better, however, to detect the DoS rather than lose completely to a MITM attack. If site owners are forced to register with CAs who they trust, the MITM attack is eliminated entirely.
Ultimately, if all the browsers start supporting notaries directly and ship with a list of major trusted notaries this won't be a problem. But bootstrapping a trust network to replace a presumably untrusted PKI while using that same PKI to validate the code you're using to replace it... It's sort of unfounded.
The sole benefit of convergence is the ability to trust individual entities less than 100% and require that more than one entity (notary in this case) vouches for the validity of an SSL certificate. The existing CA system would be vastly improved if this simple change was added so that every major root CA is only trusted in proportion to the ability of obtaining an invalid certificate, and multiple signatures would be required on each SSL certificate. This is almost exactly the same case as requiring multiple notaries to validate a certificate except that it retains the offline trust ability that is still necessary for captive portals and also allows sites to use as many SSL certificates as they want for their sites, so long as they get them signed by enough CAs. In the diginotar case, Mozilla could have just dropped the trust in the diginotar root certificate, potentially requiring some sites to acquire additional signatures from other CAs. The (huge) problem is that SSL does not support multiple chains of trust for a single certificate and every SSL stack in the world would have to be changed. Some hacks are probably possible to allow interoperability between new and old servers and clients. Ultimately, signatures are a much more robust cryptographic building block than mandatory online verification.
This is what the network notary system (Perspectives / Convergence plugin) is for, take a look at it. When you visit a site, it compares the cert your browser receives with what other computers around the world are seeing at the same time.
From the perspectives project: Perspectives is a new approach to helping computers communicate securely on the Internet. With Perspectives, public “network notary” servers regularly monitor the SSL certificates used by 100,000s+ websites to help your browser detect “man-in-the-middle” attacks without relying on certificate authorities.
There are a few problems: network notaries can be selectively denied by an attacker. Will browsers complain that only a fraction of the selected notaries were able to be queried before connecting? Network notaries will be just as vulnerable to attack as root CAs (if not moreso; many will likely run on consumer hardware with private keys laying in RAM instead of a secure addon crypto processor); change the list of certificates that the network notary stores and it will validate an attacker's MITM certificate. Steal a network notary's private key and simply impersonate them. If a notarized site has its DNS spoofed to point to an attacker's site for long enough (and they can simply replay traffic so everything looks normal), the attacker's MITM certificate may be accepted as a valid change of certificate. Attackers can spoof the major sites to the notaries by sending the MITM certificates only to known notaries so as not to alert users with browser certificate checking turned on. Notaries will be of no value within closed networks whereas existing CA architectures allow trust to be calculated between peers who trust an offline third party.
Individual notaries are just as vulnerable to legal (or criminal) intervention as root CAs are today. China and other repressive regimes will almost certainly block access to notaries if it serves their purposes, or enforce usage of state-controlled notaries. Notaries won't scale to billions of sites unless they are very large. Who pays their bandwidth bills? CAs pay their bills by charging for validation. In short, the only way to fix the SSL certificate trust problem on the Internet is to use the PGP web of trust model to assign limited trust to many entities and calculate cumulative trust from distinct signatures of a particular SSL certificate by many semi-trusted entities. This can be accomplished with CAs, notaries, individuals, or a mix of all three. Signatures are far more bandwidth and computationally efficient than realtime queries and attestations and they can be computed offline to keep private key material as secure as possible.
The only advantage of notaries that I can see is that certificate revocation becomes automatic and much more timely. Still, realtime CRL checks serve the same purpose.
No one can "steal" your existing certificate unless they also steal your web server's private key. A CA can issue a fraudulent certificate for your site, but anyone can generate a self-signed certificate for your site as well. How does a CA make MITM attacks more likely? How many users visit your web site for the first time on an untrusted wireless network or in a country where the government may want to feed them a fake certificate anyway? Propagation and widespread trust of self-signed certs is what would actually cause a rise in the number of MITM attacks. This story is about known bad certificates that everyone can avoid by removing a single root CA from their browser. I haven't heard of any reported MITM attacks resulting from the bad certificates, although I wouldn't be surprised if some occurred. In a world of self-signed certificates there isn't even a way to begin to detect MITM attacks (much less stop them) unless you watch every connection between every client and web server and keep track of every possible certificate ever generated and its use history. Did your favorite web site just change its self-signed certificate because they lost the private key due to hardware failure, because it expired, or some other legitimate reason? Or is this a MITM attack?
Just as an example, I am "lucky" enough to own one of the Via Unichrome devices that's losing support. It had iffy support to begin with because Via released an old open source driver with no documentation and it was up to volunteers to keep it running as Xorg changed. Comments in the code included things like "Rewrite this so that it actually uses screens and GL contexts in the appropriate way" because the original Via programmers did things strangely. I had to write a couple horrible hacks to detect double-free corruption using magic values to keep KDE from crashing on startup. I was hoping I could learn enough to rewrite the driver properly to use it on my old laptop, but I imagine now it will just keep the hacky, mostly-working code that it has right now. Given the existence of unfixed bugs in ancient code that doesn't even use the Xorg/Mesa APIs right, it's probably the right decision to drop it.
The best part is that if anyone cares to fix it, they can just update the code and submit it back into Xorg and everything will be happy again. If I ever get stuck on a desert island with that laptop and a solar panel, I'll submit a patch when I get back.
An API is just a list of function prototypes and the type definitions they depend on. The only reason function names are required is that so far there isn't a general semantic langauge that specifies (simply, and with clarity) the preconditions and postconditions of the functions, so the linker needs a way to bind calls to the appropriate functions instead of just pattern matching based on formal semantics.
If "type_1 function_name_1(type_2, type_3, type_4, type_5)..." is your idea of copyrightable content, then I have some very boring novels to sell you.
Both OSS and FSF licenses are necessary and are balanced by the state of the software industry. In a wide-open industry OSS does fine and software vendors can safely write and use OSS. When even a few (large/important/influential) companies start to play badly with others, close their source, and embrace and extend the standards, the demand for FSF software increases.
Presumably we are now seeing a high demand for purely open standards and software. This is enabled primarily by the wide availability of open standards and software that already exist. People seem to forget that just 20 years ago there were no widely available free operating systems, free compilers, or free application frameworks. Today there are hundreds of major examples, even from traditionally closed-source vendors. That will change in the future, as it has in the past. Then the FSF will again be able to fulfill the demand for community-centered software that prevents individuals in the industry from controlling too large a portion of the market to the detriment of others.
In short, OSS works wonderfully on a level playing field. Free Software can level any existing playing field.
Kinetic energy converted into heated water and rock is going to dissipate a *lot* of energy into phase transitions and the kinetic and heat energy of the ejecta, and the majority of the hot ejecta will almost immediately fall out of the atmosphere. Heating the atmosphere itself directly with gaseous byproducts of a huge mass of small ablating meteors would result in higher absolute temperatures as well as longer lived dust in the atmosphere.
A fragmented asteroid or comet would also likely fall over the entire surface of the Earth if the cloud of fragments was significant compared to the Earth's diameter, which would be likely if it was fragmented months or years before the impact. Atmospheric drag would take a lot of material around the sides of the earth and dump it on the far side of the original impact. The Earth would end up capturing a shitload of particles that would make a permanent cloud of space junk as well. Goodbye, human space endeavors.
"Please instruct the court stenographer to stop recording the audio in this courtroom, or else have him/her arrested for violating the very statute in question in this case."
Does it matter if audio is recorded by a pen on paper or by bits in flash memory? Is it only wiretapping if the physical waveform is recorded? I think the right lawyer could make a strong argument that it doesn't matter, or at least that the law as written is ambiguous.
There is already support for arbitrarily long certificate chains, and if all the CAs cooperated they could just sign an existing certificate chain with their own intermediate CA, the web site could tack that newest signature (along with any other necessary certificates in the chain) onto its existing chain and to an old SSL client it would just look like the newest CA was the ultimate source of trust, but the new version of SSL clients could verify that the web site's certificate has actually been signed by more than one locally trusted CA.
This particular workaround would probably not be the best solution; as far as I know it would require each root CA to sign every other company's root certificates as intermediate authorities. Perhaps by using a new set of root certificates that aren't trusted by old browsers it wouldn't be as big of a problem because only the top-level signer would use their traditional root CA key. New browsers would know about the new multi-chain root certificates and identify each of them in the chain. In the end, it would probably be better to just extend the TLS specification to send multiple certificate chains if the client requests them.
In short, we need a web of trust for X.509 certificates. PGP was right all along.
It requires some serious magical thinking to believe that not only will we reach that target, but that we'll be able to keep making them even smaller than that!
That only means the future technology has to be sufficiently advanced.
To only lose 3TB out of the 145TB implies that the metadata is stored redundantly across all storage devices and that the data is not striped. If the data is striped then the loss of one drive makes most of it useless. If metadata is not redundant across several drives then you could lose the drive storing metadata about data on other drives.
It's a cost vs. speed/simplicity trade-off to only replicate data. You have to buy 300% of raw storage for three full replicas, versus approximately 115% for RAID6 on 15 disks. For enclosure/server redundancy RAID6, or in general any (m,n) erasure code, can be used to aggregate enclosures with a small overhead for protecting data. The entire reason for designing erasure codes was to save time/space/money.
copy-on-write snapshots (fast, space-efficient), automatic resilvering (scanning the disks for bit errors and automatically correcting them), inline compression, extremely large file and filesystem support, and probably others.
It's not so much userspace vs. kernelspace but the number of context switches involved. There are fast instructions in most modern processors for moving from userland to the kernel and back again in protected mode. If you could have direct inter-process communication between userspace drivers and the processes that use them it wouldn't be such a big deal. But you need some trusted part of the operating system (typically the kernel) to mediate IPC, otherwise you have to fully trust both your driver and user processes. Memory mapped control and I/O channels partially eliminate this problem (e.g. direct rendering on video cards) but there's still the problem of passing signals (interrupts and requests) back and forth at high speed. x86 hardware could probably support a secure inter-procedure call system using call gates and a dedicated stack segment, but it would require quite a few changes in the way the OS, drivers, and userspace applications interacted.
Yes, it would be difficult to memorize a one time pad. One might as well memorize the plaintext itself and never write anything down. It was just a hypothetical argument.
Revealing a OTP for a specific ciphertext is meaningless because any possible plaintext decryption can be chosen by providing an appropriate OTP. There is no way to verify which OTP was used to create the original ciphertext.
Further, store the passphrase in the encrypted volume. Then even if you are only required to decrypt the data you can truthfully claim that doing so will reveal the passphrase itself.
Suppose that a defendant encrypted incriminating data using a one time pad, and memorized the one time pad. Forcing the defendant to reveal the one time pad would be meaningless. If a defendant memorizes a password with less entropy than the encrypted incriminating data it becomes possible to verify the accuracy of what the defendant has revealed. Finally consider the case where a defendant is in possession of a single bit of information; the answer to the question "Did you commit the crime of which you are accused?"
In both the first and third cases the fifth amendment protects the revelation of information by the defendant. Why should the second case be any different? Courts must always consider the effect of their actions and not merely the legal technicalities. In my mind there is little difference between coercing a defendant to pen his or her own confession (the equivalent of forcing a defendant to decrypt a OTP ciphertext), decrypt potentially incriminating data with a password, or directly admit guilt.
You might be underestimating the load facebook handles. Facebook routinely has tens of million of concurrent users, conceivably producing 100 million or more TPS at peak loads. Maybe the very latest hardware could handle that in a single database cluster, but I would bet that Facebook would still find it necessary to run separate databases for different types of data (users, posts, media, applications, ads, etc.) and use application nodes to glue it back together. At that point is it worth it to spend the $$$ on Oracle and big iron instead of making the application nodes do more work with an essentially free back end?
Slashdot Mirror
If we're going to hack a protocol (really? DNS? Why not just implement TLS over DNS while we're at it? Then captive portals will just block *everything*) we might as well hack SSL. I didn't say root CAs would have to be paid CAs. Any notary could be a CA just as easily, the *only* security difference is that there's now a variable level of trust that the user controls. In practical terms, a PKI infrastructure based on certificates is also more scalable. What happens when there are two billion sites (like Moxie hoped) that all need to be queried once a day by every notary? Who pays those bandwidth bills? Certificates also have a major advantage in that they can be signed securely, offline, by hardware if necessary, and then distributed by untrusted servers. Notaries will require the entire software stack to be trusted at all times.
There is one other aspect of notaries that is nice at first glance, and that's the fact that users are in control of which notaries they trust and site admins basically don't have to do anything. The subtle problem, of course, is that some server in China has no chance of getting its real certificate out to any notaries. The Great Firewall will MITM every single connection if the government so chooses. One might argue that this situation is unwinnable; if China never lets the real certificate through it's an effective denial of service attack. It would be better, however, to detect the DoS rather than lose completely to a MITM attack. If site owners are forced to register with CAs who they trust, the MITM attack is eliminated entirely.
If you can trust a CA-signed certificate for https://addons.mozilla.org/ why not one for https://citibank.com/ or https://mail.google.com?
Ultimately, if all the browsers start supporting notaries directly and ship with a list of major trusted notaries this won't be a problem. But bootstrapping a trust network to replace a presumably untrusted PKI while using that same PKI to validate the code you're using to replace it... It's sort of unfounded.
The sole benefit of convergence is the ability to trust individual entities less than 100% and require that more than one entity (notary in this case) vouches for the validity of an SSL certificate. The existing CA system would be vastly improved if this simple change was added so that every major root CA is only trusted in proportion to the ability of obtaining an invalid certificate, and multiple signatures would be required on each SSL certificate. This is almost exactly the same case as requiring multiple notaries to validate a certificate except that it retains the offline trust ability that is still necessary for captive portals and also allows sites to use as many SSL certificates as they want for their sites, so long as they get them signed by enough CAs. In the diginotar case, Mozilla could have just dropped the trust in the diginotar root certificate, potentially requiring some sites to acquire additional signatures from other CAs. The (huge) problem is that SSL does not support multiple chains of trust for a single certificate and every SSL stack in the world would have to be changed. Some hacks are probably possible to allow interoperability between new and old servers and clients. Ultimately, signatures are a much more robust cryptographic building block than mandatory online verification.
So in other words, the CA system works just fine as a complete root of trust.
This is what the network notary system (Perspectives / Convergence plugin) is for, take a look at it. When you visit a site, it compares the cert your browser receives with what other computers around the world are seeing at the same time.
From the perspectives project: Perspectives is a new approach to helping computers communicate securely on the Internet. With Perspectives, public “network notary” servers regularly monitor the SSL certificates used by 100,000s+ websites to help your browser detect “man-in-the-middle” attacks without relying on certificate authorities.
There are a few problems: network notaries can be selectively denied by an attacker. Will browsers complain that only a fraction of the selected notaries were able to be queried before connecting? Network notaries will be just as vulnerable to attack as root CAs (if not moreso; many will likely run on consumer hardware with private keys laying in RAM instead of a secure addon crypto processor); change the list of certificates that the network notary stores and it will validate an attacker's MITM certificate. Steal a network notary's private key and simply impersonate them. If a notarized site has its DNS spoofed to point to an attacker's site for long enough (and they can simply replay traffic so everything looks normal), the attacker's MITM certificate may be accepted as a valid change of certificate. Attackers can spoof the major sites to the notaries by sending the MITM certificates only to known notaries so as not to alert users with browser certificate checking turned on. Notaries will be of no value within closed networks whereas existing CA architectures allow trust to be calculated between peers who trust an offline third party.
Individual notaries are just as vulnerable to legal (or criminal) intervention as root CAs are today. China and other repressive regimes will almost certainly block access to notaries if it serves their purposes, or enforce usage of state-controlled notaries. Notaries won't scale to billions of sites unless they are very large. Who pays their bandwidth bills? CAs pay their bills by charging for validation. In short, the only way to fix the SSL certificate trust problem on the Internet is to use the PGP web of trust model to assign limited trust to many entities and calculate cumulative trust from distinct signatures of a particular SSL certificate by many semi-trusted entities. This can be accomplished with CAs, notaries, individuals, or a mix of all three. Signatures are far more bandwidth and computationally efficient than realtime queries and attestations and they can be computed offline to keep private key material as secure as possible.
The only advantage of notaries that I can see is that certificate revocation becomes automatic and much more timely. Still, realtime CRL checks serve the same purpose.
No one can "steal" your existing certificate unless they also steal your web server's private key. A CA can issue a fraudulent certificate for your site, but anyone can generate a self-signed certificate for your site as well. How does a CA make MITM attacks more likely? How many users visit your web site for the first time on an untrusted wireless network or in a country where the government may want to feed them a fake certificate anyway? Propagation and widespread trust of self-signed certs is what would actually cause a rise in the number of MITM attacks. This story is about known bad certificates that everyone can avoid by removing a single root CA from their browser. I haven't heard of any reported MITM attacks resulting from the bad certificates, although I wouldn't be surprised if some occurred. In a world of self-signed certificates there isn't even a way to begin to detect MITM attacks (much less stop them) unless you watch every connection between every client and web server and keep track of every possible certificate ever generated and its use history. Did your favorite web site just change its self-signed certificate because they lost the private key due to hardware failure, because it expired, or some other legitimate reason? Or is this a MITM attack?
Just as an example, I am "lucky" enough to own one of the Via Unichrome devices that's losing support. It had iffy support to begin with because Via released an old open source driver with no documentation and it was up to volunteers to keep it running as Xorg changed. Comments in the code included things like "Rewrite this so that it actually uses screens and GL contexts in the appropriate way" because the original Via programmers did things strangely. I had to write a couple horrible hacks to detect double-free corruption using magic values to keep KDE from crashing on startup. I was hoping I could learn enough to rewrite the driver properly to use it on my old laptop, but I imagine now it will just keep the hacky, mostly-working code that it has right now. Given the existence of unfixed bugs in ancient code that doesn't even use the Xorg/Mesa APIs right, it's probably the right decision to drop it.
The best part is that if anyone cares to fix it, they can just update the code and submit it back into Xorg and everything will be happy again. If I ever get stuck on a desert island with that laptop and a solar panel, I'll submit a patch when I get back.
An API is just a list of function prototypes and the type definitions they depend on. The only reason function names are required is that so far there isn't a general semantic langauge that specifies (simply, and with clarity) the preconditions and postconditions of the functions, so the linker needs a way to bind calls to the appropriate functions instead of just pattern matching based on formal semantics.
..." is your idea of copyrightable content, then I have some very boring novels to sell you.
If "type_1 function_name_1(type_2, type_3, type_4, type_5)
Both OSS and FSF licenses are necessary and are balanced by the state of the software industry. In a wide-open industry OSS does fine and software vendors can safely write and use OSS. When even a few (large/important/influential) companies start to play badly with others, close their source, and embrace and extend the standards, the demand for FSF software increases.
Presumably we are now seeing a high demand for purely open standards and software. This is enabled primarily by the wide availability of open standards and software that already exist. People seem to forget that just 20 years ago there were no widely available free operating systems, free compilers, or free application frameworks. Today there are hundreds of major examples, even from traditionally closed-source vendors. That will change in the future, as it has in the past. Then the FSF will again be able to fulfill the demand for community-centered software that prevents individuals in the industry from controlling too large a portion of the market to the detriment of others.
In short, OSS works wonderfully on a level playing field. Free Software can level any existing playing field.
Kinetic energy converted into heated water and rock is going to dissipate a *lot* of energy into phase transitions and the kinetic and heat energy of the ejecta, and the majority of the hot ejecta will almost immediately fall out of the atmosphere. Heating the atmosphere itself directly with gaseous byproducts of a huge mass of small ablating meteors would result in higher absolute temperatures as well as longer lived dust in the atmosphere. A fragmented asteroid or comet would also likely fall over the entire surface of the Earth if the cloud of fragments was significant compared to the Earth's diameter, which would be likely if it was fragmented months or years before the impact. Atmospheric drag would take a lot of material around the sides of the earth and dump it on the far side of the original impact. The Earth would end up capturing a shitload of particles that would make a permanent cloud of space junk as well. Goodbye, human space endeavors.
"Please instruct the court stenographer to stop recording the audio in this courtroom, or else have him/her arrested for violating the very statute in question in this case."
Does it matter if audio is recorded by a pen on paper or by bits in flash memory? Is it only wiretapping if the physical waveform is recorded? I think the right lawyer could make a strong argument that it doesn't matter, or at least that the law as written is ambiguous.
There is already support for arbitrarily long certificate chains, and if all the CAs cooperated they could just sign an existing certificate chain with their own intermediate CA, the web site could tack that newest signature (along with any other necessary certificates in the chain) onto its existing chain and to an old SSL client it would just look like the newest CA was the ultimate source of trust, but the new version of SSL clients could verify that the web site's certificate has actually been signed by more than one locally trusted CA.
This particular workaround would probably not be the best solution; as far as I know it would require each root CA to sign every other company's root certificates as intermediate authorities. Perhaps by using a new set of root certificates that aren't trusted by old browsers it wouldn't be as big of a problem because only the top-level signer would use their traditional root CA key. New browsers would know about the new multi-chain root certificates and identify each of them in the chain. In the end, it would probably be better to just extend the TLS specification to send multiple certificate chains if the client requests them.
In short, we need a web of trust for X.509 certificates. PGP was right all along.
It requires some serious magical thinking to believe that not only will we reach that target, but that we'll be able to keep making them even smaller than that!
That only means the future technology has to be sufficiently advanced.
A spokesman from Level3 was quoted as saying "AT&T just uses such a tremendous amount of the world's Internet bandwidth. What else could we do?"
On a von-Neuman machine instructions *are* data, and vice versa.
Sandbox everything.
Hacksaw? Wouldn't any car thief worth their salt use a dremel or other battery operated cutting tool by now?
To only lose 3TB out of the 145TB implies that the metadata is stored redundantly across all storage devices and that the data is not striped. If the data is striped then the loss of one drive makes most of it useless. If metadata is not redundant across several drives then you could lose the drive storing metadata about data on other drives.
It's a cost vs. speed/simplicity trade-off to only replicate data. You have to buy 300% of raw storage for three full replicas, versus approximately 115% for RAID6 on 15 disks. For enclosure/server redundancy RAID6, or in general any (m,n) erasure code, can be used to aggregate enclosures with a small overhead for protecting data. The entire reason for designing erasure codes was to save time/space/money.
copy-on-write snapshots (fast, space-efficient), automatic resilvering (scanning the disks for bit errors and automatically correcting them), inline compression, extremely large file and filesystem support, and probably others.
Having to replicate 145 TB over the network just because one disk failed is kind of pointless. RAID6 will just rebuild the failed disk locally.
It's not so much userspace vs. kernelspace but the number of context switches involved. There are fast instructions in most modern processors for moving from userland to the kernel and back again in protected mode. If you could have direct inter-process communication between userspace drivers and the processes that use them it wouldn't be such a big deal. But you need some trusted part of the operating system (typically the kernel) to mediate IPC, otherwise you have to fully trust both your driver and user processes. Memory mapped control and I/O channels partially eliminate this problem (e.g. direct rendering on video cards) but there's still the problem of passing signals (interrupts and requests) back and forth at high speed. x86 hardware could probably support a secure inter-procedure call system using call gates and a dedicated stack segment, but it would require quite a few changes in the way the OS, drivers, and userspace applications interacted.
Ever. It's unpossible.
Yes, it would be difficult to memorize a one time pad. One might as well memorize the plaintext itself and never write anything down. It was just a hypothetical argument.
Revealing a OTP for a specific ciphertext is meaningless because any possible plaintext decryption can be chosen by providing an appropriate OTP. There is no way to verify which OTP was used to create the original ciphertext.
Further, store the passphrase in the encrypted volume. Then even if you are only required to decrypt the data you can truthfully claim that doing so will reveal the passphrase itself.
Suppose that a defendant encrypted incriminating data using a one time pad, and memorized the one time pad. Forcing the defendant to reveal the one time pad would be meaningless. If a defendant memorizes a password with less entropy than the encrypted incriminating data it becomes possible to verify the accuracy of what the defendant has revealed. Finally consider the case where a defendant is in possession of a single bit of information; the answer to the question "Did you commit the crime of which you are accused?"
In both the first and third cases the fifth amendment protects the revelation of information by the defendant. Why should the second case be any different? Courts must always consider the effect of their actions and not merely the legal technicalities. In my mind there is little difference between coercing a defendant to pen his or her own confession (the equivalent of forcing a defendant to decrypt a OTP ciphertext), decrypt potentially incriminating data with a password, or directly admit guilt.
You might be underestimating the load facebook handles. Facebook routinely has tens of million of concurrent users, conceivably producing 100 million or more TPS at peak loads. Maybe the very latest hardware could handle that in a single database cluster, but I would bet that Facebook would still find it necessary to run separate databases for different types of data (users, posts, media, applications, ads, etc.) and use application nodes to glue it back together. At that point is it worth it to spend the $$$ on Oracle and big iron instead of making the application nodes do more work with an essentially free back end?