Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
What about things like: arcfour128,arcfour256,arcfour ?
So how to protect myself ?
Posted Nov 20, 2008 21:24 UTC (Thu) by jengelh (subscriber, #33263)
This is paranoia. Or just good sense. I have not yet come across an SSH implementation that does not do AES-256-CTR, and should I, I'd replace it with something that does. putty, openssh, you name it.
# grep Ciphers sshd_config
Posted Nov 21, 2008 16:08 UTC (Fri) by drag (subscriber, #31333)
What point is there in using anything else, really?
For my local Lan typically I'll disable compression and use arcfour.
Posted Nov 27, 2008 18:43 UTC (Thu) by mikachu (guest, #5333)
Posted Nov 27, 2008 22:44 UTC (Thu) by kasperd (guest, #11842)
Supposedly CTR is more secure (for reasons that may be completely unrelated to this vulnerability). But CTR is only more secure if your IV is generated properly. If you were for whatever reason going to reuse an IV, it would weaken CTR a lot more than it would to CBC. However since the symmetric keys are just session keys, such a vulnerability is highly unlikely to exist in ssh. The risk of improper use of IVs for CTR is more of an issue when you have long lived symmetric keys (storage encryption).
I am still not convinced that there even is a vulnerability in ssh. Given the information made available so far, the whole thing could be a canard.
Posted Nov 23, 2008 22:04 UTC (Sun) by djm (subscriber, #11651)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds