Cryptography-Digest Digest #169, Volume #10 Fri, 3 Sep 99 18:13:04 EDT
Contents:
Re: Schneier/Publsied Algorithms (Anonymous)
Cracked ? ("B3avis")
Re: Implementing crypto algorithms in Fortran. ("Douglas A. Gwyn")
Re: THINK PEOPLE (David A Molnar)
Re: Home Invasion Bill Drives U.S. Computer Users across border (David A Molnar)
Re: IDEA- safe? (jerome)
Re: Alleged NSA backdoor in Windows CryptoAPI (Lee K. Gleason)
Does SSL use RSA Keys? ([EMAIL PROTECTED])
Re: SQ Announcement (David Wagner)
Re: Alleged NSA backdoor in Windows CryptoAPI (Frank Gifford)
Re: Schneier/Publsied Algorithms (Eric Lee Green)
Re: Alleged NSA backdoor in Windows CryptoAPI ("Steven Alexander")
Re: THINK PEOPLE (SCOTT19U.ZIP_GUY)
Re: Description of SQ (David Wagner)
Re: MD5 source code in VC++ or asm? (Paul Koning)
----------------------------------------------------------------------------
Date: Fri, 3 Sep 1999 22:01:11 +0200
From: Anonymous <[EMAIL PROTECTED]>
Subject: Re: Schneier/Publsied Algorithms
One of the posts in this thread refers to Bugs in Windows NT...yes there are bugs in
Windows NT..but its a v. large op. sys. Millions of lines of code....2fish is a very
small apps..maybe 2-3k lines of code....
OK...Now we see some Test Vectors appeaing on the counterpane.com web site...with no
documentaion...
Checking the source code when I last downloaded and now....the header in twofish.c
still reads version 1. April '98 by the same guy...Hi/fn ...whoever that is...
So contrary to what people are saying here in this thread....that the bugs are listed
in the counterpane web site and the source code is constantly updated....that is NOT
TRUE....
What we have here is a piece of code written by a guy who is not even from Counterpane
systems.....and the CODE has not Changed for 16 MONTHS.....
Come on....WHo are you kidding....
Do you expect us to believe that this download is a professional product rteady for
commercial use....I dont think so....
So if we are a commercial organisation...is there another deal on offer....I mean
....here is a free Source code on our web site...take it or leave it...we cant really
tell you much about its roubstness....But if you want a commercial deal...well you can
have THIS....oh yes..we have this for you...and this stuff on the web site is just a
load of crap smilling and looking over while the ink dries up on the cheque...
I mean...this stuff on the website cant be the real thing....Is it Real Coke or
Classic Coke????
I would not even consider using it in an Commercial Apps....Its just badlz wriiten
piece of crap
Wolfman
------------------------------
From: "B3avis" <[EMAIL PROTECTED]>
Subject: Cracked ?
Date: Fri, 3 Sep 1999 22:18:42 +0200
Hey there,
I was wondering... Can someone give me a list or tell me where to find it of
all common encryption-algoritms that are cracked and the ones that aren't
cracked yet ?
Thanks in advance, B3avis
http://come.to/bchicken
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Implementing crypto algorithms in Fortran.
Date: Fri, 3 Sep 1999 17:48:31 GMT
"SCOTT19U.ZIP_GUY" wrote:
> ... IF the machine your on uses 2's complimnet
> arithmetic then you can use signed numbers as unsigned.
Only if overflow does not trigger an exception.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: THINK PEOPLE
Date: 3 Sep 1999 20:18:20 GMT
Frank Gifford <[EMAIL PROTECTED]> wrote:
> If you don't have the final 100 bytes of the target encrypted message, how
> do you know that they are identical to the last 100 bytes of some other
> message?
David Scott's scenario was three messages for three people, with the only
differences being in the middle, and the plaintext for two of the messages
known.
-David
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy.anon-server
Subject: Re: Home Invasion Bill Drives U.S. Computer Users across border
Date: 3 Sep 1999 20:16:29 GMT
In sci.crypt [EMAIL PROTECTED] wrote:
> Hasn't been 'real' so far.
> I've been seeing stuff about this Zero-Knowledge Systems for a year.
> I know people who are associated with them.
> I've seen no product.
Beta test is running now.
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: IDEA- safe?
Date: 3 Sep 1999 20:34:58 GMT
Reply-To: [EMAIL PROTECTED]
typo, replace 4.5months by 4.5years
On 3 Sep 1999 19:03:28 GMT, jerome wrote:
>
>and these attacks can use the key even if they are different than
>brute force...
>
>moreover if currently everybody says that 56bits is easy to reach, 64bits
>is only 256 times more, so in 4.5months 64bits would be as easy as
^^^^^^^^^
4.5 years obviously
>56bits now, according to the principle "the cpu power double every 18months"
------------------------------
From: [EMAIL PROTECTED] (Lee K. Gleason)
Subject: Re: Alleged NSA backdoor in Windows CryptoAPI
Date: 3 Sep 99 14:57:54 CST
In article <[EMAIL PROTECTED]>, Stephan Eisvogel
<[EMAIL PROTECTED]> writes:
>
> There's a couple of possibilities what _NSAKEY really means:
>
> b) some MS-programmer's prank (not funny)
> c) 2nd MS key in case first one is compromised only with a
> funny label
You know, I wouldn't rule the joke/funny explanations out. It's happened
before, in VMS. Their symbols for things security related often had
"funny" symbols and abbreviations, like KGBs (Key Grant Blocks), CIAs
(Covert Intrusion Analysis), and NSA (something Security Auditing, I
forget what the N "stood" for). 'Course, the fully commented sources for
(almost all) of VMS is/was widely available, so everyone could see that
these things were not use for covert purposes.
Lee K. Gleason N5ZMR
Control-G Consultants
[EMAIL PROTECTED]
------------------------------
Date: Fri, 03 Sep 1999 14:59:07 -0500
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Does SSL use RSA Keys?
To all that have a clue,
Please don't laugh if my knowledge level is a little low, but please
help clarify two points. I know you folks out there know the answers.
1. Does SSL use RSA keys?
2. In SSL, is the key re-generated each time a browser initiates a
session?
i.e. if someone has the "crack" for a certain key, can they then decrypt
all messages coded with that key?
What started all this? An very lame article I read said that the 512
bit RSA
encryption module had been cracked. The headline of the article said
that "the standard used to encrypt financial transactions on the
Internet is no longer secure."
My impression was that the RSA keys are used in PGP and a lot of VPN
networks, and that the SSL keys are not the same.
Please clarify.
Thanks,
Michael Sorbera
Webmaster
Randolph-Brooks Federal Credit Union
"In the land of the clueless, he who has half a clue is King!"
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: SQ Announcement
Date: 3 Sep 1999 13:47:31 -0700
In article <7qo4oi$[EMAIL PROTECTED]>,
Kostadin Bajalcaliev <[EMAIL PROTECTED]> wrote:
> I have read Shannon theories, just compare my and your claim:
>
> If we need more information than the output carry about them inner state of
> the generator ...
>
> when the output keystream length is longer than the key length, the
>
> I do not see any logical conection.
My point is that, if the stream cipher uses a N-bit key, then we
need only N bits of information about the cipher to deduce the inner
state, total.
Thus, by looking at N bits of output, we are guaranteed to have enough
aggregate information to break the cipher (if there are no bounds on
our computing power).
I believe this means that the "Information Lose" theory does not apply
to any cipher which generates more than N bits of output: if more than
N bits of information about the output are available, then the output
carries enough information about the internal state to break the generator,
and thus the "Information Lose" theory cannot be applied to the cipher.
Am I interpreting the "Information Lose" theory correctly, or am I confused?
> Mr. Wagner I am not expert in cryptography, but I am certainly not newby
> asking what is cryptography. I know what I am talking about. The thesis is
> not a dream that I have solved all the problems, before it was written I
> have read specification and analysis of most of the Stream Ciphers. Sq1 is
> very similar with RC4, that is not a coincidence, RC algorithms are one of
> the most interesting designs known now, at list I think so. I have tried as
> much as I can to extract the common from secure ciphers and to define theory
> why they are secure at first place.
Ok. It probably is just a communication problem.
It certainly sounds like you are tackling the right problems. If we
had a theory that could provide proofs of security (or design principles)
for RC4-like ciphers, that would be extremely interesting.
However, I don't yet understand how the theory you are describing works.
Again, this may be just a communications problem.
------------------------------
From: [EMAIL PROTECTED] (Frank Gifford)
Subject: Re: Alleged NSA backdoor in Windows CryptoAPI
Date: 3 Sep 1999 15:35:43 -0400
In article <[EMAIL PROTECTED]>,
DJohn37050 <[EMAIL PROTECTED]> wrote:
>The obvious reason for an NSA key (assuming that is what it is) is to allow NSA
>to write their own CSP's without needing to get permission from Microsoft.
>That is, they can put in their algorithms without going to Microsoft for
>approval. But the CSP still needs to be put on the machine somehow and this is
>a voluntary act (as far as I know), so I do not see anything nefarious.
Taking this at face value (i.e. something signed by NSA can be put in as a
cryptographic primitive), there is the possibility that with a wiretap order
in hand that your computer could have a subverted algorithm or key selection
process put in without your knowledge. Now, they may have a search warrant
which allows it, this would be a means to an end.
The more interesting thought here would be 'how' they might weaken an
algorithm. My initial thoughts are that since one might be communicating
with someone else, the algorithm has to be left alone and the key selection
algorithm would be modified. For example, for 56 bit DES, a subset of keys
might be chosen at random and the other bits filled in (i.e. by a hash).
Alternatively, a known plaintext block can be inserted into the stream which
the other side might just ignore (an ACK in the TCP/IP stream, for example).
Lots of food for thought. Certainly this might give rise to having servers
which generate session keys instead of the clients - or some other method
where the client doesn't have exclusive choice of a session key.
If _NSAKEY really does deal with the NSA and the importing of cryptographic
routines, this is very bad for Microsoft.
-Giff
--
Too busy for a .sig
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Schneier/Publsied Algorithms
Date: Fri, 03 Sep 1999 21:42:57 GMT
Anonymous wrote:
>
> One of the posts in this thread refers to Bugs in Windows NT...yes there are bugs in
>Windows NT..but its a v. large op. sys. Millions of lines of code....2fish is a very
>small apps..maybe 2-3k lines of code....
>
> OK...Now we see some Test Vectors appeaing on the counterpane.com web site...with no
>documentaion...
>
> Checking the source code when I last downloaded and now....the header in twofish.c
>still reads version 1. April '98 by the same guy...Hi/fn ...whoever that is...
First of all, why should we take seriously some twit who can't even figure out
how to wrap his lines?
Secondly: TwoFish was submitted over 16 months ago as an AES candidate. It
isn't going to change unless some serious flaw is found, in which case it will
more likely be tossed out of the competition rather than changed. If you want
the "official" AES-candidate source code, go to the AES home page at
http://www.nist.gov/aes and order the CD-ROM, and get not only the latest
TwoFish but also the source code to all the other AES candidates. (Note: that
page now says that they are going to make a new CD-ROM with the finalists on
it, and it won't be available until October... but if you're interested in good
top-quality encryption algorithms in a number of different languages, it still
looks interesting). If TwoFish is the AES winner, it will be the "official"
encryption standard for all non-military US encryption. It's already one of the
top five finalists. Sounds like it's pretty solid to me, though some of the
other AES candidates also have good points that make them worth looking at.
As for documentation, there is an *ENTIRE BOOK* with documentation for TwoFish,
not to mention extensive documentation online at the AES home page. If you're
too cheap to buy the book, don't look for sympathy in these quarters. In my
POV, that's the only real advantage TwoFish has over most of its competitors in
the AES competition, it's better documented. I'm rooting for one of the
European candidates (Serpeant or Rijndael) to win due to the political windfall
for encryption rights advocates, but the extensive documentation on the TwoFish
design does make it a worthwhile competitor.
-- Eric Lee Green
------------------------------
From: "Steven Alexander" <[EMAIL PROTECTED]>
Subject: Re: Alleged NSA backdoor in Windows CryptoAPI
Date: Fri, 3 Sep 1999 14:47:07 -0700
The easiest way to weaken an algorithm would be to make part of the key
known. For instance, making 8 bits of a 56-bit DES key known would allow
anyone with decent computing resources(the NSA has much more than decent) to
brute force the rest of the key without trouble. Also, even if several
people had DES keys with the same static bits, the 48-bits would produce
more than enough difference for them not to notice.
What worries me as much as the NSA being able to take advantage of your
machine without your knowledge is that another malicious attacker could as
well. Such an attack could be crushing to many businesses.
-steven
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: THINK PEOPLE
Date: Fri, 03 Sep 1999 22:35:59 GMT
In article <7qpaec$lem$[EMAIL PROTECTED]>, David A Molnar
<[EMAIL PROTECTED]> wrote:
>Frank Gifford <[EMAIL PROTECTED]> wrote:
>
>> If you don't have the final 100 bytes of the target encrypted message, how
>> do you know that they are identical to the last 100 bytes of some other
>> message?
>
>David Scott's scenario was three messages for three people, with the only
>differences being in the middle, and the plaintext for two of the messages
>known.
>
>-David
And the same encryption key and program used for all three files.
Two of the encrypted files where obtain in tact ( well since you have the key
who cares) but the third encrypted file for which the plaintext is missing but
is known to be the same except for a small portion in the middle has a 100
bytes missing from the end.
The point is if you use any of the AES methods with the 3-letter blessed NSA
chaining methods. Which have passed the high standards of the NSA so they
must be good. You can recover the missing portion of the text. Not so with
a program like mine. Becasue I don't use the offical blessed chaining methods
since I feel the term "error recovery" is a PR term for Back Door. But these
are my feeling only. Go ahead and follow the crytpo gods and continue to
worship at the altar of Bill Gates.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Description of SQ
Date: 3 Sep 1999 14:25:01 -0700
In article <7qp20o$[EMAIL PROTECTED]>,
Kostadin Bajalcaliev <[EMAIL PROTECTED]> wrote:
> /* initialization */
> for j=0 to 2^w { P[j]=j; V[j]=0; }
> For j=0 to 2^w { V[j]=K[r]; r=(r+1) mod L; }
> For j=0 to 2*2^w SQ1();
>
>
> /* generator iteration */
> {1} A=P[Sr]; B=P[V[A]];
> {2} V[A]=B; Swap P[A], P[B]; P<<<1;
> {3} Out=P[A+B mod 2w];
> {4} Sr<<<1; Sr=Sr+Out;
> Return Out
Interesting. (A much clearer presentation of the algorithm. Thanks.)
Here's an observation on the basic structure. Consider what happens
if you add an _extra_ P[] lookup to step {1}. One might imagine that
adding more lookups can only increase security, but actually it can
weaken the cipher, which might be a surprise. Consider replacing {1} by
{1'} A=P[Sr]; B=P[V[P[A]]];
Then the modified cipher becomes insecure, for some keys.
Consider: After the first step of initialization, we have
lsb(P[j]) = lsb(j) for all j,
where lsb(x) = x mod 2 stands for the least significant bit of x.
Suppose a similar condition holds for V (which is a L-bit condition on
the 8L-bit key). Then at the first SQ1() iteration, we have
lsb(A) = lsb(P[Sr]) = lsb(Sr)
lsb(B) = lsb(P[V[P[A]]]) = lsb(V[P[A]]) = lsb(P[A]) = lsb(A) = lsb(Sr)
and thus the first half of step {2} (`V[A]=B; Swap P[A], P[B];') doesn't
disturb the lsb-properties of V or P. The rotation `P<<<1' changes the
lsb-property on P[] to a new one, namely lsb(P[j]) = 1-lsb(j) for all j.
Now look at the second iteration. After step {1'}, we have
lsb(A) = lsb(P[Sr]) = 1-lsb(Sr)
lsb(B) = lsb(P[V[P[A]]]) = 1-lsb(V[P[A]]) = 1-lsb(P[A]) = lsb(A) = 1-lsb(Sr)
Again, the first half of step {2} (`V[A]=B; Swap P[A], P[B];') doesn't
disturb the lsb-properties of V or P. Finally, the rotation `P<<<1'
returns the lsb-property on P[] to lsb(P[j]) = lsb(j) for all j.
After two cycles, we're back to where we started (in terms of the
lsb-properties of V[] and P[]). By induction, after any even number of
cycles, the lsb-properties for V[] and P[] will always hold, if your
key is of the special form mentioned above. In this case, lsb(Out) will
form the sequence 0,1,0,1,0,1,0,1, and thus this situation is readily
detectable.
In other words, 1/2^L of the L-byte keys are very weak for this
modification of the cipher. Does the "Information Lose" theory predict this?
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: MD5 source code in VC++ or asm?
Date: Fri, 03 Sep 1999 17:41:49 -0400
[EMAIL PROTECTED] wrote:
>
> Hello all,
>
> Does anyone know where to find MD5 source code in VC++ or asm?
The MD5 description (for example RFC 1321) gives a reference
implementation in C. Assuming VC++ isn't too badly non-standard,
that should work unchanged.
paul
--
!-----------------------------------------------------------------------
! Paul Koning, NI1D, D-20853
! Xedia Corporation, 50 Nagog Park, Acton, MA 01720, USA
! phone: +1 978 263 0060 ext 115, fax: +1 978 263 8386
! email: [EMAIL PROTECTED]
! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "The only purpose for which power can be rightfully exercised over
! any member of a civilized community, against his will, is to prevent
! harm to others. His own good, either physical or moral, is not
! a sufficient warrant." -- John Stuart Mill, "On Liberty" 1859
------------------------------
** 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
******************************
