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: "Rank, Mark" <>
  • To: "" <>
  • Subject: [AD-Assurance] RE: RC4 - some positive references
  • Date: Fri, 5 Apr 2013 19:41:54 +0000
  • Accept-language: en-US
  • Authentication-results: sfpop-ironport01.merit.edu; dkim=neutral (message not signed) header.i=none

Jeff:

I like  your proposed references and endorse the suggestion of using it to support an alternate
means proposal. I also feel putting a time limit or a proposed re-evaluation period by the AAC
would be a good addition. 

Personally I think 3 years is a little long without re-evaluation given the increasing performance 
of GPU processors [1] but you do have "until broken" clause as the ultimate arbitrator.

Thanks for your contribution on this.

Regards,
Mark
 


--------------------------------------------------
Mark Rank
Project Manager - Identity & Access Mgt
UCSF Information Technology Services (ITS)
email:
phn:414-331-1476
--------------------------------------------------

From: [] on behalf of Capehart,Jeffrey D []
Sent: Friday, April 05, 2013 11:59 AM
To:
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

http://www.cisco.com/web/about/security/intelligence/nextgen_crypto.html

 

(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                  http://www.ietf.org/rfc/rfc6150.txt

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)

http://www.academia.edu/450208/EVALUATION_OF_THE_RC4_ALGORITHM_AS_A_SOLUTION_FOR_CONVERGED_NETWORKS

 

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?

-Jeff

 

[EXCERPTS for EVALUATION_OF_THE_RC4_ALGORITHM]

“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

http://oia.ufl.edu

 




Archive powered by MHonArc 2.6.16.

Top of Page