fyi: NSA Releases UK Crypto Docs

From: cryptomeearthlink.net
Subject: NSA Releases UK Crypto Docs
To: ukcryptochiark.greenend.org.uk
Date: Fri, 02 Mar 2007 06:11:39 -0800


NSA has released under FOIA nine crypto docs in response to
a request
for information on "Non-Secret Encryption" and JH
Ellis. One is a formerly
secret paper by Ellis written in 1977. Another is a formerly
confidential
paper by Clifford Cocks written in 1998. Ellis and Cocks
were long
associated with CESG.

Three of the nine papers were formerly classified as Top
Secret Codeword.


http://cry
ptome.org/nsa-nse/nsa-nse-01.htm



----------

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

Hi gang,

On recent consulting gig, I came across what I think is a 
potential vulnerability and wanted to see how crazy my
thinking is.

Without mentioning the exact place or piece of software
because 
of NDAs, here is the basic scenario.

The tool stores the hex version of the remote access
password in 
a field that is visible to the end user. The default setting
of 
the software is that if you enter ASCII into the field, it
will 
calculate the hex version and display it. At this site the
sys 
admins have decided that this is not a user settable field
so 
once set the user can not change it except with the help of
an 
admin. There is also no policy in place to require periodic

password changes.

Also every user in the entire enterprise has this field
visible 
in their LDAP address information that anyone in the company
can 
access at any time. The address info also contains the user
name 
for logging onto the network. The password for remote access

appears to be the same as the password for logging onto the

machine even when it it not connected to the domain.

Next, trial versions of the software are available that
still 
have the default setting where the user can enter any
password 
and the hex value will be shown. As to the password
algorithm 
itself, I don't know what it is. I don't know if it uses an
IV 
that changes for every password that is entered, but that
would 
be easy to check with the trial version. What research I've
done 
says that it is derived from AES128 and it is a fixed field

length. There is more than a bit of security by obscurity at
play 
here.

So it seems to me this is vulnerable to a know text attack:
i.e., 
enter "known password 1" get back "hex value
1", etc. By hand it 
would take a while to build a list of equivalences, but I
assume 
that a clever perl hacker, which I'm not, could code a
widget 
that would automate this, taking a common dictionary such as
from 
Cain & Abel, John the Ripper or some such, and fairly
quickly 
build a list of password/hex pairs. With this list in hand
an 
insider bent on industrial espionage could find the weak 
passwords of sys admins and logon as them and do whatever 
nefarious deeds they wish.

My questions are: A) is this as vulnerable as it seems at
first 
blush? B) how many password/hex pairs would be needed to
deduce 
the underlying algorithm?, C) If one could deduce the
algorithm, 
could the attack be generalized so that it could be used
against 
other enterprises that use the same software? (It is very(!)

widely deployed), and D) am I missing something in my
thinking?

Thanks,

Allen

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

On Sat, Mar 03, 2007 at 04:09:36AM -0800, Allen wrote:

> On recent consulting gig, I came across what I think is
a 
> potential vulnerability and wanted to see how crazy my
thinking is.
> 

If you are not a security consultant hired to find and close
this type
of vulnerability, and don't want to follow in the footsteps
of Randal
L. Schwartz, it is sadly best to stay ignorant of such
matters...

-- 

 /" ASCII RIBBON                  NOTICE: If received
in error,
  / CAMPAIGN     Victor Duchovni  please destroy and
notify
  X AGAINST       IT Security,     sender. Sender does not
waive
 /  HTML MAIL    Morgan Stanley   confidentiality or
privilege,
                                   and use is prohibited.

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

> My questions are: A) is this as vulnerable as it seems
at first  
> blush? B) how many password/hex pairs would be needed
to deduce the  
> underlying algorithm?, C) If one could deduce the
algorithm, could  
> the attack be generalized so that it could be used
against other  
> enterprises that use the same software? (It is very(!)
widely  
> deployed), and D) am I missing something in my
thinking?

A) yes it is vulnerable. B) none - it would take no time to
reverse  
engineer the entire algorithm out of the executable. C) yes
of  
course. D) just how bad this is.

Ruptor

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

the hex value stored is perhaps a hash, or even better, a
salted hash,
or even better, a keyed salted hash which is then
hex-encoded.  any
discussion of unix password cracking will describe the first
two.
(i think even the original doug mcilroy paper)

all are vulnerable to dictionary and brute force attacks.
an unsalted hash also reveals what two users have the same 
password as their hashes are the same.

yes, you could also precompute hash values instead of using
attacks
which enumerate the values and their hashes. 

if the hash is sent to a counterparty to authenticate the
user (to make
unnecessary  their typing a password) it has the same
protective power
as a plaintext password.   if you have the hash, you can
pretend to be 
the user in any situation which accepts the hash as an
authenticator.

the only value of such a hash is to obscure the password and
to make less
likely that someone with the hash can take advantage of the
user using the
same plaintext password in other circumstances.  

this is the main reason why static authenticators such as
passwords
should generally not be reused, or, for that matter, used at
all for
high value asset protection.



On Sat, Mar 03, 2007 at 04:09:36AM -0800, Allen wrote:
> Hi gang,
> 
> On recent consulting gig, I came across what I think is
a 
> potential vulnerability and wanted to see how crazy my
thinking is.
> 
> Without mentioning the exact place or piece of software
because 
> of NDAs, here is the basic scenario.
> 
> The tool stores the hex version of the remote access
password in 
> a field that is visible to the end user. The default
setting of 
> the software is that if you enter ASCII into the field,
it will 
> calculate the hex version and display it. At this site
the sys 
> admins have decided that this is not a user settable
field so 
> once set the user can not change it except with the
help of an 
> admin. There is also no policy in place to require
periodic 
> password changes.
> 
> Also every user in the entire enterprise has this field
visible 
> in their LDAP address information that anyone in the
company can 
> access at any time. The address info also contains the
user name 
> for logging onto the network. The password for remote
access 
> appears to be the same as the password for logging onto
the 
> machine even when it it not connected to the domain.
> 
> Next, trial versions of the software are available that
still 
> have the default setting where the user can enter any
password 
> and the hex value will be shown. As to the password
algorithm 
> itself, I don't know what it is. I don't know if it
uses an IV 
> that changes for every password that is entered, but
that would 
> be easy to check with the trial version. What research
I've done 
> says that it is derived from AES128 and it is a fixed
field 
> length. There is more than a bit of security by
obscurity at play 
> here.
> 
> So it seems to me this is vulnerable to a know text
attack: i.e., 
> enter "known password 1" get back "hex
value 1", etc. By hand it 
> would take a while to build a list of equivalences, but
I assume 
> that a clever perl hacker, which I'm not, could code a
widget 
> that would automate this, taking a common dictionary
such as from 
> Cain & Abel, John the Ripper or some such, and
fairly quickly 
> build a list of password/hex pairs. With this list in
hand an 
> insider bent on industrial espionage could find the
weak 
> passwords of sys admins and logon as them and do
whatever 
> nefarious deeds they wish.
> 
> My questions are: A) is this as vulnerable as it seems
at first 
> blush? B) how many password/hex pairs would be needed
to deduce 
> the underlying algorithm?, C) If one could deduce the
algorithm, 
> could the attack be generalized so that it could be
used against 
> other enterprises that use the same software? (It is
very(!) 
> widely deployed), and D) am I missing something in my
thinking?
> 
> Thanks,
> 
> Allen
> 
>
------------------------------------------------------------
---------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

     --
 >> My questions are: A) is this as vulnerable as it
 >> seems at first blush? B) how many password/hex
pairs
 >> would be needed to deduce the underlying
algorithm?,
 >> C) If one could deduce the algorithm, could the
 >> attack be generalized so that it could be used
 >> against other enterprises that use the same
software?
 >> (It is very(!) widely deployed), and D) am I
missing
 >> something in my thinking?

 > A) yes it is vulnerable. B) none - it would take no
 > time to reverse engineer the entire algorithm out of
 > the executable. C) yes of course. D) just how bad
this
 > is.

  Concerning B:  If the implementors of the system had
half a brain, they probably did something reasonable to
generate the hex, such as hashing the password with a
large secret, in which case no number of password hex
pairs will reveal the algorithm.

By and large, security systems that are covered by an
NDA are covered by an NDA because they are not very
good, and the seller of the system intends to send
anyone to jail who widely publicizes the fact that they
are not very good.

Approach with care.

     --digsig
          James A. Donald
      6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
      MGjeTFQKB0Wa89CvalWg8qz/BAWRAwDEUL0m4Kkn
      4VpuVXjmJfOnK1OLnn3wsm24Y9ES8GObzFkOVY4XV

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

Allen wrote:
> Hi gang,
> 
> On recent consulting gig, I came across what I think is
a potential
> vulnerability and wanted to see how crazy my thinking
is.
> 
> Without mentioning the exact place or piece of software
because of NDAs,
> here is the basic scenario.
> 
> The tool stores the hex version of the remote access
password in a field
> that is visible to the end user. The default setting of
the software is
> that if you enter ASCII into the field, it will
calculate the hex
> version and display it. At this site the sys admins
have decided that
> this is not a user settable field so once set the user
can not change it
> except with the help of an admin. There is also no
policy in place to
> require periodic password changes.
> 
> Also every user in the entire enterprise has this field
visible in their
> LDAP address information that anyone in the company can
access at any
> time. The address info also contains the user name for
logging onto the
> network. The password for remote access appears to be
the same as the
> password for logging onto the machine even when it it
not connected to
> the domain.
> 
> Next, trial versions of the software are available that
still have the
> default setting where the user can enter any password
and the hex value
> will be shown. As to the password algorithm itself, I
don't know what it
> is. I don't know if it uses an IV that changes for
every password that
> is entered, but that would be easy to check with the
trial version. What
> research I've done says that it is derived from AES128
and it is a fixed
> field length. There is more than a bit of security by
obscurity at play
> here.
> 
> So it seems to me this is vulnerable to a know text
attack: i.e., enter
> "known password 1" get back "hex value
1", etc. By hand it would take a
> while to build a list of equivalences, but I assume
that a clever perl
> hacker, which I'm not, could code a widget that would
automate this,
> taking a common dictionary such as from Cain &
Abel, John the Ripper or
> some such, and fairly quickly build a list of
password/hex pairs. With
> this list in hand an insider bent on industrial
espionage could find the
> weak passwords of sys admins and logon as them and do
whatever nefarious
> deeds they wish.

That's a very dubious analysis. If the obfuscated password
(I hesitate
to say encrypted in the face of an unknown algorithm)
contains salt
(i.e. what you called an IV), then this technique will not
work.

Of course, all good password obfuscators should include
sufficient salt
that this attack doesn't work.

> 
> My questions are: A) is this as vulnerable as it seems
at first blush?
> B) how many password/hex pairs would be needed to
deduce the underlying
> algorithm?, C) If one could deduce the algorithm, could
the attack be
> generalized so that it could be used against other
enterprises that use
> the same software? (It is very(!) widely deployed), and
D) am I missing
> something in my thinking?
> 
> Thanks,
> 
> Allen
> 
>
------------------------------------------------------------
---------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com
> 
> 


-- 
http://www.apache-
ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he
can go if he
doesn't mind who gets the credit." - Robert Woodruff

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com