AES-CTR being based on a permutation rather than a true PRF might matter if SSH used all the counter values, but SSH rekeys every 2^32 blocks at most - a tiny fraction of the 2^128 possible counters.
Google has grabbed a bunch of open source libraries, sometimes respecting the license, hacked on them, and rolled them into Chrom*.
If you have any cases where you think that Chrome is failing to comply with the terms of a free software license, then please file a bug at http://code.google.com/p/chromium/issues/list - we take license compliance very seriously. (I'm a Google engineer, though not working Chrome).
No, it is not vulnerable to this attack. The Brumley/Tuveri paper describes a timing leak in a specific algorithm that is only used for elliptic curve crypto over binary/GF(2m) fields. OpenSSH uses ECC over prime fields that use different algorithms that have no known timing leaks. A result against ECC using prime fields would be more difficult because the curve point components are integers and so can use well-tested modular arithmetic code.
The changes announced today seem to be little more than a delaying tactic to remove the issue of mandatory Internet censorship from the agenda ahead of the election that is expected to be announced any day now. This issue has turned quite toxic for the government; the people who are for it are only weakly so, but the people who are against it are furious and are already organising campaigns against the government on various social media.
I don't think the government can be trusted not to bring it back in a essentially unmodified form after the next election. Vote accordingly.
Sony has managed to lose my trust too. I was a very happy customer of PS1-3, but the retroactive otheros thing has put me right off. I rarely used Linux once I installed it, but that they were willing to retrospectively nuke an advertised feature of their product clearly demonstrated to me that they do not put the customer first. I wouldn't be at all surprised if they do start crippling the PSN for non-paying customers.
The dumbest thing about the OtherOS removal is that it is probably not even going to help. Now that the hypervisor has been cracked enough to obtain memory dumps, it is far more likely that further hacking is going to rely on bugs that are found in the hypervisor software itself. These will probably be reachable by any application running on the system that takes user or network input. Think that every savegame loader is foolproof? How about that dinky web browser? Nuking OtherOS just pissed off loyal customers and bought them very little.
Actually, in some places (e.g. Australia), a significant amount of paper _is_ made by chopping down unique old-growth forests. Furthermore, the chlorine bleaching processes commonly used release a substantial amount of toxic effluent. So yeah, you should worry.
Thanks for the pointer, I have been meaning to do just that. Here is mine:
Sony has just issued a firmware update[1] that disables the "OtherOS" support that is used to run alternate operating systems such as Linux on the Playstation 3 (PS3) game console. This was an advertised feature of the PS3 and was a factor in my decision to purchase the product. The firmware update is effectively mandatory; the PS3 will not support online play or game updates/downloads via the Playstation network without it (these are also advertised features).
That a major consumer electronics company can unilaterally remove advertised features from a product that I have bought and paid for is chilling to say the least and appears misleading and deceptive in the classic "bait and switch" style. I request that the ACCC investigate this matter.
Larger sensors will always have a noise and sensitivity advantage to smaller sensors: larger surface area == more photon gathering ability.
Also, I'm surprised they cite a four-stop improvement; I thought we were within that range of the quantum limit with current sensors already.
If you are randomly generating your passwords and they are of a decent length then you don't really need to do anything. If your passwords contain lower-case letters only (not recommended), but are eight characters long then your million authentication attempts would represent only a 0.0005% chance of success. If you passwords contain numbers and upper-case characters too, then the likelihood is 1000 times less.
Re:October 18th is also its birthday
on
OpenBSD 4.6 Released
·
· Score: 2, Informative
Most of the speed gains for high bandwidth x delay networks have been realised in stock OpenSSH already. HPN still does better on very fast long distance networks though.
You do realise that we implemented quite a few speedups for high bandwidth x delay networks already. The remaining "HPN" patches make marginal difference for most networks, other than the patch to allow deactivation of encryption that we refuse to merge at all.
The umac-64 MAC is only supported by OpenSSH AFAIK (though the spec is available to anyone else who wants to). It is faster and has a better security guarantee than HMAC-MD5 (and is way faster than HMAC-SHA1).
I'd like to thank the OpenBSD project, as well, but I'd also like to point out a few issues.
OpenSSH still won't work with certificates signed by a CA.
Quite right, and we have no intention of incorporating x.509 support. X.509 parsing and verification exposes a large amount of attack surface and all of it is, by necessity, pre-authentication too (the type which, if buggy, allows worms). Read Peter Gurmann's X.509 style guide and see if you ever want to go near this horror again. We have actually written our own minimal RSA verification code to avoid the sort of ASN.1 parsing that is necessary to deal with X.509, and it has saved us from at least seven bugs - some probably exploitable for authentication bypass or remote code execution.
OpenSSH doesn't allow an unencrypted connection (after authentication). Not all CPUs can encrypt/decrypt at 1Gbps.
Yep, we are a _secure_ shell and we take a mildly patriarchal attitude to adding options that can lead to insecure use of OpenSSH. Note that the actual bottleneck in most cases is not the crypto anyway (at least when using arcfour256 as your cipher) but the MAC, and you wouldn't want to switch that off. We do have a very fast MAC though: umac-64
OpenSSH doesn't work - as advertised - with an exclamation point in a "Match" statement.
Use arcfour256 as your cipher and umac-64@openssh.com as your MAC (ssh -oCiphers=arcfour256 -oMACs=umac-64@openssh.com...). Between these, CPU is usually not the bottleneck anymore.
We don't support the none cipher because "secure networks" often aren't, and there are already tools that are insecure and go fast.
Slashdot Mirror
Imagine a beowulf cluster of ... nevermind.
AES-CTR being based on a permutation rather than a true PRF might matter if SSH used all the counter values, but SSH rekeys every 2^32 blocks at most - a tiny fraction of the 2^128 possible counters.
Google has grabbed a bunch of open source libraries, sometimes respecting the license, hacked on them, and rolled them into Chrom*.
If you have any cases where you think that Chrome is failing to comply with the terms of a free software license, then please file a bug at http://code.google.com/p/chromium/issues/list - we take license compliance very seriously. (I'm a Google engineer, though not working Chrome).
No, it is not vulnerable to this attack. The Brumley/Tuveri paper describes a timing leak in a specific algorithm that is only used for elliptic curve crypto over binary/GF(2m) fields. OpenSSH uses ECC over prime fields that use different algorithms that have no known timing leaks. A result against ECC using prime fields would be more difficult because the curve point components are integers and so can use well-tested modular arithmetic code.
It's a good thing we did that before banning ozone-depleting freons.
OpenSSH isn't vulnerable to this attack: https://twitter.com/#!/damienmiller/status/72814031941017600
Never mind the millions displaced by rising sea levels or changed rainfall patterns effecting their crops, we might lose a few bars of wifi reception!
You have cause and effect swapped. MS announced Windows for ARM because of the huge number of ARM products coming to market.
Apology accepted Captain Ozzie.
I have been reading Slashdot for a long time, but I have to say that this was easily the best comment I have ever seen here. Well done.
The changes announced today seem to be little more than a delaying tactic to remove the issue of mandatory Internet censorship from the agenda ahead of the election that is expected to be announced any day now. This issue has turned quite toxic for the government; the people who are for it are only weakly so, but the people who are against it are furious and are already organising campaigns against the government on various social media.
I don't think the government can be trusted not to bring it back in a essentially unmodified form after the next election. Vote accordingly.
Sony has managed to lose my trust too. I was a very happy customer of PS1-3, but the retroactive otheros thing has put me right off. I rarely used Linux once I installed it, but that they were willing to retrospectively nuke an advertised feature of their product clearly demonstrated to me that they do not put the customer first. I wouldn't be at all surprised if they do start crippling the PSN for non-paying customers.
The dumbest thing about the OtherOS removal is that it is probably not even going to help. Now that the hypervisor has been cracked enough to obtain memory dumps, it is far more likely that further hacking is going to rely on bugs that are found in the hypervisor software itself. These will probably be reachable by any application running on the system that takes user or network input. Think that every savegame loader is foolproof? How about that dinky web browser? Nuking OtherOS just pissed off loyal customers and bought them very little.
Actually, in some places (e.g. Australia), a significant amount of paper _is_ made by chopping down unique old-growth forests. Furthermore, the chlorine bleaching processes commonly used release a substantial amount of toxic effluent. So yeah, you should worry.
Actually there is: you cannot use the Playstation network or BD+ bluray features without the latest SW version.
Sony has just issued a firmware update[1] that disables the "OtherOS" support that is used to run alternate operating systems such as Linux on the Playstation 3 (PS3) game console. This was an advertised feature of the PS3 and was a factor in my decision to purchase the product. The firmware update is effectively mandatory; the PS3 will not support online play or game updates/downloads via the Playstation network without it (these are also advertised features).
That a major consumer electronics company can unilaterally remove advertised features from a product that I have bought and paid for is chilling to say the least and appears misleading and deceptive in the classic "bait and switch" style. I request that the ACCC investigate this matter.
[1] http://blog.us.playstation.com/2010/03/28/ps3-firmware-v3-21-update/
You mean like Moody's or Standard and Poor's? Oh, wait...
Larger sensors will always have a noise and sensitivity advantage to smaller sensors: larger surface area == more photon gathering ability. Also, I'm surprised they cite a four-stop improvement; I thought we were within that range of the quantum limit with current sensors already.
If you are randomly generating your passwords and they are of a decent length then you don't really need to do anything. If your passwords contain lower-case letters only (not recommended), but are eight characters long then your million authentication attempts would represent only a 0.0005% chance of success. If you passwords contain numbers and upper-case characters too, then the likelihood is 1000 times less.
Yes. See http://www.openbsd.org/cgi-bin/man.cgi?query=softraid&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html
Most of the speed gains for high bandwidth x delay networks have been realised in stock OpenSSH already. HPN still does better on very fast long distance networks though.
You do realise that we implemented quite a few speedups for high bandwidth x delay networks already. The remaining "HPN" patches make marginal difference for most networks, other than the patch to allow deactivation of encryption that we refuse to merge at all.
Faster still (and a better cipher):
ssh -o Compression=no -o Ciphers=arcfour256 -o MACs=umac64@openssh.com ...
The umac-64 MAC is only supported by OpenSSH AFAIK (though the spec is available to anyone else who wants to). It is faster and has a better security guarantee than HMAC-MD5 (and is way faster than HMAC-SHA1).
I'd like to thank the OpenBSD project, as well, but I'd also like to point out a few issues.
OpenSSH still won't work with certificates signed by a CA.
Quite right, and we have no intention of incorporating x.509 support. X.509 parsing and verification exposes a large amount of attack surface and all of it is, by necessity, pre-authentication too (the type which, if buggy, allows worms). Read Peter Gurmann's X.509 style guide and see if you ever want to go near this horror again. We have actually written our own minimal RSA verification code to avoid the sort of ASN.1 parsing that is necessary to deal with X.509, and it has saved us from at least seven bugs - some probably exploitable for authentication bypass or remote code execution.
OpenSSH doesn't allow an unencrypted connection (after authentication). Not all CPUs can encrypt/decrypt at 1Gbps.
Yep, we are a _secure_ shell and we take a mildly patriarchal attitude to adding options that can lead to insecure use of OpenSSH. Note that the actual bottleneck in most cases is not the crypto anyway (at least when using arcfour256 as your cipher) but the MAC, and you wouldn't want to switch that off. We do have a very fast MAC though: umac-64
OpenSSH doesn't work - as advertised - with an exclamation point in a "Match" statement.
File a bug, we'll fix it.
Other than that, OpenSSH is possibly one of the most capable and reliable pieces of software I've ever had the privilege to use.
Thanks :)
Nope. Not without 3rd party patches anyway.
Use arcfour256 as your cipher and umac-64@openssh.com as your MAC (ssh -oCiphers=arcfour256 -oMACs=umac-64@openssh.com ...). Between these, CPU is usually not the bottleneck anymore.
We don't support the none cipher because "secure networks" often aren't, and there are already tools that are insecure and go fast.