December 2003 - cypherpunks-legacy

NT and C2
by Weld Pond 17 Dec '03

17 Dec '03

Here is the URL to an article in Network World by Winn Schwartau entitled, "One expert shares his views on Microsoft securitey features. http://www.iquest.net/cgi-bin/gate2?|mmMgT008://bbb.PHDx10.ix0/ibLD1P7i/ExU… If you need a username/password try cypherpunks/cypherpunks Here is an excerpt: Since Microsoft Corp. products are usually robust, I was looking forward to seeing what type of security features the company implemented in Windows NT Workstation Version 3.5. But after walking through the system with Microsoft product managers and developers, I was dismayed to find how woefully short on security features Windows NT is. Despite the fact that the U.S. government is expected to certify Windows NT as a secure operating system, Microsoft's first serious venture into security is not very impressive. Windows NT may pass muster with the federal government, but it does not meet the real-world security needs of corporations running complex, heterogeneous networked environments. Weld Pond - weld(a)l0pht.com - http://www.l0pht.com/~weld L 0 p h t H e a v y I n d u s t r i e s Technical archives for the people - Bio/Electro/Crypto/Radio

2 1

List latency.
by Peter Trei 17 Dec '03

17 Dec '03

> > At 12:20 PM 10/2/95, Peter Trei wrote: > > >For those curious about the latency, I'm posting this at 12:08, on the US > >east coast. > >How long did it take to reach you? > > I got it at 09:14, Pacific Daylight Time, so there appears to be no lag. Here's the relevant headers for the bounceback to me, which took an hour: > Received: from relay3.UU.NET [192.48.96.8] by alcor.process.com > with SMTP-OpenVMS via TCP/IP; Mon, 2 Oct 1995 13:10 -0400 > Received: from toad.com by relay3.UU.NET with SMTP > id QQzjst04916; Mon, 2 Oct 1995 12:51:05 -0400 > Received: by toad.com id AA00166; Mon, 2 Oct 95 09:10:05 PDT > Received: from alcor.process.com by toad.com id AA00160; Mon, 2 Oct 95 > 09:10:02 PDT Message-Id: <9510021610.AA00160(a)toad.com> Received: from thunk > [192.42.95.240] by alcor.process.com > with SMTP-OpenVMS via TCP/IP; Mon, 2 Oct 1995 12:10 -0400 > Date: Mon, 2 Oct 1995 12:14:30 -6 Translating: Sent by thunk.process.com 12:14 EDT Received by alcor.process.com 12:10 EDT -4 minutes (thunk's clock is off) Received by toad 9:10 PDT 0 minutes Received by uunet 12:51 EDT 41 minutes Received by alcor 13:10 EDT 19 minutes It looks like there's a considerable delay entering and leaving uunet. I'm not sure which machine gets the blame, but it's either toad&uunet, or uunet&alcor. Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei(a)process.com

2 1

Re: Simple Hardware RNG Idea
by Dave Dittrich 17 Dec '03

17 Dec '03

> Perry writes, regarding alpha decay counts for random numbers: > > > And, as I noted, there are RS232 interfaceable radiation detectors you > > can buy off the shelf -- no hardware hacking needed. > > As far as a radiation source goes, the Americium 241 source from a cheap > smoke detector is just dandy. A while ago, I took one into the lab and > put it on a scintillating counter and got alpha hits at roughly > half-microsecond intervals. It was a while ago, so I forget how this compared > to the rating in Curies on the package. But that would be fine for a > low-to-moderate bandwidth RNG. I was thinking about this the other day and wondered if it wouldn't be cheap and relatively easy to build a board that samples and sums several randomly selected signals on various frequencies on the AM broadcast spectrum. This should catch stations in nearly all metropolitan (and most rural areas as well) and would require that someone be able to broadcast at multiple frequencies to "cheat" it. Perhaps this would be affected by RF interference from the motherboard itself. If so, could the RF radiation from the motherboard itself be used to generate random numbers? -- Dave Dittrich Client Services, Computing & Communications dittrich(a)cac.washington.edu University of Washington <a href="http://www.washington.edu/People/dad/"> Dave Dittrich / dittrich(a)cac.washington.edu</a>

4 5

SSH random numbers
by Lance Cottrell 17 Dec '03

17 Dec '03

I have finaly been goaded into using SSH. I seems like a great tool, but I have one major worry. When I install SSH, it generates the host key right away. When I run ssh-keygen, it generates my user key right away. Where is it getting the random numbers. Before I dive into the source I was wondering if anyone else had looked into this? -Lance no PGP sig because I am on a remote machine. ---------------------------------------------------------- Lance Cottrell loki(a)obscura.com PGP 2.6 key available by finger or server. Mixmaster, the next generation remailer, is now available! http://obscura.com/~loki/Welcome.html or FTP to obscura.com "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche ----------------------------------------------------------

1 0

Re: CJR for perl-RSA t-shirt
by Robert A. Rosenberg 17 Dec '03

17 Dec '03

At 20:58 10/1/95, Robert Hettinga wrote: >>Subject: Mass Market Software with Encryption - 15 Day Expedited Review >> Requested >> >>Subject: Commodity Jurisdiction Request for >> perl-RSA t-shirt, an encryption program > >ROTFL! > I agree. I especially laughed at the part that stated "... also as a bar code, making the t-shirt machine readable as well as machine washable."

1 0

Re: List latency.
by Joel McNamara 17 Dec '03

17 Dec '03

As a non-crypto, latency-related, aside. The USENET newsfeed coming out of uunet to my ISP was non-existent last week. It's improved somewhat, but is still lagging behind by 2 or 3 days (never did this in the past). uunet has not provided my ISP with an explanation as to what is happening. Perhaps it's related to the delay in list messages appearing. Unfounded speculation has been the .edu sites are active again after the summer and are swamping things. Joel McNamara joelm(a)eskimo.com - http://www.eskimo.com/~joelm for PGP key Thomas Jefferson used strong crypto, shouldn't you? >It looks like there's a considerable delay entering and leaving uunet. I'm not sure which >machine gets the blame, but it's either toad&uunet, or uunet&alcor.

1 0

Time Lag (was Re: Yet Another "(Fwd) Internet Euro-Clipper")
by patrick＠Verity.COM 17 Dec '03

17 Dec '03

> > At 12:20 PM 10/2/95, Peter Trei wrote: > > >For those curious about the latency, I'm posting this at 12:08, on the US > >east coast. > >How long did it take to reach you? > > I got it at 09:14, Pacific Daylight Time, so there appears to be no lag. I got it at 11:53 PDT. I just checked the headers and the delay was split in a couple of places. (Correcting all times for PDT) thunk -> 9:10 -> alcor.process.com. (And they're off and running!) alcor.process.com. -> 9:10 -> toad.com. (delivered in 0 time:) toad.com. -> 11:29 -> relay3.uu.net. (Sat on toad 2hrs, 19 min) relay3.uu.net. -> 11:54 -> mail2.pilot.net. (Sat on relay3 25 mins ) mail2.pilot.net. -> 11:53 -> verity.com. (delivered into the past!) Of course these delays can vary a few minutes either way because of inaccuracies of time clocks on various machines. Patrick _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

1 0

Re: Certificate proposal & X509 clarifications
by baldwin 17 Dec '03

17 Dec '03

The Distinguished Name of X509 is NOT intended to be the unique identifier of a person or a public key. In the X509 world two different DNs can have the same public key, and a single DN can have multiple certificates with possibly different public keys. The same public key naturally appears in multiple certificates when each certificate is only valid for a certain period of time (e.g., weekly certificates have been proposed for applications that do not want to implement revocation lists). The unique identifier in an X509 certificate is the DN of the issuer and the serial number that the issuer attached to the certificate. Both of these fields appear in the version 1 X509 certificate. Of course, this assumes that issuers are following the rule of not issuing two certificates with the same serial number. The designers of version 1 of the X509 certificate format have realized that they need to allow issuers to attach all kinds of different attributes to a public key. This lead to version 3 of the X509 format, which provides for general extensions. Of course, this means that there is more rope to hang yourself with when it comes to designing an overall system, but with careful design, lots of good things can be done. For example, for the S/MIME secure mail effort, the certificates include the email address of the owner, as certified by the company that is providing the email post office (e.g., the employer or service provider). Note that Netscape Navigator 2.x will support Version 3 X509 certificates and S/MIME. Question: what's a good way to have the existing PGP public key infrastructure interoperate with the X509 infrastructure? --Bob

2 1

Crypto APIs
by Matt Blaze 17 Dec '03

17 Dec '03

A couple of weeks ago I attended a meeting at the NATO SHAPE Technical Center in the Hague to discuss international cryptographic APIs. Several high-ranking NSA types were there, as well as their counterparts from various NATO countries plus a handful of industry crypto people (like me). The idea of the meeting was to find a way to separate cryptographic function from cryptographic interfaces, in a way that allows the applications that call the cryptographic functions to be more freely exported. That is, I can write and export an application that calls the crypto API but that doesn't actually implement the cryptography, and then, when it reaches its destination, the locally-preferred cryptosystem can be plugged right in. Crypto might be implemented in hardware (e.g., Fortezza) or software (e.g., with a shared library or pseudo-device driver). Obviously, this idea is somewhat (completely?) at odds with the criteria presented at last month's NIST workshops for exportable software key escrow systems. One of the requirements given for such systems is that it be difficult to replace the crypto with something that doesn't implement key escrow. But who ever said the government was consistent? Interestingly, it was clear that many people in NSA believe that applications that call an API are controlled under ITAR, but there is some recognition that this may be wishful thinking or may change soon. So while some (maybe most) of NSA wants to prevent development of standard APIs and prevent the export of applications that use them, others recognize that these will evolve by themselves anyway and will be very hard to control once they do. Anyway, the situation is far from clear. It seems best to encourage the realistic side of NSA as much as possible... I learned a few interesting things at the meeting. First of all, overwhelmingly, there is recognition, especially on the part of the non-US government security agencies, that there is enormous value in being able to buy off-the-shelf applications like Microsoft Word or Netscape Navigator and just plugging in the local military cryptosystem and using it for classified traffic. Everyone seemed to agree that there is a growing need for this and that it's too expensive to rely on custom software. There is also movement away from the traditional military ``link encryption'' approach that involves centrally- controlled secure networks in favor of a ``risk management'' approach that favors end-to-end security with off-the-shelf products. In other words, the parts of the military that are concerned with actually securing communications want exactly what we want, and are just starting to realize it. While lots of us have always known this, I had never heard it articulated as quite clearly (or as loudly) by actual comsec/infosec people before. Second, the senior NSA guy mentioned a few things I hadn't heard before. Fortezza is now approved for classified traffic through the SECRET level. Also, the ``type 1'' (classified) through ``type 4'' (unevaluated) cryptography standard is being scrapped in favor of a three ``tier'' system, as follows (these are approximate quotes, from my rough notes): Tier 1 traffic is stuff related to ``national command authority''. (Seems to be secret and top secret and up). It will require NSA cryptosystems, hardware implementation, and will NOT employ key escrow (because of the ``obvious risks''!). Tier 2 traffic is information that, if disclosed, would have ``national implications'' if revealed. Examples given include things like the national power grid, the banking system, etc. It was unclear whether any classified traffic would be included in tier 2. Clearly, some of what is now called ``sensitive but unclassified'' (SBU) will be in tier 2. Anyway, tier 2 systems will be approved by NIST (not NSA, although there will obviously be NSA input into the standards) and will require hardware implementation. Tier 2 traffic will be escrowed, and the government will escrow its own keys. Fortezza is an example tier 2 device (but read on...) Tier 3 traffic will be that which would have ``private implications'' if disclosed. Examples given included personal financial and medical records, etc. Current SBU traffic not in tier 2. Tier 3 would also be handled by NIST, employ commercial or government key escrow (like tier 2) and would be permitted to be implemented in software. Here's the surprise: Tiers 2 and 3 will be interoperable. So there will be published algorithms for tier 3. It is possible that tiers 2 and 3 will have the same algorithms, and that the government will suggest them. It was unclear with interoperability will require that all tier 2 algorithms will be published and implementable in tier 3 software or whether this means that tier 2 devices will also have to implement the tier 3 algorithms. There is an obvious choice of a tier 2/3 algorithm: Skipjack (although there were concerns that this is ``too slow''). So we may eventually find out whether ``S1'' was really Skipjack after all.... -matt

2 2

Re: worldwide announce: New OTP Mail/FTP apps
by Carl Ellison 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >From: Doug Hughes <Doug.Hughes(a)eng.auburn.edu> >Date: Thu, 28 Sep 1995 19:31:00 -0500 >A company in Israel named Elementrix has just announce at Interop an >entirely new paradigm in secure transactions. They have a secure >one time pad that allows people to exchange mail and ftp files back >in forth in complete security without the worries of key management >or storage or secure random number generation or synchronization. As far as I could tell from your description, this is an autokey cipher -- not a OTP. An autokey cipher starts with a shared secret key and uses previous plaintext or ciphertext as part of the key. DES CBC is an autokey cipher. The original autokey used previous plaintext or ciphertext as the only key. More modern ones mix in the previous text. I had a design for one, several years ago, which kept a mapping in memory and changed the mapping based on incoming plaintext. Therefore, there is state information kept at both sides which keeps changing. One might think that if the attacker never gets in, today's randomness is just as good as yesterday's. That might even be true. However, there are many openings for finding relationships between yesterday's and today's ciphertexts. I look forward to seeing the actual algorithm. - Carl +--------------------------------------------------------------------------+ |Carl M. Ellison cme(a)tis.com http://www.clark.net/pub/cme | |Trusted Information Systems, Inc. http://www.tis.com/ | |3060 Washington Road PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2| |Glenwood MD 21738 Tel:(301)854-6889 FAX:(301)854-5363 | +--------------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMHBTU1QXJENzYr45AQHRigP/Yqw0T3n2SDubgRZIrKx8WpUSJtmBwcuf nIBxxwsOwu10sQti7hw3Zcj9tRM6JAcqFNh1U2LbYT3u7ELgh2Hicq0jLcr+3r4h B0H3LlbU9iv7WlETQF8Tw2KQcfDKLkYkeMRnS27cKnJIFHK9w0g4UTwabfB+m5SV sjnUZbv6Q1A= =P9X7 -----END PGP SIGNATURE-----

1 0