Cryptography-Digest Digest #278, Volume #13 Tue, 5 Dec 00 19:13:00 EST
Contents:
NT 4.0 and MD4 Hash ([EMAIL PROTECTED])
Re: newbie: how to persuade my managment not to do our own home-grown encryption?
(Bill Unruh)
Re: Public key encryption in Javascript? ("JustBrowsing")
Re: Revised cipher (Benjamin Goldberg)
Re: Why Galois Fields in Cryptography? (John Myre)
Re: About governments and my ex-relatives in Finland and the U.S.A. ... basically my
ex-spouse had around 350000 US dollars and then my ex-relatives (Finland and US )
collaborated in their efforts to force me to leave the U.S.A. without any of this
money . (Greggy)
Re: About governments and my ex-relatives in Finland and the U.S.A. ... basically my
ex-spouse had around 350000 US dollars and then my ex-relatives (Finland and US )
collaborated in their efforts to force me to leave the U.S.A. without any of this
money ... (Greggy)
Re: Smart Card vs 1.44 Disk ("Michael Scott")
Re: ARCFOUR (RC4) used for CipherSaber-N (Not Amused)
---- Are AES algorithms export restricted? (Greggy)
Re: Smart Card vs 1.44 Disk (Anonymous)
Re: Smart Card vs 1.44 Disk (Greggy)
Re: Global Encryption Policy Statement (Greggy)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: NT 4.0 and MD4 Hash
Date: Tue, 05 Dec 2000 23:01:09 GMT
Please fix the error in my ways.. ;-)
I was under the impression that the NT hash (not the LM hash) was a
straight MD4 hash with no salt value.
A SANS article confirms this at:
http://www.sans.org/infosecFAQ/logon.htm
Using L0phtCrack and a test account with username Administrator,
password "magic" (no quotes).
L0pht Crack reads the values as:
Administrator:"MAGIC":"magic":5B4334DA1FB3A5FBAAD3B435B51404EE:827B5320B
42E9FD95CBB0E63451B701E
LanMan Hash: 5B4334DA1FB3A5FBAAD3B435B51404EE
NT hash: 827B5320B42E9FD95CBB0E63451B701E
However, when I MD4 encrypt the string magic I get the following as a
result:
5982FE41BF9A10BB937BD0AB095192B3
I have tried this several times with various utilities including:
http://www.persits.net/encrypt/demo_hash.asp
The SANS article mentions a unicode convert prior to hashing. I get
the string "6D61676963" from a unicode conversion of magic.
Neither of these values will equate to the L0pht value.
Can someone please tell me where I am going wrong??
Thanks in advance.
Chad
Security Consultant
[EMAIL PROTECTED]
http://www.persits.net/encrypt/demo_hash.asp
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: newbie: how to persuade my managment not to do our own home-grown
encryption?
Date: 5 Dec 2000 23:14:23 GMT
In <QDdX5.385$[EMAIL PROTECTED]> "L.V.S." <[EMAIL PROTECTED]> writes:
]I had stumbled across Mr. Gutmann's library several weeks ago. It looked
]like a good place to get a version of source code, but it still seems to me
]like I will face some of the same licensing issues (e.g. for IDEA) with it.
Just pick the pieces you need. Don't take the whole library. There are a
lot on non-proprietary symmetric key algorithms out there. (eg, ARC4 for
a stream cypher, DES, 3DES, Blowfish, twofish, Rijndhal(?sp) for block
cyphers, RSA for public key). Just don'n impliment the ones that are
proprietary (IDEA, CAST, RC5,...)
]Although of course, now that the patents on DH and RSA have expired, I may
]no longer need to worry about them if I use his code and not the MIT source.
Actually, the international source ( pgp 2.6.2 international which uses
the international RSA library) have no restrictions on them (except
IDEA)
]Is this true?. How would you compare Mr. Gutmann's library with the MIT
]source for PGP? Is it as well tested and used? Is Mr. Gutmann located in
]New Zealand? Do I need to worry about any international import/export
]problems if I make use of his library?
You always have to worry. Those are criminal laws in the various
countries, and have nothing to do with whose library you use or where
you got them from. The USA has loosened their export restrictions, but
for proprietary software they are still there. You will have to get
export permission for your software, probably (talk to good lawyers who
know something about the US encryption export law-- are there more than
two of them?)
]Thanks again!
]-LVS
------------------------------
From: "JustBrowsing" <[EMAIL PROTECTED]>
Subject: Re: Public key encryption in Javascript?
Date: Wed, 6 Dec 2000 01:09:29 +0200
Reply-To: "JustBrowsing" <[EMAIL PROTECTED]>
I had a look at this not so little Lock Nut software.
I really really like it.
Not sure of the hash alg but it clearly uses RSA and DH.
Think it will become very popular.
Well done.
BreakingNews <[EMAIL PROTECTED]> wrote in message
news:909f9t$9ns$[EMAIL PROTECTED]...
>
> If its windows and java you looking for have a look at this package
> Its brilliant!!!
> http://www.kewlstuff.co.za/
> http://www4.50megs.com/johnnyco/
> You can encrypt in HTML pages and send it to an ASP server.
> All in about 20 lines of code, and its easy.
>
>
> <[EMAIL PROTECTED]> wrote in message news:901fjf$lvm$[EMAIL PROTECTED]...
> > Hi. I'm looking for a public key (asymetric) encryption algorythm which
> > is simple enough to implement in javascript. No need for key
> > generation. I don't even think we need decryption in javascript.
> >
> > I've looked around at various crypto libraries and they make my head
> > swim. Then I think about implementing them in braindead-slow
> > javascript...
> >
> > All my work is opensource/GPL.
> >
> > Can anyone point me in a helpful direction?
> >
> > John
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
>
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Revised cipher
Date: Tue, 05 Dec 2000 23:19:03 GMT
Jorgen Hedlund wrote:
>
> >Benjamin Goldberg wrote:
>
> <snip alot>
>
> <snip some more>
>
> For instance this code. What the heck is it doing? It would take a
> cryptoanalyst to decode this gibberish of code. Argh, the code style
> is not even comprehendable, not to me anyway.
Umm, oops? Hey, at least it's better than David Scott's!
I'll add some space and comments.
> Some guidelines to get better comments on your code
> - please add some 'air' into the code. It's suffocating =)
> - use understandable naming conventions on your variables
> - and for G..'s sake, use braces whenever you open a block of code.
>
> ...and ofcourse, a little more comments _in_ the code would
> be great..
Ok, will do. Umm, where don't I use braces around blocks of code?
> /jh
>
> PS! I feel a little mean today, blame my boss =) DS!
>
> > void gb_init() {
> > static int initialized = 0;
Well, I'm sure you can guess what the above thing is for. It's so that
the body of this function never is called more than once. Since this
[and it's use] should be obvious, I won't mention it again.
> > const int polys[8] = {
> > 0xfdbf, 0xf7ef, 0xeff7, 0xdfef, 0xd7ff, 0xb7ff,
> > 0xfff6, 0xfff5 };
These are 8 order-16 primitive polynomials with coefficients in GF(2).
Each one of them defines a finite field in GF(2**16). Since they are
primitive, not just irreducible, 2**x is a generator in each of these
fields. The linear step of the encryption is multiplication of the 8
rows by 2**32, with each row being in one of these 8 fields.
> > uint8 pow[256], log[256];
These are power and logarithm tables for the function 3**x in GF(2**8).
> > int i, j, k;
> > if( initialized ) return;
> > for( i = 0; i < 8; ++i ) {
> > int poly = polys[i], j;
> > for( j = 0; j < 16; ++j )
> > mask[15-j] |= ((poly>>j)&1) << i;
> > }
The above takes the 8 16-bit-polys and turns them sideways :)
This allows the 8 encryption multiplications by 2**32 to be calculated
in parallel.
> > for( i = 0, j = 1; i < 256; ++i ) {
> > log[pow[i] = j] = i;
> > j ^= (j << 1) ^ ((j & 0x80) ? 0x1b : 0);
> > }
Hmm, that should be 0x11b, not 0x1b. Whoops!
Compute 3**x in GF(2^8). pow[x] = 3**x, and log[3**x] = x.
3**x is a generator function in this field.
This is needed for the calculation below.
> > for( i = 0; i < 256; ++i ) {
> > j = i ? pow[255 - log[i]] : 0;
> > k = ((j >> 7) | (j << 1)) ^ ((j >> 6) | (j << 2));
> > j ^= 0x63 ^ k ^ ((k >> 6) | (k << 2));
> > sbox1[sbox0[i] = j] = i;
> > }
Yes, this is indeed very ugly. This loops creates the same sbox as
Rijndael (and it's inverse). How is it doing this? Umm, err, I dunno.
Maybe read the Rijndael paper? I got this stuff out of somebody else's
AES implementation, and simplified it (it was even uglier before!).
> > initialized = 1;
> > }
>
> <snip rest of the code>
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Why Galois Fields in Cryptography?
Date: Tue, 05 Dec 2000 16:26:35 -0700
Dave Seaman wrote:
<snip>
> Or, to put it another way, how can any cipher that is susceptible to the
> bit-flipping attack possibly be a one-time pad?
<snip>
The term "one time pad" is quite often misunderstood. An ideal
pad (uniformly random) provides "perfect secrecy", which means
merely that capture of the ciphertext provides the enemy no
information about the plaintext, except its length. The OTP,
however, provides no authentication at all: if the message is
modified in transit, the reciever has no way to tell. So the
enemy might be able to take advantage of that.
This is sometimes characterized as a "weakness" of the OTP,
but I disagree with this; it has a tendency to perpetuate
the myth that "secrecy" and "security" are identical. One often
sees attempts to "shore up" the "weakness" in OTP, "fixing it"
to protect against this attack or that. The OTP provides perfect
secrecy and zero authentication. Investigate other cryptographic
tools if you have other needs. In particular, it is often the
case that separate tools are used, one for secrecy and a
different (independant) one for authentication.
JM
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Crossposted-To: alt.2600,alt.security
Subject: Re: About governments and my ex-relatives in Finland and the U.S.A. ...
basically my ex-spouse had around 350000 US dollars and then my ex-relatives (Finland
and US ) collaborated in their efforts to force me to leave the U.S.A. without any of
this money .
Date: Tue, 05 Dec 2000 23:33:32 GMT
In article <3a2d4b5b$0$94481$[EMAIL PROTECTED]>,
"Huckleberry Hoshimoto" <[EMAIL PROTECTED]> wrote:
> OK - we're clear on 5 points:
> (1) Your a maste-oid
> (2) You're exactly were you belong (outta HERE)
> (3) Your ex-relatives have some common sense (& are probably
celebrating
> like crazy!)
> (4) You're STILL whining to others who couldn't care less
> (5) You are unclear on the concept of "Subject" vs. "Body Text"
>
> Our response is (or should be):
> "What's your point?"
How did you get ANY of that stuff out of his post? I cannot figure out
what he is saying at all.
>
> "Markku J. Saarelainen" <[EMAIL PROTECTED]> wrote in message
> news:90j1u3$6f9$[EMAIL PROTECTED]...
>
>
--
I prefer my fourth amendment rights over a dope free
society, even if the latter could actually be achieved.
Al Gore and the Florida Robes - More than just another rock group;
a clear and present danger to America's national security.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Crossposted-To: alt.2600,alt.security,comp.security
Subject: Re: About governments and my ex-relatives in Finland and the U.S.A. ...
basically my ex-spouse had around 350000 US dollars and then my ex-relatives (Finland
and US ) collaborated in their efforts to force me to leave the U.S.A. without any of
this money ...
Date: Tue, 05 Dec 2000 23:34:37 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> It is possible to have an ex-spouse. But ex-blood-relatives are a bit
> harder to come by.
>
Is that where you have a complete blood transfusion?
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
>
--
I prefer my fourth amendment rights over a dope free
society, even if the latter could actually be achieved.
Al Gore and the Florida Robes - More than just another rock group;
a clear and present danger to America's national security.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: Smart Card vs 1.44 Disk
Date: Tue, 5 Dec 2000 23:45:26 -0000
"JustBrowsing" <[EMAIL PROTECTED]> wrote in message
news:90jrg4$ic9$[EMAIL PROTECTED]...
> Smart Card vs 1.44 Disk
>
> This is probably a really dumb question but once I get past all the smart
> card marketing, I cant see the advantages of a smart card over a 1.44 disk
> using good crypto techniques.
>
The advantage is quite simple. Smart cards are uncloneable (or thats the
claim anyway). Its certainly a lot easier to copy a diskette. Very poor
marketing that doesn't highlight this simple fact.
Mike Scott
> I keep coming to this conclusion, once data has been securely locked up,
> does it matter what the medium is?
> Does giving the medium a "mind of its own" really make a difference.
>
> Just dont get it!
> For the sake of argument please assume all mediums are equal. For example,
> yes, 1.44 disks get messed up easily, mag stripes cant hold a huge amount
of
> info etc.
> Get past that and tell me why smart card as a medium can do something a
1.44
> disk and PC with reader cant?
>
> I'm thinking about setting up a travel agency voucher system... why must I
> buy expensive smart cards?
>
>
------------------------------
From: [EMAIL PROTECTED] (Not Amused)
Subject: Re: ARCFOUR (RC4) used for CipherSaber-N
Date: 5 Dec 2000 17:48:25 -0600
Yeah, dude. What you're doing is multiple mixes of the state array
which is what you call "mixing the key". Cool VB code.
On Thu, 30 Nov 2000 16:27:44 GMT, [EMAIL PROTECTED] (Glide) wrote:
>Hi Cryptoids. If any of you are familiar with the CipherSaber
>implementation of RC4 and you would care to enlighten me, I'd
>appreciate it. Since I do my thing in Visual Basic, it will look
>fairly different from the usual suspects (C code).
>
>If you are so inclined, please comment to this here in the newsgroup
>since my e-mail address is fraudulent.
>
>I use a Visual Basic version of ARCFOUR. I tried it against
>thevectors that were published with "alleged RC4" and it passes. I
>added support for CipherSaber (part of which will not show in the
>following code) and would like to correctly implement CipherSaber-n
>where n is the number of times you mix the key. I'm not sure I'm
>doing it in the right spot. If you wouldn't mind, would you comment
>on where I propose to mix the key "n" times? Here is the code:
>
>' *** Begin ARCFOUR Function ***
>
>Public Function ARCFOUR(inp As String, key As String) As String
>
>Dim S(0 To 255) As Byte, K(0 To 255) As Byte, i As Long
>Dim j As Long, temp As Byte, Y As Byte, x As Long, z as long
>Dim Outp As String
>Dim n as long
>
>' Array/S-box is setup for ARCFOUR
>
>For i = 0 To 255
> S(i) = i
>Next
>
>j = 1
>For i = 0 To 255
> If j > Len(key) Then j = 1
> K(i) = Asc(Mid(key, j, 1))
> j = j + 1
>Next i
>
>' end of setup
>
>
>'*** This is where I'm mixing the key "n" times
>'*** If n = 1 then it is standard CipherSaber
>'*** This example shows CipherSaber-2
>
>'*** beginning of part 1 of added code
>n = 2
>For z = 1 to n
>'*** end of part 1 of added code
>
>
>' This is where I believe the key is mixed for ARCFOUR
> j = 0
> For i = 0 To 255
> j = (j + S(i) + K(i)) Mod 256
> temp = S(i)
> S(i) = S(j)
> S(j) = temp
> Next i
>
>' end of key mixing
>
>
>'*** beginning of part 2 of added code
>Next z
>'*** end of part 2 of added code
>
>
>
>' encryption part of ARCFOUR
>
>i = 0
>j = 0
>For x = 1 To Len(inp)
> i = (i + 1) Mod 256
> j = (j + S(i)) Mod 256
> temp = S(i)
> S(i) = S(j)
> S(j) = temp
> t = (S(i) + (S(j) Mod 256)) Mod 256
> Y = S(t)
>
> Outp = Outp & Chr(Asc(Mid(inp, x, 1)) Xor Y)
>Next
>
>' end of encryption
>
>ARCFOUR = Outp
>
>End Function
>
>' *** End ARCFOUR Function ***
>
>*** Important *** - This code does not show generation or handling
>of the CipherSaber ten-byte vector which is appended to the key and
>will be prepended to the encrypted data.
>
>Thank you.
>
>Glide
>
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: ---- Are AES algorithms export restricted?
Date: Tue, 05 Dec 2000 23:39:57 GMT
It just seemed to me as I was reading another post here that none of
the AES algorithms could possibly be export restricted from within the
US since they were all published during the AES contest. Am I
correct? Or did I miss something in my thinking here?
--
I prefer my fourth amendment rights over a dope free
society, even if the latter could actually be achieved.
Al Gore and the Florida Robes - More than just another rock group;
a clear and present danger to America's national security.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: Smart Card vs 1.44 Disk
Date: Tue, 5 Dec 2000 15:48:55 -0800
From: Anonymous <[EMAIL PROTECTED]>
JustBrowsing <[EMAIL PROTECTED]> wrote in message
news:90jrg4$ic9$[EMAIL PROTECTED]...
> Smart Card vs 1.44 Disk
>
> This is probably a really dumb question but once I get past all the smart
> card marketing, I cant see the advantages of a smart card over a 1.44 disk
> using good crypto techniques.
>
> I keep coming to this conclusion, once data has been securely locked up,
> does it matter what the medium is?
> Does giving the medium a "mind of its own" really make a difference.
One big difference. A smart card can Prove something by what it can do with
a secret that it has. In effect, it can prove knowledge of the secret without
revealing it.
A dumb disk can only hand you the secret and say "See!" unfortunately,
it's not secret any more.
Example: (Real simple and not a real protocol) Say I want to accept an ID from
someone and I don't want to let them just replay something they have recorded
previously. I generate a random number, encrypt it with a key that the person
MUST know, and send them the ciphertext. That person decrypts it, inverts it and
re-encrypts it and hands it back.
If I decrypt the message and it is the inverse of what I sent, then I have a
pretty
good idea that this person has that key. It can't be a replay of a previous
session because
I pick the content to be encrypted. Neither of us reveal the secret. This is not
how
smart cards work but it does show how they can do different things.
Paul
>
> Just dont get it!
> For the sake of argument please assume all mediums are equal. For example,
> yes, 1.44 disks get messed up easily, mag stripes cant hold a huge amount of
> info etc.
> Get past that and tell me why smart card as a medium can do something a 1.44
> disk and PC with reader cant?
>
> I'm thinking about setting up a travel agency voucher system... why must I
> buy expensive smart cards?
>
>
--------== Posted Anonymously via Newsfeeds.Com ==-------
Featuring the worlds only Anonymous Usenet Server
-----------== http://www.newsfeeds.com ==----------
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: Smart Card vs 1.44 Disk
Date: Tue, 05 Dec 2000 23:51:43 GMT
In article <90jrg4$ic9$[EMAIL PROTECTED]>,
"JustBrowsing" <[EMAIL PROTECTED]> wrote:
> Smart Card vs 1.44 Disk
>
> This is probably a really dumb question but once I get past all the
smart
> card marketing, I cant see the advantages of a smart card over a 1.44
disk
> using good crypto techniques.
>
> I keep coming to this conclusion, once data has been securely locked
up,
> does it matter what the medium is?
> Does giving the medium a "mind of its own" really make a difference.
>
> Just dont get it!
> For the sake of argument please assume all mediums are equal. For
example,
> yes, 1.44 disks get messed up easily, mag stripes cant hold a huge
amount of
> info etc.
> Get past that and tell me why smart card as a medium can do something
a 1.44
> disk and PC with reader cant?
>
> I'm thinking about setting up a travel agency voucher system... why
must I
> buy expensive smart cards?
>
>
You know, that is a very good question.
--
I prefer my fourth amendment rights over a dope free
society, even if the latter could actually be achieved.
Al Gore and the Florida Robes - More than just another rock group;
a clear and present danger to America's national security.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Crossposted-To: alt.security,comp.security,alt.2600
Subject: Re: Global Encryption Policy Statement
Date: Tue, 05 Dec 2000 23:52:41 GMT
In article <90gcg5$1a3$[EMAIL PROTECTED]>,
Markku J. Saarelainen <[EMAIL PROTECTED]> wrote:
>
>
> Global Encryption Policy Statement
>
> "All electronic commerce applications require various security
> solutions implemented. Encryption has become one of the most important
> elements in any e-commerce product and service. It is highly
> recommended that we decline to accept any terms and requirements in
the
> Wassenaar or other international encryption agreements that are
> limiting the global access to these technologies. It is essential that
> we support the strongest cryptography in all commercial transactions,
> Internet communications, voice and fax communications and other
> processes globally. The role of the Internet is already critical for
> basic operations of any international enterprise and institution,
which
> further increases the level of the need for the strongest encryption
> technologies. We must also decline to accept the protection using
> specific standards such as the AES (Advanced Encryption Standard) that
> have been developed and then tested through U.S. governmentally
> coordinated processes. However, still today too many people are using
> no encryption and email their business communications over the
Internet
> without any communication security. This is like sending your
> confidential business plans on open postcards without any envelops.
> This lack of basic security implementations has made too many
> corporations extremely vulnerable. It is the common public knowledge
> that some specific intelligence agencies such as the CIA, FBI and NSA
> are using the Internet and other electronic intelligence collection
> methods to acquire and collect specific technology, business and
> commercial intelligence for specific U.S. corporations, businesses and
> institutions. Some of the most popular encryption products and
> development processes have been supported and influenced by the U.S.
> military, the NSA, the CIA and other U.S. intelligence agencies. One
of
> these applications is the well-known encryption product that became
> very popular in early 1990's. The U.S. involvement in development
> phases of many encryption products and APIs (Applications Programming
> Interface) is an element of a broader covert intelligence operation
> planned and implemented by the NSA. In the future's electronic
> commerce environment these encryption methods and technologies shall
> become ever more important for many corporations around the globe and
> it is highly recommended to avoid using any free and publicly non-
> commercially available encryption products and applications. We must
> also realized that many U.S. cryptography companies are or have been
> influenced by the U.S. government and the NSA."
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Do you even understand the issues?
--
I prefer my fourth amendment rights over a dope free
society, even if the latter could actually be achieved.
Al Gore and the Florida Robes - More than just another rock group;
a clear and present danger to America's national security.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
