Cryptography-Digest Digest #313, Volume #10 Fri, 24 Sep 99 23:13:03 EDT
Contents:
Security Specialist/Cryptographer Position in Seattle: ("BC")
Re: Relating cyrptology to factoring? (Tom St Denis)
Re: some information theory (very long plus 72K attchmt) (SCOTT19U.ZIP_GUY)
Re: EAR Relaxed? Really? (Greg)
Re: Exclusive Or (XOR) Knapsacks (Guenther Brunthaler)
Re: Another bug RE: CryptAPI (Christopher Biow)
Re: Securing Executables ([EMAIL PROTECTED])
Re: Another bug RE: CryptAPI (Greg)
Re: Second "_NSAKey" (Greg)
Re: Exclusive Or (XOR) Knapsacks ("Douglas A. Gwyn")
Re: Thesis Announcement: "Rethinking public key infrastructures and digital
certificates --- building in privacy" (David A Molnar)
Re: RSA 640 bits keys factored, French banking smart card system craked! (David A
Molnar)
Re: Another bug RE: CryptAPI (Christopher Biow)
Re: Another bug RE: CryptAPI (Eric Lee Green)
----------------------------------------------------------------------------
From: "BC" <[EMAIL PROTECTED]>
Subject: Security Specialist/Cryptographer Position in Seattle:
Date: Fri, 24 Sep 1999 17:22:53 -0700
Looking for cryptographer to advance the development of protocols for
international software payment system. Excellent comp + options--we're
taking off, come join us.
Qualifications:
1.Relevant MS: Ph.D. preferred
2.Must have solid cryptographic and mathematical background
3.Must be current in all recent developments in security and cryptography
4.Ability to communicate clearly with both internal development and outside
parties--whether customers or other outside firms.
5.Experienced in working with developers to ensure that the security issues
are addressed during both development and implementation.
6.Must be familiar with RSA--of course.
Please contact:
Barry Connolly
Orion Resources
1411 4th Ave Suite 1410
Seattle, WA 98101
206-382-8400
[EMAIL PROTECTED]
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Relating cyrptology to factoring?
Date: Fri, 24 Sep 1999 23:21:54 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> JPeschel wrote:
> > Tom St Denis <[EMAIL PROTECTED]> writes:
> > >Just to be picky I would seriously argue that symmetric ciphers are
> > >younger then their asymmetric counterparts.
> > If you do, you will likely get plenty of argument.
>
> Not only that, but what does he mean by "their counterparts"?
> Or "younger"?
> Or "is"? :-)
That must have been my evil twin posting. I deny knowing of any 'symmetric
ciphers' as he calls them.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: some information theory (very long plus 72K attchmt)
Date: Sat, 25 Sep 1999 02:16:28 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>: In article <[EMAIL PROTECTED]>, James Felling
> <[EMAIL PROTECTED]> wrote:
>
>:>> David Scott promotes using compression before encryption, and several
>:>> responses have agreed with him. [much snip]
>
>: What if you don't know the starting text. The problem with non
>: "one to one" comp is that they are weak even if the starting portion of
>: the FILE is not KNOWN. You sir seem to think one always has the start of
>: the file encrypted that is not necessarily true. What I showed is that
>: non "one to one" compression weakens the compression followed by
>: encryption even if there is no information about the input file.
>
>This sounds a /bit/ too strong to me.
>
>What if the "compression" consists of your "one-to-one" technique,
>followed by interleaving the signal with lots of hardware-generated
>real randomness?
>
>This is no longer "one to one" compression - it adds information to
>the signal. However it doesn't help decompression, and - although the
>cyphertext is longer - the additional encrypted data is /genuinely/
>random, so there's no security lost at the encryption stage.
>
>Indeed - interleaving with real randomness may even increase the
>security - /slightly/ - it would certainly make a normal message
>harder to read.
>
>Sorry to nitpick ;-)
yes you are correct
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: Greg <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: EAR Relaxed? Really?
Date: Sat, 25 Sep 1999 01:24:23 GMT
> In dealing with the dark agencies one has to assume
> hidden agendas as a matter of course, so assuming
> correlation between the stated and actual grounds may
> be a mistake.
What HIDDEN agenda?
It is obvious that the NSA's role is to crack ciphers.
If everyone used strong ciphers, they would be out of
work. There is nothing hidden about that.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Guenther Brunthaler)
Subject: Re: Exclusive Or (XOR) Knapsacks
Date: Sat, 25 Sep 1999 01:36:39 GMT
On Thu, 16 Sep 1999 17:35:16 +0100, "Gary" <[EMAIL PROTECTED]>
wrote:
>Exclusive Or (XOR) Knapsacks
>
>Problem:
>Given an n bit number X and a set {B1,B2,...,Bn} of n bit numbers;is there a
>subset whose elements collectively XORed give X?
>
>Can the general problem be solved easily?
I doubt it (assuming there are much more numbers than bits per
number).
Although similar problems may have been solved by using genetic
algorithms or setting up equation systems, this will not work in this
case.
Even if <n-1> numbers have been selected correctly, selecting the
<n>th number incorrectly will render the rest of the sequence
ineffective.
IMHO, this reduces the problem to a backtracking or random-search,
which will be computionally infeasible for a sufficiently long
sequence of numbers.
However, I see problems in the application in real applications based
on that problem: Although it may indeed be hard to find a correct
subset of numbers that collectively XOR to X, it will be at least as
hard to avoid collisions!
There may be more than one possible sub-sequence that XORs to X, and
perhaps there are even MANY of such subsequences - and any attacker
could find one in short time when applying a simply random search.
Greetings,
Guenther
--
Note: the 'From'-address shown in the header is an Anti-Spam
fake-address. Please remove 'nospam.' from the address in order
to get my real email address.
In order to get my public RSA PGP-key, send mail with blank body
to: [EMAIL PROTECTED]
Subject: get 0x2D2F0683
Key ID: 2D2F0683, 1024 bit, created 1993/02/05
Fingerprint: 11 71 47 2F AF 2F CD F4 E6 78 D5 E5 3E DD 07 B5
------------------------------
From: Christopher Biow <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Another bug RE: CryptAPI
Date: Fri, 24 Sep 1999 19:49:20 -0400
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>Christopher Biow wrote:
>> I remain correct that nothing prior to the release of the symbol
>> communicated the semantics of "NSA key".
>I don't think that's right -- the backup key (but not its name)
>had been explored by hackers and mentioned on some of their sites
>well before NT 4.0 SP5 was released (which merely attached a name
>to the backup key). Unfortunately I don't remember where I saw it.
You are misinterpreting my claim. I say again, nothing had previously
communicated the source-code *semantics* of "NSA key". Those semantics may
be, "owned by the NSA for nefarious use" or "inserted and owned by MS at
NSA direction". Regardless of which is correct, only the English-language
symbol communicated that particular, natural-language semantics.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Securing Executables
Date: Sat, 25 Sep 1999 00:46:38 GMT
In article <7sb75f$f49$[EMAIL PROTECTED]>,
"Peter Johnson" <[EMAIL PROTECTED]> wrote:
> I'm designing a client/server application that will run in real-time.
> Assuming that the network traffic is secure by using strong
encryption, a
> good random number generator for packet sequencing, compression, etc.
how do
> I protect against an attack on the client executable?
If the client computer is secured then you don't have a problem. If it
isn't then your client executable in the PC cannot be protected because
it can be substituted by a Trojan.
The solution may be to take the executable out of the PC: store it in a
PC card (either memory or hard disk) and have the user handle it as if
it were a physical key. A Trojan attack will not work as long as the
attacker has no detailed knowledge about the program's interface.
Another alternative is to put an encryption program in a smart card and
have it decrypt the *entire* user's hard drive (including the OS) every
time he sits to work and encrypt it again every time he leaves.
Obviously, these are no easy solutions. If the server can be trusted,
maybe you can have it continously and unpredictably challange the
client OS and application and hope that the attacker will not be able
to alter the operating environment of the client without the server
noticing.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Another bug RE: CryptAPI
Date: Sat, 25 Sep 1999 01:51:30 GMT
> Absolutely false. The vulnerability was explained in one of
> Bruce Schneier's newsletters...
And you believe him?
I read his piece on the NSA key discovery and it doesn't hold
water for me. He does not seem to address the issue (I mean
I don't think he even bothered to discuss it) that NSA is
in conflict of interest in advising anyone on security matters.
Their job is to INVADE security.
But that is his problem and it is really another story...
> Also see: http://www.cs.berkeley.edu/~daw/papers/
>
> and read the paper about vulnerabilities in an (old) version of the
> Netscape browser. David Wagner succesfully reverse-engineered the SSL
> code in the original Netswcape=-SSL, and found a rather surprising
> vulnerability.
I wonder why?
> Regarding "open source vs. closed source",
Regarding open source v. closed source, you could make a very good
argument today (in light of MS's fiasco) that open source is much
more preferred. The relationship between the NSA's life blood and
that of MS is now too obvious to ignore. No matter who writes the
software, to be certain you know what it is doing you and everyone
else in the community must be able to see all of it.
This is why I think it was a major disaster for MS. People have
been woken up to see, yes indeed, MS does NOT have our best interest
at heart and Bill would gladly sell our privacy out to the NSA for
a piece of the international market.
I am looking into Linux this fall to replace my NT on my desktop.
I have simply had it up to here... no, up to here... no, go higher
up to here... no, no no, you are not high enough... :)
--
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/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Second "_NSAKey"
Date: Sat, 25 Sep 1999 01:37:45 GMT
> > Be my guest. Show me why the conspiracy theory to give
> > NSA a key CANNOT be correct. That is what I mean by refute.
> > Show that it CANNOT be correct.
>
> No, the onus is on *you* to provide extraordinary evidence to
> support youe extraordinary claim. All I had to do was point
> to at least one reasonable alternative theory.
But they are not reasonable.
> > Someone wanted a second key. It makes no sense that MS wanted
> > it, so someone else must have wanted it. And it has their name
> > on it. What else do you need?
>
> In at least one alternative explanation, it *did* make sense
> that Microsoft wanted a second key.
Which one? I could have missed it, though I probably did not.
> I assure you that if NSA had engineered this, they would *not*
> have put their name clearly on it.
Wrong! If NSA required it and MS coded it, then the scenario
is all too obvious.
Look, you go ahead and believe that MS and NSA are benevolent.
It is very clear to me that NSA's reason for living is to decrypt
messages flying over the internet. It is therefore obvious that
they have a great deal at stake to look into our PCs if they
ever think they will need to. If they had no back door, if
people could use strong encryption, they would effectively be
useless. They are not about to let MS put them out of work
without twisting arms. It is not that they are criminals. The
NSA is simply trying to do their job.
--
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/
Before you buy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Exclusive Or (XOR) Knapsacks
Date: Fri, 24 Sep 1999 23:14:23 GMT
David Wagner wrote:
> And what do you mean by inconsistency?
in the sense of an overdetermined system.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Thesis Announcement: "Rethinking public key infrastructures and digital
certificates --- building in privacy"
Date: 25 Sep 1999 02:21:36 GMT
[EMAIL PROTECTED] wrote:
> ------------------------------------------------------------------------------
> See http://www.xs4all.nl/~brands for a detailed overview of the
> contents of the thesis, online summaries (in English and in Dutch),
> several downloadable chapter parts, and contact information.
Thanks for posting this! I'm looking forward to seeing the entire thesis
when it's finished, and I'd guess a number of other people are, too.
Good luck!
-David
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: RSA 640 bits keys factored, French banking smart card system craked!
Date: 25 Sep 1999 02:48:01 GMT
In sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
> First the prime number theorem is pi(x) = x / ln x, and it has not been
> proven, that's why it's a theorem. It just happends to be a very good
> estimate.
Nitpick 1 : theorems are statements of the form "if X, then Y" which can
be proved. So saying that "it has not been proven, that's why it's a
theorem" is *very* confusing.
You seem to be thinking of the fact that there's an error term in that
estimate...the number pi(x) isn't "exactly" x/ln x, but within some
(small) constant of that. There's also this estimate :
pi(x) = li(x) + O(x^{1/2 + epsilon})
where li(x) is this integral :
/ x
| dt
| ---
/2 log t
The nice thing about this form (IMHO) is that it gives nice explicit
bounds on how much error to expect, which aren't as obvious to me in the
x/log x estimate. The downside is that it depends on the Riemann
Hypothesis -- why? because to get this estimate requires rewriting an
expression denoting "the number of all prime powers less than x" in terms
of the Riemann zeta function, so where that function goes to zero becomes
important.
*I* can't prove this correct right now, but I can direct you to an
explanation : chapter 8 of "Algorithmic Number Theory : Volume 1,
Efficient Algorithms" by Bach and Shallit. I know this doesn't help you
much, since you probably don't have it lying around. It's just that I
found it much more helpful than any of the other math books I could find
on the topic.
(does anyone have pointers to an online, introductory-level treatment of
prime number theorems and densities? course notes, maybe?)
This is not to say that it's an _easy_ explanation. Indeed, reading
through it is leading me to the (depressing) conclusion that I need to
take complex analysis. Depressing because it's rumored to be one of the
deadlier courses here, and I still want to row sometime.
> Second I seriously doubt the primary poster had any idea what he was talking
> about. Applied Crypto covers prime numbers in a bit of detail, you should
> check there.
Actually, if you want to recommend books, I really really like the already
mentioned "Algorithmic Number Theory : Volume 1 Efficient Algorithms" by
Bach and Shallit. Applied Crypto is nice, but it does not cover this topic
in much detail, besides giving enough to let you know that probabilistic
prime generation will work.
-David
------------------------------
From: Christopher Biow <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Another bug RE: CryptAPI
Date: Fri, 24 Sep 1999 20:40:11 -0400
[much trimmed]
Eric Lee Green <[EMAIL PROTECTED]> wrote:
>Christopher Biow wrote:
>> Eric Lee Green <[EMAIL PROTECTED]> wrote:
>> >Regarding "open source vs. closed source", Unix or Unix-lookalike
>> >operating systems account for approximately 75% of the operating systems
>> >on the Internet.
>> Defined how?
>As public web, ftp, or mail servers.
Granted, though I'd like to see good figures on the trends of the last two
years. I've found it downright depressing how the suits have been running
off the NT cliff together. A large organization I know is trying to use NT
machines for everything but paperweights and bicycles.
>By far the vast majority of
>workstations are behind firewalls, where they are safe from attack.
I'm not sure that's true. I know at least one major lab that has a standard
policy of not using firewalls.
>> Regardless, the closed-source of WinNT has been a
>> considerable impediment to the discovery of many classes of
>> vulnerabilities, especially remote buffer overflows.
>Probably the biggest impediment has been that WinNT 4.0 does not
>implement a large number of Internet functionalities. For example, there
>is no remote login capability in a stock WinNT install, which in itself
>eliminates a major portion of the ability to attack the machine.
There is not a *telnet* interface, which is not surprising for a GUI-based
system, any more than *nix's lack of NetBEUI interfaces (a notable omission
in Samba). However, a notable and hard-to-close stock NT vulnerability
comes with the capability for remote Administrator login via IP or even
IPX. That login can then install a telnet app, if he wishes.
>Similarly, WinNT's FTP server is rather sadly disfunctional compared to
>wu-ftpd...
Even normalized per square gallon of functionality, I'll claim that NT
exploits are rarer than most open-source *nix. (In many respects NT IIS has
more such functionality than stock Apache.)
>> Scanning http://ciac.llnl.gov/cgi-bin/index/bulletins?i and
>> http://ciac.llnl.gov/cgi-bin/index/bulletins?j ISTM that the vast majority
>> of the Unix remote root exploits that have been discovered and potentially
>> widely exploited (i.e. not discovered and patched in-house prior to release
>> of vulnerability info) have been in open-source Unix code.
>I'm not sure what you're saying. You're saying that there's no
>difference between the closed-source and open source Unix variants, but
>that open-source Unix code common to both has been a large source of
>exploits?
Correct. I'm not sure there are enough data points for a direct comparison
of closed-source Unix code to its open-source counterparts.
>Incidentally, probably the most secure operating system out there is
>OpenBSD (http://www.openbsd.org ). I don't run it because it doesn't
>have all the functionality I want...
Bingo, and ditto for much of the rest of the net. OpenBSD is what
proportion of workstations or servers? I can probably write a secure OS
that does nothing but answer pings. Somewhere between that and a
functionality-overloaded (new and legacy) OS like NT, there is a quantum
difference in scale.
>With OpenBSD I can be reasonably assured that no buffer
>overflows will be detected in the bundled applications within the near
>future (with 3rd party apps, of course, there is no such assurance).
>With Windows NT I do not have that assurance.
I maintain that a stripped down NT with such auditing effort would be even
safer from these than OpenBSD. MS seems to have correctly surmised that
effort spent on producing such an NT would not bring as much $$ return as
putting that effort into getting Win2K out the door, or adding additional
(if unreliable) functionality to it.
>In other words, what I think you are saying is this:
>If no effort has been made to secure the system, the more obscure of the
>pair is the most secure.
Given that OS technology is nowhere near crypto technology in its ability
to eliminate security holes, with comparable effort, increased obscurity
will likely result in increased OS security. Perhaps there would be a
crossover point at which the broader scrutiny of open source code would pay
off. Perhaps you are even correct that OpenBSD has reached that point.
Linux, e.g. in the incarnation of a RH6.0 install, clearly has not yet
reached this point w.r.t. the roughly contemporary NT 4.0SP5. The same
maintenance effort put into post-SP5 hotfixes vs. 6.0 RPM errata would lead
to more frequent windows of remote root/admin vulnerability on the RH box,
vs. the same level of attacker.
(FWIW, I've chosen RH6 for new servers, both at my company and where I
consult, but for reasons of functionality, efficiency, and sheer personal
preference for the Linux community over MS, not perceived security.)
>What I am saying is this:
>If a positive effort has been made to secure the system, the more open
>of the pair is the most secure...
At some point, yes. I question whether any *nix has reached that point.
Perhaps you are correct about OBSD.
>The situation is analgous in the crypto world, BTW. If someone is
>passing out snake oil, the snake oil that is most obscure is the most
>secure. If, on the other hand, there has been an active effort to secure
>an algorithm, probably the one that is most open will be the most
>secure.
OK, Enigma was snake-oil. Within that analogy, I question whether any
fully-featured workstation or server is beyond the snake-oil stage wrt
security. It can reasonably be expected that a skilled programmer can
implement IDEA without severe remote security holes. Moderate auditing will
increase this likelihood. An OS that did nothing but answer pings could be
written at this level. But it cannot reasonably be expected in 1999 that
even a large team of programmers can implement a full-featured
workstation/server system without severe remote security holes. Relative
amounts of functionality and formality of specifications have a lot to do
with this difference, IMO. And thus obscurity *adds* to security of such
systems. (Note that I've stopped scoping my claim to the OS, to avoid the
obvious counter of a trivial but truly secure OS.)
I'll be on vacation for the next week, so you get free hits in response to
anything that I've stated poorly or thought out incompletely.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Another bug RE: CryptAPI
Date: Fri, 24 Sep 1999 19:59:07 -0700
Greg wrote:
> I am looking into Linux this fall to replace my NT on my desktop.
> I have simply had it up to here... no, up to here... no, go higher
> up to here... no, no no, you are not high enough... :)
Linux can certainly be secured to the level of NT (and beyond), but be
careful. The typical Linux distribution is shipped "wide open". Absolute
security does not appear to be a priority in LinuxLand, certainly not to
the extent that OpenBSD took the concept. You will have to download a
variety of cryptographic components in order to properly secure Linux,
and there's so much junk on the typical Linux CD-ROM (1200M with
Mandrake 6.1!) that even then it's easy to miss something that opens
your system wide open.
I'm not going to go into detail on the security flaws in current Linux
distributions, because that's not relevant to this newsgroup. All I
wanted to do was point out that going to a non-Microsoft Os does not
automatically mean you are secure. Security does not appear to be a
priority anywhere, alas... I think the well-publicized security problems
that have afflicted Microsoft (and to some extent Unix and Linux) in the
past are just a reflection of Microsoft giving people what they want
(i.e., convenience). Most people, when faced with security measures that
make their life more of a hassle, disable said security. As a result,
system vendors, since they listen to their customers, conveniently ship
the system by default with the hassle-type features disabled :-(. It
appears that, in reality, nobody cares about security unless they are
personally hit by a security breach, at which point it becomes the OS
vendor's fault for not automatically enabling the security features that
the customer would have disabled anyhow :-(.
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
There Is No Conspiracy
------------------------------
** 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
******************************
