Cryptography-Digest Digest #299, Volume #10 Thu, 23 Sep 99 00:13:03 EDT
Contents:
Re: Another bug RE: CryptAPI (Greg)
Re: Second "_NSAKey" (Greg)
Re: msg for Dave Scott (Tom St Denis)
Re: Factoring arbitrary numbers ("Dann Corbit")
Re: low diffie-hellman exponent (Eric Lee Green)
Re: Another bug RE: CryptAPI (Eric Lee Green)
Re: RSA 640 bits keys factored, French banking smart card system craked! (Paul Rubin)
Re: Another bug RE: CryptAPI (Eric Lee Green)
Re: msg for Dave Scott ([EMAIL PROTECTED])
Re: International crypto restrictions (Eric Lee Green)
Re: EAR Relaxed? Really? (Eric Lee Green)
Re: (US) Administration Updates Encryption Export Policy (Eric Lee Green)
Re: Factoring arbitrary numbers (Paul Rubin)
Re: Another bug RE: CryptAPI (Greg)
Re: Homophones (JTong1995)
Re: low diffie-hellman exponent (Scott Fluhrer)
----------------------------------------------------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Another bug RE: CryptAPI
Date: Thu, 23 Sep 1999 00:25:39 GMT
> It's a stretch, but Microsoft(tm)'s authority to sign
> every CryptoAPI module can be construed as a form of
> endorsement. By that standard it is false (fradulent)
> because one might end up with modules that are not signed
> -- endorsed -- by Microsoft(tm) because of the loopholes that
> Microsoft(tm) put in their software.
What I mean by fraud- let me say it clearly here for
all time and all people- Microsoft pushed a product, the
CryptAPI archeticture, as an adequate design for security
while KNOWING all along that it was compromised by NSA.
This is what the word fraud means.
--
Truth is first ridiculed, then violently opposed, and then it is
accepted as self evident ("obvious").
I love my president... I love my president... I love my president...
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Second "_NSAKey"
Date: Thu, 23 Sep 1999 01:04:15 GMT
> > No, seriously, this is one time NSA has been caught with its
> > pants down.
>
> In what sense has the NSA been caught? None that I can see.
I don't know how to say it- it is so obvious to me I guess it
is hard to put into words.
Look, the key is clearly there because someone wants it there.
It makes no sense to say that MS wants it there, and it makes
every bit of sense to say NSA does.
NSA has the means (EAR) the motive (project Echelon) and the
opportunity (current political climate makes enforcement work).
No other explanation I have yet heard fits so effortlessly to
the evidence we have in hand today as this one does.
> Certainly the agency might be interested in compromising the
> vast number of machines now in use. But this was crude.
> Amateurish. I suspect the agency simply isn't that crude.
It was brilliant. Look how long it continued before it was
exposed. And I cannot think of a better means to pull of what
their key can do to Windows CryptoAPI.
> Consider that you are assuming a vast bureaucratic conspiracy
> where none may exist.
No I am not. It is agency policy and how many people KNOW the
real agency policies within the NSA? A: only those who need
to know.
> But if it did/does exist, and
> Microsoft(tm) were doing NSA's bidding, they could simply
> weaken critical aspects of the CryptoAPI and
> tracelessly (note that word -- it is important)
> read the bulk of the data
> secured under Microsoft(tm)'s OS.
How would you weaken encryption without tipping your hand?
You don't. The NSA key, I believe, is not designed to weaken
the encryption, but to syphon off plain text to a covert IP
address- Echelon's perhaps?
> The last thing they would do is attempt a hole for the
> insertion of a trojan horse crypto DLL. the hole leaves traces.
> Inserting the the DLL leaves footprints. And anyone who detected
> such a trojan (and someone, or many, would) would have the
> equivalent of a smoking gun.
No, this hole did not leave a trace. The name was the first
real break as to who the hole belonged to.
This was a brilliant move by the NSA. I would have been proud
to have come up with this approach. I came up with one similar
and it was very effective in not giving the user a clue that
something was wrong. The NSA hole was good- very good.
> I suspect this is proof not of a vast bureaucractic conspiracy
> but of simple stupidity. Lots of it.
It does not fit the evidence. There is no amount of stupidity that
can carefully reproduce itself in each of the 32 bit platforms.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: msg for Dave Scott
Date: Thu, 23 Sep 1999 00:42:30 GMT
In article <fQ4G3.475$[EMAIL PROTECTED]>,
"Anonymous" <[EMAIL PROTECTED]> wrote:
> Really???? Why all the repeated characters if it *is* RC4??
Yes really. I pad no matter what you use. For some reason I have to have
lots of padding... I need about 5x4 bytes for the header, but if I reduce it
below 40 or so it corrupts the message (probably because the larger block
sizes ...)
At any rate... there is a new peekboo that can read deja-messed up messages
(deja-news puts spaces in everywhere).
http://www.cell2000.net/security/peekboo/
(can you read the message?)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Dann Corbit" <[EMAIL PROTECTED]>
Subject: Re: Factoring arbitrary numbers
Date: Wed, 22 Sep 1999 17:36:17 -0700
Ted Kaliszewski <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Good and simple accounts of the principal factoring methods are not
readily
> found, except in scattered journal articles. Your best bet is to look up
> Riesel's book, perhaps the new edition, on Prime Numbers and Computer
> Methods for Factorization. The version that I know was published in 1985.
Another good idea is to collect postscript papers from the web or do a web
search for factoring sites.
Finally, Chris K. Caldwell's prime page:
http://www.utm.edu/research/primes/
has an excellent bibliography:
http://www.utm.edu/research/primes/refs.shtml
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
"The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. Newsgroup http://www.dejanews.com/~c_a_p
C.A.P. FAQ: ftp://38.168.214.175/pub/Chess%20Analysis%20Project%20FAQ.htm
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: low diffie-hellman exponent
Date: Wed, 22 Sep 1999 18:43:27 -0700
Tom St Denis wrote:
> > an unlicensed implementation of RC5 or RC6 (they are patented here in
> > the U.S., or, rather, one of the mathematical operations within them is
> Well I already have Twofish in their (along with CAST, Blowfish and XXTEA).
> No offense but your excuse is rather lame, do you feel that opressed that you
> can't download it or you just don't have the time?
Both, sort of. Since I use FreeBSD as my desktop operating system (well,
I also dual-boot with Linux to run some apps that FreeBSD doesn't seem
to like too much, like Quake 2), I cannot use your source directly so it
would be useful mostly as a framework for a quick port. Having to
snuffle out the proprietary bits is a bit too much hassle for my
available time. So yes, my "excuse" was rather simplified, but it all
adds up to the same answer (shrug).
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
There Is No Conspiracy
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Another bug RE: CryptAPI
Date: Wed, 22 Sep 1999 18:47:32 -0700
Paul Koning wrote:
> There's just one solution. You have to understand the fact that
> NO Microsoft product has any security.
I use FreeBSD as my desktop operating system, and our primary
development environment at my place of employment is Linux (makes a
darned cheap Unix software development workstation, and actually works
better as a desktop nowdays than Solaris does, though Solaris still
kicks rear as a server). Still, I would disagree withn your assertation
that "no Microsoft product has any security". While that is true of
Windows 9x, that is NOT true of a properly configured Windows NT system.
NT would actually be a fairly secure OS if properly configured (but it
is usually configured "wide open", sigh).
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
There Is No Conspiracy
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Crossposted-To: alt.security.pgp
Subject: Re: RSA 640 bits keys factored, French banking smart card system craked!
Date: 23 Sep 1999 02:39:45 GMT
Laurent PELE <[EMAIL PROTECTED]> wrote:
>> could factor by mathematical means. I wonder if the factors were
>> embedded in the smart card, and Humpich got them out with a hardware
>> or protocol attack.
>
>No because, Humpich can make different false smartcards and change them as
>he like.
Well, if the smartcards had the secret key inside and he got it out,
then he could re-use it in other cards.
>He didn't find any leak in the protocol, he didn't have any other choice to
>factor the key, it is said in the 2 pages interview in PirateMag September
>magazine in French.
Is that interview online? I can read enough French to get the sense
of what he said.
>But the 640 bits number had special properties, as Humpich told it.
>It means probably that there is a special modulo, and it can be attacked
>with method based on elliptic curves.
Is this from something you know that hasn't been mentioned here, or
are you just guessing?
>It is a factor of two numbers of 320 bits exactly, each of them are not far
>of the square root.
Well if they're *really* close to the square root, then yes there
are methods that will work, but the people who chose the key must not
have known what they are doing.
>He said that he used latest methods to factor the number with a
>japanese software. He setup the software to take account of the
>properties of the 640 bit number.
What software?
>He also entered probabilities about the prime numbers (for example maybe he
>tried the prime number around the factor/3 because he think maybe the banks
>chose a prime number that is about twice more than the first one and didn't
>use a random number generator).
Um, then the numbers would both be far from the square root.
>I mean that generally researchers are not involved in the prime numbers
>choice. The litterature at that time only said that the factor should be
>like (8A+3)x(8B+7) where 8A+3 and 8B+7 are two prime numbers.
Yes. The idea was to generate random primes of that form. Actually
as I remember, the suggestion was to use (4A+3)(4B+3).
>He also said that prime numbers of 320 bits long are quite rare,
>maybe there are even less numbers with this special properties around the
>scale he tried.
No. The number of primes less than n is about n/log(n). So there
would be around 10**94 primes of 320 bits. The residues mod 8 are
always 1,3,5, or 7 (or else the number would be even) and these should
happen about equally often. Since you only have to find one of the
two factors, limiting the residue to 3 or 7 just gets rid of half
the candidates, still leaving at least 10**93 to choose from.
This kind of "rarity" isn't going to help you.
>So the fact is that some individuals can attack some cryptographic systems,
>maybe with some chance, maybe also with a leak in the prime number
>generation but also after much work (4 years !)
It seems just about certain to me that they didn't set the system
carefully, if it was broken by methods anything like what you describe.
>French banks has done a fault, because, instead of increasing the size of
>the key, they should have change the protocol. Because zero-knowledge
>protocols (like the Fiat-Shamir scheme) was available in 1991 and smartcards
>should be based on such protocol before massively use smartcard in point of
>sale terminals since 1993.
Don't forget that F-S can also be broken if you can factor the modulus.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Another bug RE: CryptAPI
Date: Wed, 22 Sep 1999 18:52:13 -0700
Christopher Biow wrote:
> Paul Mikesell <[EMAIL PROTECTED]> wrote:
> >I'd like to point out that a non-dll implementation only will only make
> >the system more secure through obfuscation, which does not really make it
> >more secure.
>
> By analogy, passwords are security through obfuscation, but their use has
> non-trivial effects upon security.
Err, passwords are keys. No security system is secure if its keys are
known.
You're saying that your car is insecure because if someone has the key,
they can open the door and drive off in it. Not a good analogy at all.
Whereas if you said that your car is secure because, even though you
left it unlocked and left the key in the ignition, you parked it in a
hidden area on the back 40 of your uncle's ranch... then you're relying
on security by obcurity. I.e., you're betting that nobody is going to
stumble on it. Which may remain true for one year. Or two years. Or even
three. But not forever.
Basically: a good encryption algorithm is secure whether its details are
known or not. Because you can bet that attackers will discover the
details eventually, and if you left the keys in the ignition, well, it
doesn't matter whether it's on the back 40 or in your driveway.
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
There Is No Conspiracy
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: msg for Dave Scott
Date: Wed, 22 Sep 1999 22:03:27 -0400
jerome wrote:
> can you explain all these 'a' at the end and in the middle of the
> cypher text ?
Yes, that is padding used by the program itself, nothing to do with the
ciphers nor the encryption system, it's mearly there for error correction
I believe.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: International crypto restrictions
Date: Wed, 22 Sep 1999 19:57:14 -0700
Scott Hardy wrote:
> I was then informed that Blowfish was only allowed
> to be exported from the US with a 32-bit, rather
> than 40-bit key, presumably because of its
> behaviour along these lines. So, my question is
> this: since I can code it outside of the US, is
> this a viable idea, or are there many other
> countries which limit algorithms based on subkey
> generation time?
If you are a U.S. citizen then U.S. export law applies to you whether
you are inside the country or outside of it, and "export" means that the
program ends up overseas. That is, if you are a U.S. citizen and write
the program while physically located outside the country, you are
considered to have exported it (illegally, since you don't have an
export license presumably!).
If you are not a U.S. citizen, you will have to obey a) the laws of
whatever host country you are located in, and b) the laws of your own
home country.
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
There Is No Conspiracy
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: EAR Relaxed? Really?
Date: Wed, 22 Sep 1999 19:18:37 -0700
Greg wrote:
>
> In article
> <[EMAIL PROTECTED]>,
> Eric Lee Green <[EMAIL PROTECTED]> wrote:
> > Greg wrote:
> > > I have also heard that there are non disclosure agreements between
> > > NSA and the vendor. This is fine, except it can prevent the vendor
> > > from telling all about the negotiations with NSA. For example, if
> > > the NSA says, "We need two back doors into your software to examine
> > > the plain text before it is encrypted," then we would never hear of
> > > it.
> >
> > Oh poop. You'd hear of it alright, because we would never
> > agree to put two back doors into our software....
>
> So you mean you would violate an NDA with the federal government
> that would expose their true intentions that they would desire
> to keep close to their chest? Do you really think they would
> let you do this without hell to pay? I don't.
No. I would not sign such an NDA, and I would advise my employer not to.
Instead, we would simply state that the cryptographic functions of our
software are not available overseas due to NSA action, and leave it at
that.
It'd probably sell more copies of our software domestically anyhow.
"Wow, their software's so secure that the NSA won't let them sell it
overseas!".
Of course, nobody is stopping you from doing a s/rsh/ssh/ in the main
network backup script (which is called by the GUI to do the actual guts
of the program). For that matter, an upcoming revision will allow
specifying an external compression program to be called prior to sending
the data over the network, and it'd be child's play to instead
substitute a script that invokes an encryption prograam after the
compression program. Our software is written under the Unix philosophy
of "many small programs chained together", albeit run by an overall GUI,
and that philosophy allows a flexibility to "plug in" functionality into
the chains.
We do not have any specific hooks for encryption in our software, but
that does not stop people from misusing current network data transfer or
compression hooks to do encrypted data transfers. So we really don't
have much incentive to jump through a lot of hoops to provide
cryptographic function to our overseas customers -- they already can add
as powerful of encryption as they want, due to the flexible design of
the software. I suspect we'd get more commercial value if we DON'T get
export permission, actually ("Software too powerful to export!"), and it
would reduce development costs by half since we would not have to
maintain two seperate cryptographic source trees (one for the domestic
product supporting the AES winner so that we could get government
contracts, and one for the export product supporting 56-bit DES, the
maximum exportable under the proposed new rules unless you want to
undergo onerous reporting requirements).
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
There Is No Conspiracy
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: (US) Administration Updates Encryption Export Policy
Date: Wed, 22 Sep 1999 19:43:09 -0700
Patrick Juola wrote:
> In article <7s8h7v$9i1$[EMAIL PROTECTED]>,
> Bill Unruh <[EMAIL PROTECTED]> wrote:
> >In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Jerry
>Coffin) writes:
> >]Finally, note that the Bernstein case revolved around the use of
> >]source code as a method of communication between people, so there was
> >]a restriction on the right to free speech. If, for example, you write
> >]source code like Dave Scott's, which nobody can read, that argument
> >]obviously goes out the window. To export source code in accordance
> >]with this decision, you could be called upon to prove that the
> >]_primary_ reason for using source code was simply to provide an
> >]unambiguous method of communicating with another person.
> In general, publishing source code for a software package can easily
> be argued not to be "communicating" with other humans;
If I am publishing the source code as a political statement regarding
the corruption of the United States government and its system of
encryption export controls, I am very much so communicating with other
humans, even if I do not expect a single human to ever read my source
code.
It's like burning the American flag. It's political speech. It's
protected.
Now, if I were publishing the source code *FOR COMMERCIAL GAIN*, then it
becomes commercial speaeh and thus may be regulated.
Of course, none of this makes a darned bit of difference in the real
world. The United States Government has no intention of allowing
political statements such as the publishing of source code for free on
the Internet, and views the First Amendment as merely this encumberance
that must be ignored at all possible times. You can expect that they
will very swiftly and harshly prosecute anybody who dares to make such a
political statement.
The problem, though, is that if nobody is willing to pay the price for
freedom, then freedom goes away :-(. Without having the backing of the
EFF or ACLU, I would not dare to attempt it, and even so would have to
be prepared to pay a terrible price (Phil Zimmerman, anybody?).
Followups to talk.politics.crypto.
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
There Is No Conspiracy
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Factoring arbitrary numbers
Date: 23 Sep 1999 02:41:42 GMT
In article <7sbku5$96$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>Hi,
>
>I'm writing a program that factors arbitrary numbers. I've heard of
>the following algorithms:
>
>Brent-Pollard method
>Pollard's (p-1) method
>William's (p+1) method
>Lenstra's elliptic curve method
>Pomerance-Silverman-Montgomery multiple polynomial quadratic sieve
>
>Can someone refer me to a website or some good math textbooks that
>contain these formulas and theories?
Book: A Course in Number Theory and Cryptography, by Neal Koblitz.
Website: see the MIRACL package by Mike Scott, http://indigo.ie/~mscott.
It contains very readable C++ implementations of many of these algorithms.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Another bug RE: CryptAPI
Date: Thu, 23 Sep 1999 02:40:40 GMT
> Start on a Microsoft platform and you're defeated
> before you even get started.
Amen!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (JTong1995)
Subject: Re: Homophones
Date: 23 Sep 1999 03:57:56 GMT
The book, "Secret Codebreakers II: A Cryptanalyst's Handbook" has a section
on the solution of the Mexican Army Cipher Wheel, which was a monoalphabetic
substitution cipher with up to 4 homophones for each plaintext letter. For an
introductory book, it is surprizingly good.
Jeffrey Tong [EMAIL PROTECTED]<Jeffrey Tong>
PGP 5 Key available for download at WWW.PGP.COM Key ID: BFF6BFC1
Fingerprint: 6B29 1A18 A89A CB54 90B9 BEA3 E3F0 7FFE BFF6 BFC1
------------------------------
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: low diffie-hellman exponent
Date: Thu, 23 Sep 1999 03:59:35 GMT
In article <7s9i2f$ett$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
>In peekboo 1.4 I used the output of sha for the exponent. Now I am wondering
>is that a bad idea? The modulus is 2048 bits so I think solving it would be
>a pain but what about specialized cases like mine?
With DH, in general, if the attacker knows the private exponent is between 0
and N, he can find it in O(sqrt(N)) time using the 'big step/little step'
method. So, if you use a straight SHA image as the exponent, the attacker
can reconstruct it with about 2**80 modular multiplications.
You decide if that is that is an unacceptable crack (my opinion: only if you
are extremely paranoid. But then, I think a 2048 bit DH modulus is massive
overkill and shows you are already quite paranoid).
--
poncho
------------------------------
** 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
******************************
