Um, no. People disable RC4 because it's rubbish. If I may quote GCHQ - a "surprising [...] cryptologic breakthrough" was obtained a few years ago from NSA. We

Um, no. People disable RC4 because it's rubbish. If I may quote GCHQ - a "surprising [...] cryptologic breakthrough" was obtained a few years ago from NSA. We don't know for certain if that referred to an RC4 break specifically, but from context, I think that is the most probable candidate - a bulk cipher they've never used themselves, but widely-deployed internationally (at the time, and still to a large extent) on a huge number of websites largely because of advice to mitigate the BEAST attack (a tricky, active attack) not by switching to TLS 1.2, but by switching to a stream cipher designed in the late 80s for the 8086 that is showing its age poorly. That was probably not good advice. What we do know for sure is that it's in a poor state; worse than any other cipher deployed in mainstream crypto. RC4 is Considered Harmful. Go back and review what you've encrypted with RC4 previously, and evaluate if an eavesdropper could have recorded it and saved it for later when they do have a practical attack, and if so, if that's a problem - because in the state it's in, that is not a theoretical concern, because we know some Nation State Adversaries (cough) certainly do that en masse as general practice. The IETF TLS Working Group have actually had a big discussion about this already - resulting in a live Internet-Draft not merely deprecating, but actively prohibiting RC4's use in TLS, which obtained strong-to-unanimous support in the Working Group and in my opinion will very probably be adopted as a WG document: https://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02 https://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-... - long story short, you MUST NOT use RC4 in TLS, don't even think about negotiating it, kill it with fire. If you're still using it in anything else, consider this your I-told-you-so warning. If you want a replacement, consider ECDHE-RSA-AES128-GCM-SHA256 or - if you want a modern stream cipher that's actually 256-bit secure yet faster in software than RC4 (unless you're on an 8086...) - ECDHE-RSA-CHACHA20-POLY1305: coming to an AEAD stream near you, and already with a draft implementation live in Chrome and on most of Google's properties thanks to agl's patches that more recently have become BoringSSL - but sadly not YouTube's video CDN yet, as the article notes. I couldn't speak for OpenSSH, but I also think your information, or your software, may be out of date. SSHFP DNSSEC records, in particular, have had SHA256 on the Standards Track RFC for two years and change - https://tools.ietf.org/html/rfc6594 https://tools.ietf.org/html/rfc6594