I don't see how this [acceping BC from customers] is much different than using fiat [currency to accept payment from customers].
It's one more thing to add on top of your existing tax computations. Most small businesses aren't specifically set up to account for profits and losses specifically tied to currency fluctuations or to short-term commodities trading.
It's true that if you have good software that has this built in, then the cost may be nearly zero. But if you are running a small business on the side, say, selling handmade quilts at trade shows, then you may need to invest some time to learn how to account for the BC-to-local-currency transation on your own books and how to properly declare it - as a currency transation or as a commodities transaction - when you do your taxes. That time, energy, and expense is overhead - overhead that can be avoided by sticking with local-currency-only transactions.
Like fiat currencies and for that matter the value of metals beyond their utilitarian value (industry, jewelry, etc.), BC is still a "faith currency."
Its value rises and falls not just with supply and demand but with people's faith their ability to spend it in the future for the same goods as they can today. Or, to put it another way, people's faith influences demand. If I can buy one widget for one BC today, but I believe that next year I will be able to buy 2 widgets (that is, if I have faith that the value will go up over time/that BC will experience deflation), I may be willing to pay more for BC than if I believe I will only be able to buy 1 widget with that BC next year, assuming that I believe that the local currency will buy the same amount of widgets a year from now as next year. If I believe that BC will suffer inflation (unlikely, given its model - but I may still believe it) then will be willing to spend less on BC than if I believed its value was stable. Either that, or I will plan on spending it soon, before I think the value will drop. Ditto if I believe it is in a bubble relative to the local currency (like precious mentals and fiat currencies, BC will occaisionally be in a "bubble" relative to any given metal or currency, and it will occasionally be in a "buying opportunity" - but only history will tell you what is a bubble or buying opportunity and what is the "new normal").
Like currency stored in a bank account, BC has no "intrinsic value." Even bank notes have a non-zero intrinsic value: You can use them as wallpaper or burn them as fuel. Coins typically have slightly higher intrinsic value thanks to the industrial uses of their metal content. While I wouldn't call in "intrinsic" the selling price of gold is very unlikely to drop below half of its current value relative to a "market basket" of other commodities (natural textiles, foods, fossile fuels, etc.) in my lifetime, if only because I don't see any significant letup in demand for its "artistic uses" (jewelry, collectable coins, etc.) during that time. But in 500 years or 5000 years, its price may drop to its value to industry, whatever that is at the time. Without significant intrinsic value, any currency is, at its core, a "faith currency."
If it's government backed, why do you need the blockchain?
If you are suggesting the use of government-backed fiat currency - as in paper/cloth/plastic bills not entries in a bank ledger - then the advantage is theft resistance. Not only will someone have to steal your ewallet but they will either have to steal it when you have it opened, or steal its password too.
If you are suggesting a bank account, well, I've already outlined the advantages that a blockchain has over a bank account. The most obvious one is that a wallet can be passed around anonymously, without any record at all (no blockchain entry except by the final recipient). In that way, it's much like a check made out to "cash" or a pre-paid debit-card/"gift card" except that it's typically got a password on it.
Wasn't the point of the blockchain the decentralization?
It may have been the original purpose, but it is not the only advantage it has over either cash or bank-book-entry ledger systems like credit cards.
It's expensive to receive a credit card transaction. It's a bare minimum of $20.00/mth plus transaction fees of $0.25 + a percentage (1.5% - 3.5% depending on the card).
There are several credit-card-processing options that don't include a monthly fee, at least in the USA. Square and PayPal just to name two.
Granted, there is still the per-transaction fee and the percentage-cost, which are much higher than BC. But if it is domestic there is no currency-exchange cost or currency-fluctuation risk. Unless you are converting your BC to local currency almost immediately, there is inherent currency-fluctuation risk (and profit potential) on the part of the merchant. Depending on your jurisdiction, using BC may also force you to do additonal tax paperwork that comes with the "profit and loss" on the BC-to-local-currency exchanges. That's overhead that's avoided if you skip BC and use a credit card or other local-currency option.
It's said that coins and currency have intrinsic value, trade value, and collectable value.
Book-entry money, including bank accounts and e-coins, typically has only trade value.
A typical, non-collectable $1 bill will have an intrinsic value of a few cents or less - it can be used as wallpaper if nothing else. It has a trade value of exactly $1. Unless and until it becomes collectable, it's collectable value is less than its face value and can be ignored.
A de-monetized bank note from the Confederate States of America probably has less intrinsic value per square inch than a modern bill and it has zero trade value, but it probably has significant collectable value.
Metal coins are similar, except that they typically have higher intrinsic value than paper/cloth/plastic currency. "Back in the old days" the intrinsic value of a coin was pretty close to the trade/"face" value. That is still true for the US penny and nickle - as metal, each is worth over 60% of the trade/"face" value. The dime, quarter, and half dollar, on the other hand, are worth less than 20% of face value.
For people who hold BC for more than a short time, it's gambling.
For people who need to buy from someone and they don't have a currency the seller will accept, they must buy a currency the seller will accept. If the seller accepts US Dollars and BitCoin, and all I have are Euros, am I going to buy USD or am I going to buy BitCoin? Well, if they take my credit card (with its low exchange fees) I may "buy" USD. If they don't, I'll buy BC, buy elsewhere, or do without. For this buyer, it's being used as a currency.
If I'm a merchant that is accepting BC to attract more customers, AND I convert that BC to local currency within a short time, then I'm also using it as a currency, just as if I accepted Euros but sold them for the local currency within hours of receiving them.
I'm still waiting for a government or national-bank to issue blockchain-based currency that is backed by a familiar, tangible asset such as gold, silver, or the local fiat currency.
Unlike bitcoin, this would be a "captive" coin and it would not have many of the benefits of bitcoin and the like.
But here is what it would have:
* Stable value: Like currency or metal, a "bit-buck" is worth $1 and it always will be and a "bit-troy-ounce of gold" is worth 1 troy ounce of gold and it always will be. * Built-in: In most industrialized countries, most people trust the national bank and the government when it comes to currency issues. I'm not saying they should, only that they typically do. * Like bitcoin, you can trade with it without having a bank account or having to carry cash. * You can trade "whole wallets" many times in a way that is free of any record-keeping except by the final recipient, who will want to transfer the money to his own wallet and at the same time verify that the wallet he received is legit. * It's a backdoor to increased use of BitCoin etc.: It would encourage people to install software that make using it easy. Presumably, this software would also work with BitCoin and other non-backed coins, so their use will also presumably increase. * As "Novelty use local currency" it can boost local pride. Think "college campus bucks" or "state fair dollars."
There is one major disadvantage: To work right, there must be excess dollars or gold or whatever to cover newly-mined coins, or the coins must be "pre-mined" which means someone will have to cover the transaction costs. To be acceptable to the general public, there must not be any transaction fees. This means that in practice, the state or bank holding the reserves will need to pay the transaction fees or be constanty adding to the "backing reserve" until the coin is fully mined.
Yes, I know there are strong arguments why backing the blockchain with assets helps rather than hurts, but for applications where you need stability, it's a big win.
This would allow non-encrypted Google searches and non-encrypted CDN traffic. Since most users in those countries know their government is spying on them, er, I mean protecting them from bad stuff on the Internet, this shouldn't cause too much domestic political blowback.
Face it, if you are in a country with draconian censorship or government monitoring - like North Korea and possiby China - you'll need to use stegonography to hide the fact that you are even encrypting things. Furthermore, if you need to "encrypt and hide" more than a relatively small amount of data, you'll have to use a technique that is "custom made" or at least a "custom variation" of well-known formats to avoid detection. I'm not saying the people in Egypt are in this situation now, but people in some parts of the world are.
That's what has enabled the modern spy infrastructure
Not just the modern spy infrastructure, but most "spy infrastructures" throughout history.
Fear: Either on the part of the public, demanding the government protect them (e.g. 1933 Germany, 2001 USA), or on the part of a tyrannical regime, to protect them from rebellion (e.g. Communist Eastern Europe excluding Russia, Japan-occupied China and Korea in the decades before 1945, the occupied parts of the Confederacy during the last parts of the American Civil War and former Confederate states in the years after that war).
How does it handle counterfeit or lost messages? Not so well, I bet. Why would I want to spend more time securely obtaining one time pads than actually communicating?
I think it would work like this:
You go to your bank to open an account. While you are filling out paperwork and supplying a thumb-print (thank you 9/11 terrorist - NOT!) the bank generates a very long one-time pad that should provide enough coverage for several year's worth of communications. They keep a copy and they give you a copy. The pad is probably signed with the bank's public key so you know it is really from the bank.
To detect lost messages, every communication will include either an index into the one-time pad (in cleartext or encrypted with some other method) or a pre-determined "synchronization phrase" encrypted with the pad. If it includes the index, then the problem is solved. If it includes a "synchronization phrase" then you start with where the pad left off. If it doesn't match, then you read forward in the pad until it matches, and you know you probably lost a message somewhere along the line.
Also, the pad may be, in effect, two pads: one for sending, one for receiving. This is easly accomplished by having one party start at the beginning of the pad working forwards and the other party start at the end working backwards.
Also, to avoid pad exhaustion, the pad would probably be used to generate temporary/ephemeral symmetric keys and for some other things like the initial setup of the communication. The actual "meat" of the communication would be encrypted with the ephemeral, symmetric keys.
there is going to be lag between when Quantum Computers can decrypt classical based algorithms and when Quantum Cryptography can be used. They must think it's long enough to find more robust classical algorithms. Probably not going to help
The two concepts are related but not identical.
Practical quantum cryptography means sending quantum messages over long distances - anything less than halfway across the world leaves room for improvement - while quantum computing, which includes fast description of classical encryption algorithms - is typically done in one location.
I expect well-funded parties will be able to routinely decript 512-bit-and-smaller factor-based algorithms in a reasonable amount of time (less than a year) and cost (less than $100,000 per decryption effort) well before we see routine quantum cryptography between locations that are halfway around the world from each other.
P.S.: For all we know, the government spooks in America, England, Israel, China, North Korea, and possibly other countries can already do this. I have no evidence to support this theory, but I do expect that we won't hear about it until at least a year or two after they do have it.
Sending in an online application to a graduate school a thousand miles away, not so much.
Okay, I take that back: Physical "in person" key exchange could be done if you did your key exchange "in person" with agents acting on the other party's behalf, with the key sealed in a tamper-evident packaging and optionally encrypted with your public key. Oh way, scratch that optional part, or we will be reasoning in circles.
Besides, one-time pads can be compromised.
I do agree that a combination of one-time pads and public-key encryption - with the pads being encrypted with short-lived public keys - are preferred for some uses, such as setting up a bank account in person, than the current system.
Decades ago some cities had houses with 2 electric meters.
One fed the hot water heater (the kind with a tank) but the power company would turn off the electricity for, say, 15 minutes at a time on a "rolling" basis during peak usage. In exchange, the "hot water heater" electricity rate was lower than the regular rate.
Since hot water stays hot for a long time, you wouldn't notice it unless everyone in your house was taking a long shower at the same time the power was cut.
Oh, and since this was decades ago, it was in a time when the power grid was managed almost completely by "analog" devices, including "analog computers."
Granted, if it's closed-source you have to trust the library vendor. If it's open-source, you either have to do due dilligence or trust someone else who claims to have done so.
I assume we are talking about re-using source code, linking with staticly-linked libraries, and using and "private copies" of shared libraries binaries (e.g./usr/local/bin/applicationname/lib/lib1.so or C:\Program Files\Application\DLLs\MyDll.dll). With "public" shared binaries (/usr/lib/sharedlib.so or C:\Windows\...\MSDLL.DLL), you are relying on the library or OS vendor to keep things patched.
Here's an example:
I know of a popular product that uses its own private copy of Java. If the vendor doesn't update their customer's versions of Java on a regular basis, an attacker can exploit it, even if the user is updating the "Oracle" version of Java on a regular basis. That's bad. On the other hand, they would probably be in a worse of a position of the vendor re-wrote the functionality of Java in-house, as that code would have its own set of bugs and it would likely NOT be as maintined as Java is. The solution is to use the "Oracle" version of Java instead of a private copy, OR push out updates to the private copy within a day or two of Oracle pushing out their updates.
I love when people think ISPs will willingly deny themselves money for altruistic reasons,
Or lawsuit-prevention reasons.
How soon before someone successfully sues an ISP for failing to cut off someone once they are notified their customer has a bot or other malicious machine on his LAN?
It's time for consumer firewalls to be "block all by default" in all directions, not just WAN-to-LAN.
If you want to allow your thermostat to talk to a specific external host then punch a very narrow hole in the firewall to allow it.
Heck, I would go so far as to put everything on the LAN side in its own DMZ. If you want your PC to talk to your media player, punch a specific hole in the firewall.
This will require industry cooperation: * Protocols will have to be developed so "punching holes in firewalls" becomes super-easy for the consumer * ISPs will have to start telling customers "if bad things come out of your network, we WILL cut you off. If you use one of these new routers, it's much less likely that bad things will come out of your network."
? It can say "Hey, I'm three inches behind you and ten to the right" without saying who you are.
I don't see how it can be hack-proof and anonymous at the same time.
To reject bogus messages, you need to know: * That the person sending the message is "vouched for" somehow * That the "vouching" hasn't been revoked
The most obvious way is for each car to "sign" its message, and have each car's "signing key" be counter-signed by the manufacturer or other trusted entity. Copies and counterfiets can be "revoked" as needed.
While such a system isn't foolproof, it's less game-able than an anonymous system that says "hi, I'm a car, and I'm 3 inches behind you to the right" without any way to verify that data.
About the only way "anonymous" communication would work would be if each car took incoming messages as "advisory/double-check it or ask the driver to check it" and not "as fact."
Slashdot Mirror
How soon before China infects the firmware without Tesla even being aware of it?
I don't see how this [acceping BC from customers] is much different than using fiat [currency to accept payment from customers].
It's one more thing to add on top of your existing tax computations. Most small businesses aren't specifically set up to account for profits and losses specifically tied to currency fluctuations or to short-term commodities trading.
It's true that if you have good software that has this built in, then the cost may be nearly zero. But if you are running a small business on the side, say, selling handmade quilts at trade shows, then you may need to invest some time to learn how to account for the BC-to-local-currency transation on your own books and how to properly declare it - as a currency transation or as a commodities transaction - when you do your taxes. That time, energy, and expense is overhead - overhead that can be avoided by sticking with local-currency-only transactions.
Like fiat currencies and for that matter the value of metals beyond their utilitarian value (industry, jewelry, etc.), BC is still a "faith currency."
Its value rises and falls not just with supply and demand but with people's faith their ability to spend it in the future for the same goods as they can today. Or, to put it another way, people's faith influences demand. If I can buy one widget for one BC today, but I believe that next year I will be able to buy 2 widgets (that is, if I have faith that the value will go up over time/that BC will experience deflation), I may be willing to pay more for BC than if I believe I will only be able to buy 1 widget with that BC next year, assuming that I believe that the local currency will buy the same amount of widgets a year from now as next year. If I believe that BC will suffer inflation (unlikely, given its model - but I may still believe it) then will be willing to spend less on BC than if I believed its value was stable. Either that, or I will plan on spending it soon, before I think the value will drop. Ditto if I believe it is in a bubble relative to the local currency (like precious mentals and fiat currencies, BC will occaisionally be in a "bubble" relative to any given metal or currency, and it will occasionally be in a "buying opportunity" - but only history will tell you what is a bubble or buying opportunity and what is the "new normal").
Like currency stored in a bank account, BC has no "intrinsic value." Even bank notes have a non-zero intrinsic value: You can use them as wallpaper or burn them as fuel. Coins typically have slightly higher intrinsic value thanks to the industrial uses of their metal content. While I wouldn't call in "intrinsic" the selling price of gold is very unlikely to drop below half of its current value relative to a "market basket" of other commodities (natural textiles, foods, fossile fuels, etc.) in my lifetime, if only because I don't see any significant letup in demand for its "artistic uses" (jewelry, collectable coins, etc.) during that time. But in 500 years or 5000 years, its price may drop to its value to industry, whatever that is at the time. Without significant intrinsic value, any currency is, at its core, a "faith currency."
If it's government backed, why do you need the blockchain?
If you are suggesting the use of government-backed fiat currency - as in paper/cloth/plastic bills not entries in a bank ledger - then the advantage is theft resistance. Not only will someone have to steal your ewallet but they will either have to steal it when you have it opened, or steal its password too.
If you are suggesting a bank account, well, I've already outlined the advantages that a blockchain has over a bank account. The most obvious one is that a wallet can be passed around anonymously, without any record at all (no blockchain entry except by the final recipient). In that way, it's much like a check made out to "cash" or a pre-paid debit-card/"gift card" except that it's typically got a password on it.
Wasn't the point of the blockchain the decentralization?
It may have been the original purpose, but it is not the only advantage it has over either cash or bank-book-entry ledger systems like credit cards.
It's expensive to receive a credit card transaction. It's a bare minimum of $20.00 /mth plus transaction fees of $0.25 + a percentage (1.5% - 3.5% depending on the card).
There are several credit-card-processing options that don't include a monthly fee, at least in the USA. Square and PayPal just to name two.
Granted, there is still the per-transaction fee and the percentage-cost, which are much higher than BC. But if it is domestic there is no currency-exchange cost or currency-fluctuation risk. Unless you are converting your BC to local currency almost immediately, there is inherent currency-fluctuation risk (and profit potential) on the part of the merchant. Depending on your jurisdiction, using BC may also force you to do additonal tax paperwork that comes with the "profit and loss" on the BC-to-local-currency exchanges. That's overhead that's avoided if you skip BC and use a credit card or other local-currency option.
For people who hold BC for more than a short time, it's gambling.
As someone who bought $300 in bitcoin back when it was $0.50 a coin and is still holding on to half of it. I disagree with your statement.
It's still gambling, much in the same way investing in a single, highly-volatile stock is gambling.
You may win in the long haul or you may lose your shirt.
You happened to win. You may have even approached it as an investment. That doesn't mean it wasn't a gamble.
It's said that coins and currency have intrinsic value, trade value, and collectable value.
Book-entry money, including bank accounts and e-coins, typically has only trade value.
A typical, non-collectable $1 bill will have an intrinsic value of a few cents or less - it can be used as wallpaper if nothing else. It has a trade value of exactly $1. Unless and until it becomes collectable, it's collectable value is less than its face value and can be ignored.
A de-monetized bank note from the Confederate States of America probably has less intrinsic value per square inch than a modern bill and it has zero trade value, but it probably has significant collectable value.
Metal coins are similar, except that they typically have higher intrinsic value than paper/cloth/plastic currency. "Back in the old days" the intrinsic value of a coin was pretty close to the trade/"face" value. That is still true for the US penny and nickle - as metal, each is worth over 60% of the trade/"face" value. The dime, quarter, and half dollar, on the other hand, are worth less than 20% of face value.
For people who hold BC for more than a short time, it's gambling.
For people who need to buy from someone and they don't have a currency the seller will accept, they must buy a currency the seller will accept. If the seller accepts US Dollars and BitCoin, and all I have are Euros, am I going to buy USD or am I going to buy BitCoin? Well, if they take my credit card (with its low exchange fees) I may "buy" USD. If they don't, I'll buy BC, buy elsewhere, or do without. For this buyer, it's being used as a currency.
If I'm a merchant that is accepting BC to attract more customers, AND I convert that BC to local currency within a short time, then I'm also using it as a currency, just as if I accepted Euros but sold them for the local currency within hours of receiving them.
I'm still waiting for a government or national-bank to issue blockchain-based currency that is backed by a familiar, tangible asset such as gold, silver, or the local fiat currency.
Unlike bitcoin, this would be a "captive" coin and it would not have many of the benefits of bitcoin and the like.
But here is what it would have:
* Stable value: Like currency or metal, a "bit-buck" is worth $1 and it always will be and a "bit-troy-ounce of gold" is worth 1 troy ounce of gold and it always will be.
* Built-in: In most industrialized countries, most people trust the national bank and the government when it comes to currency issues. I'm not saying they should, only that they typically do.
* Like bitcoin, you can trade with it without having a bank account or having to carry cash.
* You can trade "whole wallets" many times in a way that is free of any record-keeping except by the final recipient, who will want to transfer the money to his own wallet and at the same time verify that the wallet he received is legit.
* It's a backdoor to increased use of BitCoin etc.: It would encourage people to install software that make using it easy. Presumably, this software would also work with BitCoin and other non-backed coins, so their use will also presumably increase.
* As "Novelty use local currency" it can boost local pride. Think "college campus bucks" or "state fair dollars."
There is one major disadvantage:
To work right, there must be excess dollars or gold or whatever to cover newly-mined coins, or the coins must be "pre-mined" which means someone will have to cover the transaction costs. To be acceptable to the general public, there must not be any transaction fees. This means that in practice, the state or bank holding the reserves will need to pay the transaction fees or be constanty adding to the "backing reserve" until the coin is fully mined.
Yes, I know there are strong arguments why backing the blockchain with assets helps rather than hurts, but for applications where you need stability, it's a big win.
Egypt and other countries that want to block Signal will now have to start blocking https://.google.com/ and https://.cnd_domain_here/ real soon now.
This would allow non-encrypted Google searches and non-encrypted CDN traffic. Since most users in those countries know their government is spying on them, er, I mean protecting them from bad stuff on the Internet, this shouldn't cause too much domestic political blowback.
Face it, if you are in a country with draconian censorship or government monitoring - like North Korea and possiby China - you'll need to use stegonography to hide the fact that you are even encrypting things. Furthermore, if you need to "encrypt and hide" more than a relatively small amount of data, you'll have to use a technique that is "custom made" or at least a "custom variation" of well-known formats to avoid detection. I'm not saying the people in Egypt are in this situation now, but people in some parts of the world are.
That's what has enabled the modern spy infrastructure
Not just the modern spy infrastructure, but most "spy infrastructures" throughout history.
Fear: Either on the part of the public, demanding the government protect them (e.g. 1933 Germany, 2001 USA), or on the part of a tyrannical regime, to protect them from rebellion (e.g. Communist Eastern Europe excluding Russia, Japan-occupied China and Korea in the decades before 1945, the occupied parts of the Confederacy during the last parts of the American Civil War and former Confederate states in the years after that war).
[drivel] Harold [more drivel]
Okay, you didn't have to tell remind us that Prime Minister Harold Saxon was bat-guano looney-toons insane, the whole universe knew that already.
They are the sheeps in the wolves clothing here.
I think the NSA re-worded your message for you. Did you mean carnivors dressing up as herbivors by any chance?
How does it handle counterfeit or lost messages? Not so well, I bet. Why would I want to spend more time securely obtaining one time pads than actually communicating?
I think it would work like this:
You go to your bank to open an account. While you are filling out paperwork and supplying a thumb-print (thank you 9/11 terrorist - NOT!) the bank generates a very long one-time pad that should provide enough coverage for several year's worth of communications. They keep a copy and they give you a copy. The pad is probably signed with the bank's public key so you know it is really from the bank.
To detect lost messages, every communication will include either an index into the one-time pad (in cleartext or encrypted with some other method) or a pre-determined "synchronization phrase" encrypted with the pad. If it includes the index, then the problem is solved. If it includes a "synchronization phrase" then you start with where the pad left off. If it doesn't match, then you read forward in the pad until it matches, and you know you probably lost a message somewhere along the line.
Also, the pad may be, in effect, two pads: one for sending, one for receiving. This is easly accomplished by having one party start at the beginning of the pad working forwards and the other party start at the end working backwards.
Also, to avoid pad exhaustion, the pad would probably be used to generate temporary/ephemeral symmetric keys and for some other things like the initial setup of the communication. The actual "meat" of the communication would be encrypted with the ephemeral, symmetric keys.
there is going to be lag between when Quantum Computers can decrypt classical based algorithms and when Quantum Cryptography can be used. They must think it's long enough to find more robust classical algorithms. Probably not going to help
The two concepts are related but not identical.
Practical quantum cryptography means sending quantum messages over long distances - anything less than halfway across the world leaves room for improvement - while quantum computing, which includes fast description of classical encryption algorithms - is typically done in one location.
I expect well-funded parties will be able to routinely decript 512-bit-and-smaller factor-based algorithms in a reasonable amount of time (less than a year) and cost (less than $100,000 per decryption effort) well before we see routine quantum cryptography between locations that are halfway around the world from each other.
P.S.: For all we know, the government spooks in America, England, Israel, China, North Korea, and possibly other countries can already do this. I have no evidence to support this theory, but I do expect that we won't hear about it until at least a year or two after they do have it.
Banking with your local bank branch, fine.
Sending in an online application to a graduate school a thousand miles away, not so much.
Okay, I take that back: Physical "in person" key exchange could be done if you did your key exchange "in person" with agents acting on the other party's behalf, with the key sealed in a tamper-evident packaging and optionally encrypted with your public key. Oh way, scratch that optional part, or we will be reasoning in circles.
Besides, one-time pads can be compromised.
I do agree that a combination of one-time pads and public-key encryption - with the pads being encrypted with short-lived public keys - are preferred for some uses, such as setting up a bank account in person, than the current system.
An anonymous reader writes:
So, you wrote it?
I thought it was a joke, but no, it had to be real.
What does Google know that the rest of us don't???
Nyquil and tequila are a wicked mix.
I thought they were the same thing, except for the worm.
Decades ago some cities had houses with 2 electric meters.
One fed the hot water heater (the kind with a tank) but the power company would turn off the electricity for, say, 15 minutes at a time on a "rolling" basis during peak usage. In exchange, the "hot water heater" electricity rate was lower than the regular rate.
Since hot water stays hot for a long time, you wouldn't notice it unless everyone in your house was taking a long shower at the same time the power was cut.
Oh, and since this was decades ago, it was in a time when the power grid was managed almost completely by "analog" devices, including "analog computers."
Granted, if it's closed-source you have to trust the library vendor. If it's open-source, you either have to do due dilligence or trust someone else who claims to have done so.
I assume we are talking about re-using source code, linking with staticly-linked libraries, and using and "private copies" of shared libraries binaries (e.g. /usr/local/bin/applicationname/lib/lib1.so or C:\Program Files\Application\DLLs\MyDll.dll). With "public" shared binaries (/usr/lib/sharedlib.so or C:\Windows\...\MSDLL.DLL), you are relying on the library or OS vendor to keep things patched.
Here's an example:
I know of a popular product that uses its own private copy of Java. If the vendor doesn't update their customer's versions of Java on a regular basis, an attacker can exploit it, even if the user is updating the "Oracle" version of Java on a regular basis. That's bad. On the other hand, they would probably be in a worse of a position of the vendor re-wrote the functionality of Java in-house, as that code would have its own set of bugs and it would likely NOT be as maintined as Java is. The solution is to use the "Oracle" version of Java instead of a private copy, OR push out updates to the private copy within a day or two of Oracle pushing out their updates.
I love when people think ISPs will willingly deny themselves money for altruistic reasons,
Or lawsuit-prevention reasons.
How soon before someone successfully sues an ISP for failing to cut off someone once they are notified their customer has a bot or other malicious machine on his LAN?
Force all their internet through a proxy that routes everything to goatse for the next 20 years to life.
I can almost hear them screaming:
"My eyes, they burn, kill me now, please kill me now."
It's time for consumer firewalls to be "block all by default" in all directions, not just WAN-to-LAN.
If you want to allow your thermostat to talk to a specific external host then punch a very narrow hole in the firewall to allow it.
Heck, I would go so far as to put everything on the LAN side in its own DMZ. If you want your PC to talk to your media player, punch a specific hole in the firewall.
This will require industry cooperation:
* Protocols will have to be developed so "punching holes in firewalls" becomes super-easy for the consumer
* ISPs will have to start telling customers "if bad things come out of your network, we WILL cut you off. If you use one of these new routers, it's much less likely that bad things will come out of your network."
? It can say "Hey, I'm three inches behind you and ten to the right" without saying who you are.
I don't see how it can be hack-proof and anonymous at the same time.
To reject bogus messages, you need to know:
* That the person sending the message is "vouched for" somehow
* That the "vouching" hasn't been revoked
The most obvious way is for each car to "sign" its message, and have each car's "signing key" be counter-signed by the manufacturer or other trusted entity. Copies and counterfiets can be "revoked" as needed.
While such a system isn't foolproof, it's less game-able than an anonymous system that says "hi, I'm a car, and I'm 3 inches behind you to the right" without any way to verify that data.
About the only way "anonymous" communication would work would be if each car took incoming messages as "advisory/double-check it or ask the driver to check it" and not "as fact."