Skip to Content.
Sympa Menu

ad-assurance - [AD-Assurance] RE: RC4 - some positive references

Subject: Meeting the InCommon Assurance profile criteria using Active Directory

List archive

[AD-Assurance] RE: RC4 - some positive references

Chronological Thread 
  • From: "Capehart,Jeffrey D" <>
  • To: "" <>
  • Subject: [AD-Assurance] RE: RC4 - some positive references
  • Date: Wed, 10 Apr 2013 20:46:15 +0000
  • Accept-language: en-US
  • Authentication-results:; dkim=neutral (message not signed) header.i=none

Nice find on RFC 6649, Eric!  The 2015 date also fits in with a time-limited exception to approved algorithm (2-3 years).


I was also bothered by the “lack of spell checking” in the academic document, but hopefully that isn’t an indictment on the quality of the testing, evaluation, and conclusion.


Is there a place where someone can document RC4 and/or RC4-HMAC?  It is not just Microsoft/AD that could benefit.  I’ve seen RC4 in SSL.  Kerberos might use RC4-HMAC.  There could be many reasons to give RC4 temporary alternative means.


Ultimately, if SYSKEY can encrypt the PEK and the password store in AD, and syskey is RC4, then things are looking better for AD!


Ann- should this be a proposed alt-means similar to the end-user use of non-compliant technologies (under Working Docs)?


Perhaps the document could be a template requiring each institution to fill out where RC4 or RC4-HMAC is being used, and document the risk for each.  The only problem I can see is using “RC4 hasn’t been broken yet” as a risk mitigation.  Perhaps better would be to say [something] will be disabled if RC4 is broken.


A brief table of these excerpts, sources, and strength of statement, would give a great summary of the alternative means proposal.


Any takers?



From: [mailto:] On Behalf Of Eric Goodman
Sent: Wednesday, April 10, 2013 4:16 PM
Subject: [AD-Assurance] RE: RC4 - some positive references


These seem reasonable conclusions. (Though I must say I’m put off by the glaring typos in the flowchart describing how RC4 works in the last paper!)


While looking at the RFCs, I also ran across RFC 6649 – a “Best Current Practices” RFC – which deprecates the use of DES and RC4-HMAC-EXP (export strength, or small key size variant of RC4-HMAC) as “weak”, but not RC4-HMAC.


We may want to add this one to the list of references. 6649’s endorsement of RC4-HMAC is notably less “ringing” than the 6150’s, but the RFC appears to be about 15 months newer (July 2012 vs Mach 2011), so may be good just to reiterate the currency of the recommendation.


This document does not add any sort of requirement for conforming implementations to implement RC4-HMAC(23).


“The main reason to not actively discourage the use of RC4-HMAC is that it is the only encryption type that interoperates with older versions of Microsoft Windows once DES and RC4-HMAC-EXP are removed. These older versions of Microsoft Windows will likely be in use until at least 2015.”


--- Eric





From: [] On Behalf Of Capehart,Jeffrey D
Sent: Friday, April 05, 2013 12:00 PM
Subject: [AD-Assurance] RC4 - some positive references


Although NIST has not approved RC4 as a cryptographic algorithm, and yet it is widely used in industry, surely there must be something that gives 128-bit RC4 some quality of “secure” that would be equivalent to the approved algorithms.


I found three authoritative references on RC4:


#1:  CISCO – Next Generation Encryption


(Their “Recommendations for Cryptographic Algorithms” refers to RC4 as legacy, with mitigation being “key schedule is important”.  Note:  They also refer to 3DES, SHA-1, and HMAC-MD5 as legacy with mitigation.  The key here is that although they are legacy, they are not on the AVOID list.)


#2: Internet Engineering Task Force RFC on MD4, MD5        

The RC4-HMAC is supported in Microsoft's Windows 2000 and later versions of Windows for backwards compatibility with Windows 2000.  As [RFC4757] stated, RC4-HMAC doesn't rely on the collision resistance property of MD4, but uses it to generate a key from a password, which is then used as input to HMAC-MD5. For an attacker to recover the password from RC4-HMAC, the attacker first needs to recover the key that is used with HMAC- MD5.  As noted in [RFC6151], key recovery attacks on HMAC-MD5 are not yet practical.                                                                       


#3:  Academic Evaluation of RC4 Algorithm for Networks (See excerpts below)


The conclusion is good news.  The testing appears to be sound.  And, it happens to also be another .EDU which may or may not matter.  Consider a “converged” network to just be a network.  I do not think the qualification is restrictive for the security evaluation.                                       


I offer these for your consideration in defining an Alternative Means for RC4 to be at least equivalent to an approved algorithm.  I would encourage others to read through and see if there is agreement on the points I made. 


If this is sufficient to give RC4 alternative means (either on its own, in limited situations, or in combination with Active Directory alternative means) it would probably be very helpful.  I have mostly seen the RC4-HMAC cipher suites with Kerberos, but RC4 is also used in

(RC4 128, RC4-HMAC, ARCFOUR-HMAC).  The 40-bit key RC4 algorithms should be considered weak and not equivalent.  Perhaps a time-limited approval such as 3 years with re-evaluation, or removed if cracked?




“We will apply the NIST suite of statistical tests to RC4 output to test its randomness and security. The testing results illustrates that RC4 is secure and random enough to be used within the converged network.”


“In this paper we discussed the security problems of the converged networks. RC4 algorithm was introduced as a solution for converged networks security problems. NIST statistical test suite was used to test the security of RC4 algorithm running over converged networks, all traffic types that are running over converged networks (video, audio, image and text) were tested after encrypting them with RC4, the resulted sequences passed all the statistical tests with high values, which indicates high statistical properties for all of them.  As a result RC4 sequences are random and can’t be predicted. Hence RC4 is applicable with converged networks traffic, and can work as a security solution for them, with a very fast performance and strong degree of security.”


“Many papers have been published analyzing methods of attacking RC4. None of these approaches is practical against RC4 with a reasonable key length, such as 128 bits. A more serious problem is reported in [8].”

[8] Weakness in the Key Scheduling Algorithm of RC4, in Proceedings, Workshop in Selected Areas of Cryptography, 2001



Jeff Capehart, CISA
IT Audit Manager
University of Florida - Office of Internal Audit
(352) 273-1882


Archive powered by MHonArc 2.6.16.

Top of Page