I've had better results with my Capital One CC than my USBank checking account. Capital One "tried" to get away with bogus charges, but would work with my wife to remove them. USBank's management out-right told me that they are sorry for their mistakes, but there is nothing they could do about it.. WTF kind of response is that?! I didn't have the time or money to fight them, I just changed to the local credit union.
I forgot about that part. With all things fair, Twofish is faster, but like you pointed out, AES is in the hardware, which makes it faster/lower-power.
Most of the next gen cryptography is about public keys or hashes. AES is still effective, so the weakest link in the chain is going to be passwords or breakable public keys, which would allow an attacker to acquire the AES key during the hand-shake.
One needs a safe way to transmit the AES key over a public network, like the internet. Public keys are very slow, but semi strong. AES is quite fast and really really really strong. Trying to make asymmetric encryption strong is hard because the public key gives information about the private key.
Twofish is decently faster than AES and still quite strong(Twofish almost became AES, was in the final 5), so it is a good alternative. SHA1 is a hash, not a symmetric encryption.
Unless it uses brute-forcing and is correct on the first guess...
AES keys are typically randomly generated or based on a hash. AES is strong, so breaking the public key or password to get the AES key is always the best way to "break" AES, but it's really just a side-channel attack. That's not AES's fault.
It is estimated that AES256 would take about 2^200 operations with currently public flaws.
Hypothetical
1,000,000,000 computers(1bil computers)
1,000,000,000,000,000 ops per computer(1peta op)
1,000,000,000,000,000,000,000,000 ops per second total
1.6069380442589902755419620923412e+60 ops to break AES256
1.6069380442589902755419620923412e+60 / (1,000,000,000,000,000,000,000,000 * 60sec * 60min * 24hr * 365days)
is 50,955,671,114,250,072,156,962,268,275.658 years
You would have to be quite dedicated and live a long time to break AES with current math/computers.
My cousin went through an advanced crypto class and his teacher ran the math and it comes down to this. If you had an ideal computer(100% efficient) that consumed the absolute minimum amount of energy that it takes to represent data based on our current laws of physics, you would have to consume all of the heat energy in the entire Milkyway Galaxy. Short of a major flaw in AES, no galaxy-bound computer can break AES.
HTTP 1.1 pipelining does not allow more than one command to be outstanding. HTTP allows you to re-use the connection for your next command, but does not allow multiple commands at the same time.
HTTP1.1 is actually quite horrible for modern networks/computers. Choosing between HTTP1.1 and 1.0 is choosing between a giant douche and a turd sandwich. UDP won't happen because of the lack of congestion avoidance, which should be left up to the OS, not the app.
The biggest issue with HTTP is it does not allow multiplexing communication without opening up more connection, which is hard on servers, firewalls, and messes with TCP congestion detection.
On the other side of thing Flame only affected networks designed this way because the HTTPS proxy was claiming all of the data was "trusted" when it was not.
When a company uses HTTPS proxies, it's just making it so all of the client browsers trust every HTTPS website.
Yes, HTTPS proxies save money, but so does not using any security.
CDMA runs as floor noise, which means it has a very very low power output. I can't say I've ever had my CDMA drop except when no bars and I hold the phone wrong.
I do agree with your anti-blanket statement argument as the intensity makes a large difference(don't stand in front of a radar or bypass a microwave's safety feature), but DNA damage is directly related to how high the EM frequency is, and EM from cellphones is lower than visible light.
Don't worry, cell phones use a lower frequency and less power than a fluorescent light-bulb. More likely to get cancer from EM radiation by being too close to your light-bulb than your cell-phone attached to the side of your head.
My local ISP claims no bandwidth caps and has nothing against P2P while openly flaunting their symmetrical speeds. At the same time, they state that hosting servers of any kind are against the ToS.
Another interesting note is the openly claim that they will not monitor any of your data-streams unless it is pointed to them that your may be doing something illegal; And only then will they look for just the offending service, assuming it exists.
Because they have no caps, don't care about P2P, and openly claim that they will not monitor your data, I believe they have this clause only so they have a leg to stand on if shit hits the fan.
HT is a mixed bag. When the scheduler knows about it, it can give an average decent speed up, in some corner cases, it's bad.
The whole issue is that modern desktop CPUs have all of these execution units to help speed up single thread performance by checking for dependencies and executing instruction in parallel when there is no dependency. Quite often, there is serial code that is just loaded with dependencies. For a small 10% transistor cost, you can make a second virtual CPU that can make use of these idle execution units.
HT also kicks in when one thread stalls for memory loads/etc. It works at the cycle level, so it's really fast to switch. If there is even one cycle where the FPU/int/SIMD is free, HT can make use of it.
Sounds great on paper, but then you realize that you need to share the same front ends like L1 cache.
The good news is when one of the virtual HT cores is turned off(OS has to sleep it), it frees up the front end shared resources for the other virtual thread, letting it run as if HT is off.
"The ARM register set consists of 37 general-purpose registers, 16 of which are usable at any one time."
In that case, Intel CPUs have hundreds of general-purpose registers, 16 of which are usable at any one time. The CPU does behind the scenes optimization with access to hundreds of registers. The 16 registers you see are virtual registers, not the real ones.
"Then, as if x86 wasn't CISC enough, they rolled out the MMX, SSE, SSE2, SSE3, SSE4 additions."
What's wrong with SIMD style instructions? Many archs use it, from ARM to GPUs to x86.
The plunge happened in 2008, not quite 10 years yet. I'm still happily watching my 401k gobble up cheap stocks.
One of two main things could happen:
1) Market rebounds and all of my old stock goes back to normal, along with a bunch of new stock that hyper inflates. This means now is the time to buy.
2) Market doesn't rebound, society falls apart and money is worthless. Well, I guess I could have been stocking up on canned goods/etc, but it wouldn't have really helped in the long run.
There is much to gain from buying now and not much to lose.
Microseconds, not nano-seconds, and light is only ~0.65c in fiber. If you multiply your round-trip value by 1000, then double it, it will be closer to the actual value.
One could have servers co-located at every exchange, but you still need to communicate among the servers somehow. Knowing what's happening at another exchange can also be useful, from each server's perspective.
Slashdot Mirror
I've had better results with my Capital One CC than my USBank checking account. Capital One "tried" to get away with bogus charges, but would work with my wife to remove them. USBank's management out-right told me that they are sorry for their mistakes, but there is nothing they could do about it.. WTF kind of response is that?! I didn't have the time or money to fight them, I just changed to the local credit union.
I forgot about that part. With all things fair, Twofish is faster, but like you pointed out, AES is in the hardware, which makes it faster/lower-power.
Until you want a house. Hmmm, $600/month to rent that I will never see again, or $600/month towards a house....
If I rent, in 30 years I will have nothing to show for
If I get a mortgage and purchase a house, in 30 years I will have a $100k house.
Most of the next gen cryptography is about public keys or hashes. AES is still effective, so the weakest link in the chain is going to be passwords or breakable public keys, which would allow an attacker to acquire the AES key during the hand-shake.
One needs a safe way to transmit the AES key over a public network, like the internet. Public keys are very slow, but semi strong. AES is quite fast and really really really strong. Trying to make asymmetric encryption strong is hard because the public key gives information about the private key.
Unless it uses brute-forcing and is correct on the first guess...
AES keys are typically randomly generated or based on a hash. AES is strong, so breaking the public key or password to get the AES key is always the best way to "break" AES, but it's really just a side-channel attack. That's not AES's fault.
asymmetric encryption != symmetric encryption
AES is rated in galaxy lifetimes, not a paltry "millions of years"
It is estimated that AES256 would take about 2^200 operations with currently public flaws.
Hypothetical
1,000,000,000 computers(1bil computers)
1,000,000,000,000,000 ops per computer(1peta op)
1,000,000,000,000,000,000,000,000 ops per second total
1.6069380442589902755419620923412e+60 ops to break AES256
1.6069380442589902755419620923412e+60 / (1,000,000,000,000,000,000,000,000 * 60sec * 60min * 24hr * 365days)
is 50,955,671,114,250,072,156,962,268,275.658 years
You would have to be quite dedicated and live a long time to break AES with current math/computers.
My cousin went through an advanced crypto class and his teacher ran the math and it comes down to this. If you had an ideal computer(100% efficient) that consumed the absolute minimum amount of energy that it takes to represent data based on our current laws of physics, you would have to consume all of the heat energy in the entire Milkyway Galaxy. Short of a major flaw in AES, no galaxy-bound computer can break AES.
HTTP 1.1 pipelining does not allow more than one command to be outstanding. HTTP allows you to re-use the connection for your next command, but does not allow multiple commands at the same time.
HTTP1.1 is actually quite horrible for modern networks/computers. Choosing between HTTP1.1 and 1.0 is choosing between a giant douche and a turd sandwich. UDP won't happen because of the lack of congestion avoidance, which should be left up to the OS, not the app.
The biggest issue with HTTP is it does not allow multiplexing communication without opening up more connection, which is hard on servers, firewalls, and messes with TCP congestion detection.
On the other side of thing Flame only affected networks designed this way because the HTTPS proxy was claiming all of the data was "trusted" when it was not.
When a company uses HTTPS proxies, it's just making it so all of the client browsers trust every HTTPS website.
Yes, HTTPS proxies save money, but so does not using any security.
CDMA runs as floor noise, which means it has a very very low power output. I can't say I've ever had my CDMA drop except when no bars and I hold the phone wrong.
I do agree with your anti-blanket statement argument as the intensity makes a large difference(don't stand in front of a radar or bypass a microwave's safety feature), but DNA damage is directly related to how high the EM frequency is, and EM from cellphones is lower than visible light.
Tagging along: I heard water is poisonous, people die from it every year!
Don't worry, cell phones use a lower frequency and less power than a fluorescent light-bulb. More likely to get cancer from EM radiation by being too close to your light-bulb than your cell-phone attached to the side of your head.
Not if you already have a 50Tb file server cluster sitting at home. A bit of network traffic is nothing for electrical costs.
My local ISP claims no bandwidth caps and has nothing against P2P while openly flaunting their symmetrical speeds. At the same time, they state that hosting servers of any kind are against the ToS.
Another interesting note is the openly claim that they will not monitor any of your data-streams unless it is pointed to them that your may be doing something illegal; And only then will they look for just the offending service, assuming it exists.
Because they have no caps, don't care about P2P, and openly claim that they will not monitor your data, I believe they have this clause only so they have a leg to stand on if shit hits the fan.
ARM goes from 250mw at 800mhz to 5 watts at 1.5ghz. If you're willing to clock low, you can make your numbers really good.
HT is a mixed bag. When the scheduler knows about it, it can give an average decent speed up, in some corner cases, it's bad.
The whole issue is that modern desktop CPUs have all of these execution units to help speed up single thread performance by checking for dependencies and executing instruction in parallel when there is no dependency. Quite often, there is serial code that is just loaded with dependencies. For a small 10% transistor cost, you can make a second virtual CPU that can make use of these idle execution units.
HT also kicks in when one thread stalls for memory loads/etc. It works at the cycle level, so it's really fast to switch. If there is even one cycle where the FPU/int/SIMD is free, HT can make use of it.
Sounds great on paper, but then you realize that you need to share the same front ends like L1 cache.
The good news is when one of the virtual HT cores is turned off(OS has to sleep it), it frees up the front end shared resources for the other virtual thread, letting it run as if HT is off.
Allows for much much faster atomic updates when doing thread syncing.
"The ARM register set consists of 37 general-purpose registers, 16 of which are usable at any one time."
In that case, Intel CPUs have hundreds of general-purpose registers, 16 of which are usable at any one time. The CPU does behind the scenes optimization with access to hundreds of registers. The 16 registers you see are virtual registers, not the real ones.
"Then, as if x86 wasn't CISC enough, they rolled out the MMX, SSE, SSE2, SSE3, SSE4 additions."
What's wrong with SIMD style instructions? Many archs use it, from ARM to GPUs to x86.
Exactly. The Bulldozer idea is a great idea. FPU/SIMD is a lot of idle transistors for most workloads.
The plunge happened in 2008, not quite 10 years yet. I'm still happily watching my 401k gobble up cheap stocks.
One of two main things could happen:
1) Market rebounds and all of my old stock goes back to normal, along with a bunch of new stock that hyper inflates. This means now is the time to buy.
2) Market doesn't rebound, society falls apart and money is worthless. Well, I guess I could have been stocking up on canned goods/etc, but it wouldn't have really helped in the long run.
There is much to gain from buying now and not much to lose.
400m is 1.3 ns (nano-seconds),
Microseconds, not nano-seconds, and light is only ~0.65c in fiber. If you multiply your round-trip value by 1000, then double it, it will be closer to the actual value.
One could have servers co-located at every exchange, but you still need to communicate among the servers somehow. Knowing what's happening at another exchange can also be useful, from each server's perspective.
It does cause temporary jobs and adds infrastructure. Too bad that infrastructure is pretty much reserved for more of this crap.