I lived in Colorado for three years, and regularly (almost monthly) made the 8-hour drive to my parents' home. Most of that time I had two vehicles, a Dodge Durango (needed to tow the camp trailer or boat, and to haul the whole family), and a Nissan LEAF, which was my commuter and the around-the-town vehicle when the whole family wasn't going. Given the amount of gas the Durango consumes I found it more economical (when all the kids weren't going) to rent a Prius or similar for the trips home. It worked great. Some unanticipated benefits were that the car tends to get pretty dirty when you drive it a thousand-plus miles in a short stretch, cluttered up with fast food containers and whatnot -- and there's an increased risk of spills and stains. So it's nice to just let Hertz deal with all of that.
Anyway, the point is that it's perfectly reasonable to choose a vehicle that is optimized for 95% of your driving, and rent one that is optimized for the other 5%. It can actually be very cost-effective. I've been looking into getting rid of the Durango and renting when I need a toy hauler, but so far it looks like the premiums charged for those sorts of vehicles make it a non-starter vs my paid-off SUV. Also, I haul the boat or trailer almost weekly during the summer, so the frequency of rentals would get annoying.
Any system which allows for refuelability/battery swapping has a much better chance of competing with current transportation fuel methods.
Nice assertion. I'll counter with one of my own: Battery swapping has negligible effect on the ability of EVs to compete with ICEVs for consumer travel. The only case where it's of use is in long-distance, non-stop travel, which is a miniscule percentage of road miles and which can in most cases be done with a rental vehicle. As long as the people in the car need to refuel every few hours, all you need is enough range to go as far as the people can, and a sufficiently-fast recharge time that by the time the people eat the car is ready to go again.
What's needed for EVs to compete isn't battery swapping, it's lower prices for vehicles with adequate range. The Model S has the range required, now. The Nissan LEAF and similar cars are in the ballpark on price. When we get a $25K (new) EV sedan with a 250-mile range, they'll sell like hotcakes in suburban middle-class America, and pollution levels in places like LA will decline dramatically in just a few years.
This isn't to say that battery swapping never makes sense, or that better highway and home charging infrastructure (particularly for apartment dwellers) doesn't matter, but solving the price/range problem will put EVs over the hump and the rest will follow naturally.
Is there a possible benefit to getting a battery with fewer charge cycles in a swap ? I sort of saw this concept as a way to get a refurbished battery when yours is reaching end of life, or has a few dead cells.
That's a completely different issue. Even without quick-recharge swaps, it's certainly possible to replace an old battery. But you're going to have to pay for that new battery (less a rebate for the value of the old one, I'm sure).
And in any case property tax does end up being a tax on economic activity also, or at least on economic value, which is determined by economic activity.
The Broken Window Fallacy is the classic counterexample. Among other things, it's a means to disengage (and of course, tax) economic activity from the value of property.
I agree that the Broken Window Fallacy is a fallacy. I don't see how it's a counterexample to the claim that property tax is a tax on economic activity. Can you elaborate?
capitalism in which the cost of protecting property rights is paid for by taxing economic activity rather than the property rights themselves.
How do you tax property rights?
Have you ever owned property? It is quite simple and called property tax.
I wondered if that's what he was proposing, that all defense of property be funded by property taxes. Property tax isn't really a tax on property rights, though. And in any case property tax does end up being a tax on economic activity also, or at least on economic value, which is determined by economic activity. So I don't see the point.
Do a search for google car can't drive in rain and you will see that they haven't even been tested in heavy rain because of safety concerns.
That just means they haven't gotten to that yet, not that they expect it to be very hard.
If it wasn't an issue they would already be doing it. Of course it is nowhere near the first of the issues autonomous cars have, they are quite far from what people imagine.
The guys I know working on the Google cars disagree. Oh, they have plenty to do, but it's mostly because they've set an extraordinarily high bar for themselves.
Is this memory based on silicon, or something else, like GaAs or Germanium or Graphene or something else?
Given that they've released close to zero technical details on how it works, but stated that it's nonvolatile, has 1000x the endurance of NAND flash while being 1000x faster, is cheaper than DRAM, and will be available in 128GBit capacities any minute now, my guess is that it's based on magic.
Of course it's cheaper than DRAM; DRAM is expensive. TFA says it will be more expensive than NAND and cheaper than DRAM. So, it just adds another point on the continuum... the more speed and write cycles you need, the more it costs. Seems reasonable. And TFA says nothing about availability; not sure where you got that from.
There's no reason to conclude it's magic. There's also no reason to start designing new architectures around it until we see it in the real world.
I own a LEAF in a similarly spread-out area, with little charging infrastructure. What do I care? The car is a commuter and I have a charger at home. It's always full whenever I go anywhere. Charging isn't cumbersome, it's practically zero-effort.
Actually, they probably included a few big wrenches to assemble some of the rack systems, so they probably have the tools to break even 1024 bit encryption.
When you say "1024-bit encryption" you're talking about RSA, which is a completely different problem. 1024-bit RSA are too small to be used today and should be replaced.
2048-bit RSA keys, however, are roughly equivalent in security against brute force to a 112-bit symmetric key, and will be secure against anyone for quite some time. 3072-bit RSA keys are equivalent to a 128-bit symmetric key. Excascale, even yottascale, computers won't touch them.
But everyone really should be moving away from RSA anyway. ECC is better in virtually every respect. To get 128-bit security (meaning equivalency to 128-bit symmetric key), you only need a 256-bit EC key.
Range suffers a bit, not so much because the batteries are affected by cold, but because you use some juice to heat the cabin. As far as performance on snow, they're great. Their center of gravity is low, front wheel drive and the power applied to the wheels is finely controllable.
I drive my Nissan LEAF to the ski resort almost every morning during the winter.
What complicates this is that whether or not an electric car is cheaper depends heavily on your driving -- and whether or not an electric car is feasible depends on your driving. TOC also depends on the cost of fuel and electricity. When I ran the numbers for myself a few years ago my break-even for a Nissan LEAF was three years, with the federal and state tax credits, or eight years without. That was without taking into consideration the difference in maintenance costs since I didn't know how to estimate them. I did not, however, predict the drop in gas prices. I haven't re-run the numbers, but I expect the lower price of gasoline would push those break-even points out 2-3 years.
Probably none at all. If you want to break today's encryption/hashing algorithms you would probably be using ASICs if not those then FPGAs with GPU compute being your last choice.
ASICs, FPGAs and GPUs are all utterly, utterly inadequate to attack today's encryption and hashing algorithms. Unless you have not only tens of billions of dollars but also don't mind waiting millions of years. http://tech.slashdot.org/comme....
For that, you would be using custom ASIC hardware, and lots of it.
No, for that you just laugh at the guy asking you to do it, and look for ways to steal the key, rather than brute forcing it. Even if an ASIC solution gets to way beyond exascale, say to yottascale (10^6 times faster than exascale), you're still looking at on the order of a million years to recover a single 128-bit AES key, on average.
What would the existence of an exascale supercomputer mean for today's popular encryption/hashing algorithms?
Nothing, nothing at all.
Suppose, for example that your exascale computer could do exa-AES-ops... 10^18 AES encryptions per second. It would take that computer 1.7E20 seconds to brute force half of the AES-128 key space. That's 5.4E12 years, to achieve a 50% chance of recovering a single key.
And if that weren't the case, you could always step up to 192 or 256-bit keys. In "Applied Cryptography", in the chapter on key length, Bruce Schneier analyzed thermodynamic limitations on brute force key search. He calculated the amount of energy required for a perfectly efficient computer to merely increment a counter through all of its values. That's not to actually do anything useful like perform an AES operation and a comparison to test a particular key, but merely to count through all possible keys. Such a computer, running at the ambient temperature of the universe, would consume 4.4E-6 ergs to set or clear a single bit. Consuming the entire output of our star for a year, and cycling through the states in an order chosen to minimize bit flips rather than just counting sequentially, would provide enough energy for this computer to count through 2^187. The entire output of the sun for 32 years gets us up to 2^192. To run a perfectly-efficient computer through 2^256 states, you'd need to capture all of the energy from approximately 137 billion supernovae[*]. To brute force a 256-bit key you'd need to not only change your counter to each value, you'd then need to perform an AES operation.
Raw computing power is not and never will be the way to break modern crypto systems[**]. To break them you need to either exploit unknown weaknesses in the algorithms (which means you have to be smarter than the world's academic cryptographers), or exploit defects in the implementation (e.g. side channel attacks) or find other ways to get the keys -- attack the key management. The last option is always the best, though implementation defects are also quite productive. Neither of them benefit significantly from having massive computational resources available.
[*] Schneier didn't take into account reversible computing in his calculation. A cleverly-constructed perfectly-efficient computer could make use of reversible circuits everywhere they can work, and a carefully-constructed algorithm could make use of as much reversibility as possible. With that, it might be feasible to lower the energy requirements significantly, maybe even several orders of magnitude (though that would be tough). We're still talking energy requirements involving the total energy output of many supernovae.
[**] Another possibility is to change the question entirely by creating computers that don't operate sequentially, but instead test all possible answers at once. Quantum computers. Their practical application to the complex messiness of block ciphers is questionable, though the mathematical simplicity of public key encryption is easy to implement on QCs. Assuming we ever manage to build them on the necessary scale. If we do, we can expect an intense new focus on protocols built around symmetric cryptography, I expect.
Not true, Indiana allows deadly force in defense of property, and there is no duty to retreat.
And it includes your vehicle when away from home.
Cite?
I think you're talking about Indiana's Castle Doctrine law, which gives you the right to assume that you're threatened with death if someone breaks into your house or car (some states also include place of business). But the authorization is for self-defense, not defense of property. The Castle Doctrine just means that the law automatically assumes that you were at risk of death or serious injury in those locations, and you don't have to justify it.
If a guy is stealing your car, would you just watch him and let him do it? Or, you could threaten him with the gun, but both you and him know that you can't legally pull the trigger? So he continues to steal your car, and you can't do anything at all to defend your property??
I can use non-lethal force. There are lots of options available.
But, no, I will not kill a man to stop him from taking my stuff. I have insurance. The situation changes dramatically if my kid is in the back seat, of course.
So for those several times per year, rent a car.
I lived in Colorado for three years, and regularly (almost monthly) made the 8-hour drive to my parents' home. Most of that time I had two vehicles, a Dodge Durango (needed to tow the camp trailer or boat, and to haul the whole family), and a Nissan LEAF, which was my commuter and the around-the-town vehicle when the whole family wasn't going. Given the amount of gas the Durango consumes I found it more economical (when all the kids weren't going) to rent a Prius or similar for the trips home. It worked great. Some unanticipated benefits were that the car tends to get pretty dirty when you drive it a thousand-plus miles in a short stretch, cluttered up with fast food containers and whatnot -- and there's an increased risk of spills and stains. So it's nice to just let Hertz deal with all of that.
Anyway, the point is that it's perfectly reasonable to choose a vehicle that is optimized for 95% of your driving, and rent one that is optimized for the other 5%. It can actually be very cost-effective. I've been looking into getting rid of the Durango and renting when I need a toy hauler, but so far it looks like the premiums charged for those sorts of vehicles make it a non-starter vs my paid-off SUV. Also, I haul the boat or trailer almost weekly during the summer, so the frequency of rentals would get annoying.
Any system which allows for refuelability/battery swapping has a much better chance of competing with current transportation fuel methods.
Nice assertion. I'll counter with one of my own: Battery swapping has negligible effect on the ability of EVs to compete with ICEVs for consumer travel. The only case where it's of use is in long-distance, non-stop travel, which is a miniscule percentage of road miles and which can in most cases be done with a rental vehicle. As long as the people in the car need to refuel every few hours, all you need is enough range to go as far as the people can, and a sufficiently-fast recharge time that by the time the people eat the car is ready to go again.
What's needed for EVs to compete isn't battery swapping, it's lower prices for vehicles with adequate range. The Model S has the range required, now. The Nissan LEAF and similar cars are in the ballpark on price. When we get a $25K (new) EV sedan with a 250-mile range, they'll sell like hotcakes in suburban middle-class America, and pollution levels in places like LA will decline dramatically in just a few years.
This isn't to say that battery swapping never makes sense, or that better highway and home charging infrastructure (particularly for apartment dwellers) doesn't matter, but solving the price/range problem will put EVs over the hump and the rest will follow naturally.
Is there a possible benefit to getting a battery with fewer charge cycles in a swap ? I sort of saw this concept as a way to get a refurbished battery when yours is reaching end of life, or has a few dead cells.
That's a completely different issue. Even without quick-recharge swaps, it's certainly possible to replace an old battery. But you're going to have to pay for that new battery (less a rebate for the value of the old one, I'm sure).
Sounds like a job for Cron.
Better yet, systemd/Timers: https://wiki.archlinux.org/ind...
And in any case property tax does end up being a tax on economic activity also, or at least on economic value, which is determined by economic activity.
The Broken Window Fallacy is the classic counterexample. Among other things, it's a means to disengage (and of course, tax) economic activity from the value of property.
I agree that the Broken Window Fallacy is a fallacy. I don't see how it's a counterexample to the claim that property tax is a tax on economic activity. Can you elaborate?
capitalism in which the cost of protecting property rights is paid for by taxing economic activity rather than the property rights themselves.
How do you tax property rights?
Have you ever owned property? It is quite simple and called property tax.
I wondered if that's what he was proposing, that all defense of property be funded by property taxes. Property tax isn't really a tax on property rights, though. And in any case property tax does end up being a tax on economic activity also, or at least on economic value, which is determined by economic activity. So I don't see the point.
capitalism in which the cost of protecting property rights is paid for by taxing economic activity rather than the property rights themselves.
How do you tax property rights?
Do a search for google car can't drive in rain and you will see that they haven't even been tested in heavy rain because of safety concerns.
That just means they haven't gotten to that yet, not that they expect it to be very hard.
If it wasn't an issue they would already be doing it. Of course it is nowhere near the first of the issues autonomous cars have, they are quite far from what people imagine.
The guys I know working on the Google cars disagree. Oh, they have plenty to do, but it's mostly because they've set an extraordinarily high bar for themselves.
Do a search for google car can't drive in rain and you will see that they haven't even been tested in heavy rain because of safety concerns.
That just means they haven't gotten to that yet, not that they expect it to be very hard.
Is this memory based on silicon, or something else, like GaAs or Germanium or Graphene or something else?
Given that they've released close to zero technical details on how it works, but stated that it's nonvolatile, has 1000x the endurance of NAND flash while being 1000x faster, is cheaper than DRAM, and will be available in 128GBit capacities any minute now, my guess is that it's based on magic.
Of course it's cheaper than DRAM; DRAM is expensive. TFA says it will be more expensive than NAND and cheaper than DRAM. So, it just adds another point on the continuum... the more speed and write cycles you need, the more it costs. Seems reasonable. And TFA says nothing about availability; not sure where you got that from.
There's no reason to conclude it's magic. There's also no reason to start designing new architectures around it until we see it in the real world.
It's going to cost more than NAND flash.
But it would make a GREAT cache for spinning rust. None of the longevity problems of NAND, 1,000 times faster. Ka-chow.
For that matter, it would be a pretty good cache for NAND SSDs. I could do with most of my writes being 1000X faster.
If you have 64GB of RAM, you can cache the entire SSD. Then you won't have to issue TRIM commands!
My SSD is 1 TB. The other one is 256 GB. SSDs today are a lot larger than you seem to realize.
I own a LEAF in a similarly spread-out area, with little charging infrastructure. What do I care? The car is a commuter and I have a charger at home. It's always full whenever I go anywhere. Charging isn't cumbersome, it's practically zero-effort.
Actually, they probably included a few big wrenches to assemble some of the rack systems, so they probably have the tools to break even 1024 bit encryption.
When you say "1024-bit encryption" you're talking about RSA, which is a completely different problem. 1024-bit RSA are too small to be used today and should be replaced.
2048-bit RSA keys, however, are roughly equivalent in security against brute force to a 112-bit symmetric key, and will be secure against anyone for quite some time. 3072-bit RSA keys are equivalent to a 128-bit symmetric key. Excascale, even yottascale, computers won't touch them.
But everyone really should be moving away from RSA anyway. ECC is better in virtually every respect. To get 128-bit security (meaning equivalency to 128-bit symmetric key), you only need a 256-bit EC key.
Range suffers a bit, not so much because the batteries are affected by cold, but because you use some juice to heat the cabin. As far as performance on snow, they're great. Their center of gravity is low, front wheel drive and the power applied to the wheels is finely controllable.
I drive my Nissan LEAF to the ski resort almost every morning during the winter.
What complicates this is that whether or not an electric car is cheaper depends heavily on your driving -- and whether or not an electric car is feasible depends on your driving. TOC also depends on the cost of fuel and electricity. When I ran the numbers for myself a few years ago my break-even for a Nissan LEAF was three years, with the federal and state tax credits, or eight years without. That was without taking into consideration the difference in maintenance costs since I didn't know how to estimate them. I did not, however, predict the drop in gas prices. I haven't re-run the numbers, but I expect the lower price of gasoline would push those break-even points out 2-3 years.
Probably none at all. If you want to break today's encryption/hashing algorithms you would probably be using ASICs if not those then FPGAs with GPU compute being your last choice.
ASICs, FPGAs and GPUs are all utterly, utterly inadequate to attack today's encryption and hashing algorithms. Unless you have not only tens of billions of dollars but also don't mind waiting millions of years. http://tech.slashdot.org/comme....
For that, you would be using custom ASIC hardware, and lots of it.
No, for that you just laugh at the guy asking you to do it, and look for ways to steal the key, rather than brute forcing it. Even if an ASIC solution gets to way beyond exascale, say to yottascale (10^6 times faster than exascale), you're still looking at on the order of a million years to recover a single 128-bit AES key, on average.
Brute force is not how you attack modern cryptosystems. More detail: http://tech.slashdot.org/comme...
What would the existence of an exascale supercomputer mean for today's popular encryption/hashing algorithms?
Nothing, nothing at all.
Suppose, for example that your exascale computer could do exa-AES-ops... 10^18 AES encryptions per second. It would take that computer 1.7E20 seconds to brute force half of the AES-128 key space. That's 5.4E12 years, to achieve a 50% chance of recovering a single key.
And if that weren't the case, you could always step up to 192 or 256-bit keys. In "Applied Cryptography", in the chapter on key length, Bruce Schneier analyzed thermodynamic limitations on brute force key search. He calculated the amount of energy required for a perfectly efficient computer to merely increment a counter through all of its values. That's not to actually do anything useful like perform an AES operation and a comparison to test a particular key, but merely to count through all possible keys. Such a computer, running at the ambient temperature of the universe, would consume 4.4E-6 ergs to set or clear a single bit. Consuming the entire output of our star for a year, and cycling through the states in an order chosen to minimize bit flips rather than just counting sequentially, would provide enough energy for this computer to count through 2^187. The entire output of the sun for 32 years gets us up to 2^192. To run a perfectly-efficient computer through 2^256 states, you'd need to capture all of the energy from approximately 137 billion supernovae[*]. To brute force a 256-bit key you'd need to not only change your counter to each value, you'd then need to perform an AES operation.
Raw computing power is not and never will be the way to break modern crypto systems[**]. To break them you need to either exploit unknown weaknesses in the algorithms (which means you have to be smarter than the world's academic cryptographers), or exploit defects in the implementation (e.g. side channel attacks) or find other ways to get the keys -- attack the key management. The last option is always the best, though implementation defects are also quite productive. Neither of them benefit significantly from having massive computational resources available.
[*] Schneier didn't take into account reversible computing in his calculation. A cleverly-constructed perfectly-efficient computer could make use of reversible circuits everywhere they can work, and a carefully-constructed algorithm could make use of as much reversibility as possible. With that, it might be feasible to lower the energy requirements significantly, maybe even several orders of magnitude (though that would be tough). We're still talking energy requirements involving the total energy output of many supernovae.
[**] Another possibility is to change the question entirely by creating computers that don't operate sequentially, but instead test all possible answers at once. Quantum computers. Their practical application to the complex messiness of block ciphers is questionable, though the mathematical simplicity of public key encryption is easy to implement on QCs. Assuming we ever manage to build them on the necessary scale. If we do, we can expect an intense new focus on protocols built around symmetric cryptography, I expect.
Duh. No one is claiming there's a bright line.
Idjuts who try to respond with non-lethal force often find that the other side isnt always that considerate.
I deploy pepper spray with my off hand, strong hand on my handgun.
Post away, I'll read it, and argue with you about what it means.
Not true, Indiana allows deadly force in defense of property, and there is no duty to retreat. And it includes your vehicle when away from home.
Cite?
I think you're talking about Indiana's Castle Doctrine law, which gives you the right to assume that you're threatened with death if someone breaks into your house or car (some states also include place of business). But the authorization is for self-defense, not defense of property. The Castle Doctrine just means that the law automatically assumes that you were at risk of death or serious injury in those locations, and you don't have to justify it.
Texans have the right to make their laws. But killing over replaceable stuff is morally reprehensible, and I have the right to say Texas is wrong.
If a guy is stealing your car, would you just watch him and let him do it? Or, you could threaten him with the gun, but both you and him know that you can't legally pull the trigger? So he continues to steal your car, and you can't do anything at all to defend your property??
I can use non-lethal force. There are lots of options available.
But, no, I will not kill a man to stop him from taking my stuff. I have insurance. The situation changes dramatically if my kid is in the back seat, of course.