guess who likes anonymous Web surfing...
According to the 12 February Wall Street Journal, the CIA wants to surf the Web anonymously. They're buying a package called Triangle Boy from SafeWeb, though they're replacing the crypto with their own algorithms. And through their venture capital subsidiary (In-Q-Tel), they're buying rights to an equity stake in SafeWeb. The article notes the irony of a privacy company linking up with the CIA. Stephen Hsu, the co-founder, is quoted as saying "I'm sure we'll take a hit from the 5% of our most paranoid customers." And some folks are speculating that the CIA really wants to cloak cyberwar activities, or they want to learn the flaws of the product so they can penetrate anonymity. (Why not -- according to CNN, the NSA claims that Osama bin Laden has better communications technology than we do) --Steve Bellovin, http://www.research.att.com/~smb
Carnivore transformed
Today's Wall Street Journal reports that the FBI is changing the name of Carnivore. It will now be known as the DCS1000 -- the "DCS" stands for "Data Collection System". Clearly, that resolves all of the problems with it. --Steve Bellovin, http://www.research.att.com/~smb
Bleichenbacher finds flaw in DSA
According to CNN, Daniel Bleichenbacher has found a flaw in the
NIST-standard Digital Signature Algorithm. See
http://www.cnn.com/2001/TECH/internet/02/06/DSA.flaw.idg/index.html
for some details. Bleichenbacher says that he'll be presenting the
paper at Eurocrypt; it is not yet publicly available.
The attack is quite expensive; it requires O(2^64) operations, several
terabytes of memory, and 2^22 signed messages.
--Steve Bellovin, http://www.research.att.com/~smb
it's not the crypto
Every now and then, something pops up that reinforces the point that
crypto can't solve all of our security and privacy problems. Today's
installment can be found at
http://www.privacyfoundation.org/advisories/advemailwiretap.html
For almost all of us, the end systems are the weak points, not the
transmission!
--Steve Bellovin, http://www.research.att.com/~smb
Update on NIST crypto standards (fwd)
Forwarded with permission. There is also going to be an announcement on modes of operation; http://csrc.nist.gov/encryption/tkmodes.html should have the information within the next month or thereabouts. --- Forwarded Message X-Sender: [EMAIL PROTECTED] X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 08 Jan 2001 13:20:18 -0500 To: [EMAIL PROTECTED] From: Jim Foti <[EMAIL PROTECTED]> Subject: Update on NIST crypto standards Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: 70f288237482be01d5331b60aec89937 Hello- Here is a brief update on NIST's crypto standards efforts: 1. On January 5, 2001, we announced a Draft FIPS for HMAC (Keyed-Hash Message Authentication Code) that is a generalization of HMAC as specified in Internet RFC 2104 and ANSI X9.71. A 90-day public comment period ends April 5, 2001. Details are available at <http://www.nist.gov/hmac>. 2. On January 2, 2001, we posted a white paper that discusses our plans for developing standards and recommendations for public key-based key management. This will be a two-part process, involving the development of 1) a scheme definition document, and 2) a key management guideline. This paper is available at <http://www.nist.gov/kms>. 3. The Draft FIPS for the AES is anticipated for release for public review in the very near future. Final approvals for the release of this document are pending. When an announcement is made, information on the draft and for providing public comments will be available at <http://www.nist.gov/aes>. Best regards and Happy New Year, Jim [This note is being sent to those people who have attended any of NIST's AES conferences, the Key Management Standard (KMS) workshop in February 2000, the Modes of Operation workshop in October 2000, or who have expressed other interest in our efforts. If you would not like to receive similar notices in the future (which should be infrequent), please let me know, and we will remove you from our email distribution list.] *** Jim Foti Computer Security Division Information Technology Laboratory National Institute of Standards and Technology (NIST) 100 Bureau Drive, Mail Stop 8930 Gaithersburg, MD 20899-8930 USA TEL: (301) 975-5237 FAX: (301) 948-1233 [EMAIL PROTECTED] *** --- End of Forwarded Message --Steve Bellovin
Carnivore draft report released
The draft Carnivore report is at
http://www.usdoj.gov/jmd/publications/carniv_entry.htm
I haven't checked yet to see if any of the redactions are reversible...
--Steve Bellovin
Re: Rijndael among the weakest of the AES candidates
On Mon, Oct 02, 2000 at 10:20:35PM -, lcs Mixmaster Remailer wrote: > Rijndael appears to be a compromise between security and efficiency. > This leaves us in an unhappy and uncomfortable position. It may well be > that Twofish and perhaps Serpent continue to be widely used alternatives > to AES. I expect Rijndael, being the chosen AES, is likely to receive far more analysis over the next few years than any of the other candidates. Assuming there are no major weaknesses found, that analysis should greatly increase confidence in Rijndael as compared to other algorithms. My expectation is based on what has happend with DES. Even though there are other algorithms that are more efficient and probably more secure there is more confidence in 3DES because of the amount of analysis that has gone into it. No other symmetric algorithm is likely to see as much analysis as DES has- except Rijndael.
software patents in Europe
(Not strictly on-topic, but nevertheless of likely interest to many
readers of this list.)
According to the (online) Wall Street Journal, the board of
administration of the European Patents Office has voted to permit
software patents, by a 10-9 vote. Opposition to the change came from
the Germans, the French, and the British; smaller countries, such as
Switzerland, Liechtenstein, and Cyprus, supported it. A German
official is quoted as saying "We would have problems with the U.S.
tendency to patent everything that can be patented. That would stifle
innovation and cause a glut of litigation."
A final decision will be made in November.
--Steve Bellovin
Re: A proposal for secure videoconferencing and video messaging over the Internet
On Thu, Jul 27, 2000 at 10:18:02PM -0700, James A. Donald wrote: > At 05:02 PM 7/27/2000 -0700, Steve Reid wrote: > > Mallory sends The Real Alice an email claiming to be from The > > Real Bob (this can be done with the usual spoofing) , telling Alice > > that she can contact "him" as "Bob'" > > Mallory can do this, but he cannot do it safely. The likelihood of > exposure is very high, and the longer the deception continues, the greater > the prospect it will be exposed. I don't believe it's more "unsafe" than any MITM attack. It's not as if Mallory is a trusted server with a reputation to protect. Mallory could be off somewhere in a country with no extradition treaty, receiving anonymous payments from an interested party. To be fair, the sort of attack I described could work against SSL too. Certificates can confirm that www.example.com is who you are contacting, but certificates can't stop them from making their web site look just like www.example.net's and duping people into giving payment information to the wrong people. I think it would work especially well against a videoconferencing system though, because there is a certain trust inherent in face-to-face communications. > If this is Alice's first contact with Bob through the secure protocol, she > will surely mention how she obtained his address, exposing Mallory. If Alice's first contact with Bob is something like, "Hi Bob, Carol sent me your address...", what are the odds that either Alice or Bob will confirm with Carol that she was the one who sent the information? I don't think we can depend on ad-hoc social protocols to pick up the slack where carefully designed cryptographic protocols have failed. > Suppose Mallory gets away with it once. He cannot go on getting away with > it indefinitely. He doesn't have to get away with it indefinately, just long enough for it to be worthwhile.
Re: names to say in late september
On Thu, Jul 27, 2000 at 03:00:16PM -0400, Arnold G. Reinhold wrote: > I like "Biprime Cryptography," or maybe "Biprime Public Key > Cryptography," where a biprime is defined as the product of two prime > numbers. I doesn't get close to any trademark and it is descriptive > of the algorithm. Sounds like "composite modulus cryptography" which I think has been mentioned on the crypto lists before. "Biprime cryptography" is not really accurate, because RSA doesn't require that the modulus be the product of two primes. I seem to remember someone (I think it was Richard Schroeppel) a few years ago advocating RSA with a three-prime modulus. The idea was that having three primes instead of two would not weaken the algorithm in any practical way, but it could make CRT operations even faster. It wouldn't make the number field sieve any easier because the number of primes doesn't affect NFS workfactor. It would make (I think) the quadratic sieve more efficient, but at normal keysizes (1024 bits?) the three primes would all be large enough that quadratic sieve would still be less efficient than the number field sieve.
Re: A proposal for secure videoconferencing and video messaging over the Internet
On Wed, Jul 26, 2000 at 11:53:07PM -0700, James A. Donald wrote: > Looking at someone's face, and hearing his voice, is good enough in > all common circumstances, and common circumstances means "where the > customers are". Someone can pull off a man-in-the-middle attack without having to "put on make up, [and] declare himself to be the other person". I think MITM could be done effectively against your protocol without requiring special help from the server. Some trivial misdirection is all that is required... Suppose you have a server with a user list like this: ID Owner -- Alice The Real Alice Bob The Real Bob Alice' Mallory Bob'Mallory Mallory sends The Real Alice an email claiming to be from The Real Bob (this can be done with the usual spoofing), telling Alice that she can contact "him" as "Bob'". Later, Alice has something important to discuss with Bob, so she asks the server for credentials for "Bob'". You can probably guess the rest, but here it is anyway: (Honest Server) / | / | / (Mallory) Alice <--> Bob' Now Mallory as Alice' establishes a connection to Bob: (Honest Server) | \ | \ (---Mallory---) \ Alice <--> Bob' / Alice' <--> Bob Mallory silently forwards between Bob' and Alice'. The end result is that The Real Alice is talking to The Real Bob and vice versa. Meanwhile, Mallory calls up Eve: "Bring popcorn." This might be classified as a user interface problem. But as you said, "Looking at someone's face, and hearing his voice, is good enough in all common circumstances". That's why this attack will work. When Alice sees Bob's face and hears his voice, any questions she had about that little apostrophe at the end of his user ID will disappear. When you call someone on the phone, and get the right person, you stop wondering if you dialed the wrong number.
Free speech and the DeCSS case
According to today's Wall Street Journal, the judge in the DeCSS case
against 2600 publisher Eric Corley (better known as Emmanuel Goldstein)
has asked both sides to submit briefs on whether or not software is
speech, and hence protected by the First Amendment.
--Steve Bellovin
Forwarded: Cable modems [and 3 other issues]
llect when applied to electronic communications. 4. On CALEA for the Net, note the following from the Q&A, which is meaningful, of course, only until January 20: > Q I am going to ask -- (inaudible). Your first proposal to expand wiretap >authority to Internet service providers, do you foresee any change in CALEA to >expand CALEA's function and the money associated with that legislation to >cover >ISPs? > > MR. PODESTA: I don't think we are looking at -- I am looking up at my >colleagues here -- I don't think we are thinking about any amendments to CALEA >or to the change of money or to apply that to the ISPs. That was a >decision that was made when CALEA was passed, in 1994, I guess. > Q John, I'm still a little confused about the -- extending these >wiretap-friendly capabilities to ISPs and cable modem providers. >Originally, if >we did that with the traditional phone companies, it resulted in CALEA, >government subsidizing some of the costs. Is it going to be a case where ISPs >and modem providers -- cable modem providers who provide that service will >have >to foot the bill for any technical changes to their software, hardware, or -- >(off mike)? > > MR. PODESTA: I don't anticipate that. And you know, we specifically >-- that specifically was rejected and left out of the bill when it was >passed. We're >having enough trouble trying to manage what we're trying to do under CALEA. I >don't see extending it at this point. --- End of Forwarded Message --Steve Bellovin
More one-time pads cracked?
A recent message (http://cryptome.org/krw-comint.htm) says that NSA
cracked a Chinese one-time pad during the Korean War. Does anyone have
any technical details?
The same posting also implies that the German foreign ministry used a
one-time pad known as GEE; this was also cracked. I've not heard of
GEE, and as far as I knew the ministry used online machines. Does
anyone have any details on either this system or its solution?
--Steve Bellovin
KeyGhost
We all know hardware keyboard loggers are possible. Now there is a commercial product called KeyGhost: http://www.keyghost.com/ Here is an independant review: http://www.dansdata.com/keyghost.htm Several forms are available or planned, each capable of storing 97k or 500k (Pro version) of keystrokes: - Keyboard cable extension with a bump in the wire. - PS2-to-AT / AT-to-PS2 adapter or cable extender with no visible bump in the wire. The hardware is concealed within the connecter. - Regular computer keyboard or Microsoft Natural keyboard with the hardware concealed within the keyboard case. 500k is a lot of keystrokes. Forward-secret protocols won't help you if the plaintexts of all your communications are recorded by one of these.
legal status of digital signatures
According to the AP, U.S. House and Senate negotiators have reached a compromise on legislation that will set national standards for digital signatures and the like. Details are in http://www.nandotimes.com/no_frames/technology/story/0,4500,500213819-500301920-501670828-0,00.html --Steve Bellovin
Re: NSA back doors in encryption products
On Wed, May 24, 2000 at 04:09:45PM -0500, Rick Smith wrote:
> The problem is that you're talking about finding some people with top-notch
> software development skills that can believably be inserted into Microsoft
> under deep cover. They'd have to be able to pursue their backdoor
> installation objectives secretly while continuously justifying their work
> with other, diversionary explanations.
[snip]
> Consider also that commercial developers constantly trade off schedule for
> functionality. How are these guys going to guarantee that they can keep
> their back door working, when some feature crucial to it has been busted to
> support something "more important for the next release"?
They wouldn't need to do any actual coding. They would just have to
insert the code that they received from the windowless building. A
windowless building can house quite a few programmers, so the programmer
hired by [insert software company name here] could appear to be quite
productive. Maybe even extra productive, as I don't think managers are
likely to question productivity. ("Don't look a gift horse in the mouth"
they said, as they wheeled it in through the gates of Troy.)
Re: GPS integrity
A company called Certified Time offers secure NIST-based time data and has many unkind things to say about the integrity of GPS time signals. You might find some useful references among the documents they have posted at http://www.certifiedtime.com/site/repository/index.html At 09:24 AM 5/8/00 +0300, [EMAIL PROTECTED] wrote: > > >I'm looking for info on GPS security, specifically, its integrity / >authentication mechanisms to protect against spoofing. >This is important since many systems assume GPS is a secure source of time >and location. (My interest in this began as we are completing paper on >proactive secure clock synchronization, and figured we ought to compare >this to the approach of using GPS receivers to provide secure time.) > >As recently discussed on this and other lists, the accuracy of commercially >available (civilian) GPS has recently been improved by the removal of the >Selective Availability degradation of the Coarse Acquisition (C/A) signal. >However, after (very limited) digging up some GPS papers/web sites, I >didn't find any mention of authentication/integrity/anti-spoofing >mechanisms to the C/A signal. I did find a brief mention that the (still >encrypted) P/Y signal has some anti-spoofing mechanism; but I didn't see >any details on how that is done (such details may be confidential). > >I'm interested in both the C/A and the P/Y integrity mechanisms. The >anti-spoofing of the P/Y signal is, to me, more of academical interest. I >find the C/A signal integrity more interesting as it is available for >commercial use. How hard is it to spoof it? Is there any real difficulty in >protecting its integrity ? Or is it protected well? > >Thanks for any help/info. > >Best Regards, >Amir Herzberg > >IBM Research Lab in Haifa (Tel Aviv Office) >http://www.hrl.il.ibm.com > > >
Re: Automatic passphrase generation
On Tue, May 02, 2000 at 10:14:14AM -0500, Rick Smith wrote: > Is it really necessary to protect against an attack that orders the phrases > according to how easy they are to remember? Clearly, a practical brute > force attack against the passphrases must be automated. But I don't know of > an algorithm for assessing the "memorability" of a passphrase. The obvious approach would be to start with the shortest, simplest, and/or most common words first. This would try "the happy duck slowly kisses the yellow book" before something like "the aboriginal physicist chemically anodizes the artificial hypotenuse". I don't think it would be difficult to quantify such things- if it's just done on a per-word basis it could be done by hand. There are bound to be more sophisticated methods. If someone needs to brute force passphrases with lots of entropy, it may well be worthwhile to spend a lot of time and money studying what makes a passphrase desirable. If it means that the number of passphrases that need to be tried can be reduced by a factor of several then it may make the process significantly more cost-effective.
Automatic passphrase generation
Here is my first attempt at a passphrase generator that tries to produce proper sentences. The idea here is similar to Diceware except I'm hoping the results will be easier to memorize by having proper sentence structure. Also, it uses /dev/urandom instead of dice. http://sea-to-sky.net/~sreid/passphrase It requires the Moby part-of-speech lexicon (which is now public domain according to http://www.clres.com/dict.html) available at this address: ftp://ftp.dcs.shef.ac.uk/share/ilash/Moby/mpos.tar.Z The program is written in Perl and is only intended as a proof of concept. It is _very_ inefficient, especially with memory usage. Below is some sample output. The amount of entropy per passphrase should be more than 89 bits, or almost the same as seven Diceware words. However, if you generate N passphrases and pick the one that is easiest to remember then you should subtract log2(N) bits from your entropy estimate (assume an adversary knows how to try passphrases in order of easiest-to-remember to hardest-to-remember). 1- the optative furore dankly bedevil the sixty-six creamware 2- the mouthless clepsydras sweatily abdicated the unfelt Commons 3- the talkative admirer cracking endure the declivous Andizhan 4- the unrested Atabrine corruptly graving the stateside flatness 5- the unvibrant kataplasia valorously reissuing the calcareous Portage This is not nearly as good as I had hoped. Does anyone have any suggestions for producing output that is more correct english? I'm wondering if maybe the lexicon I'm using isn't so good. Or maybe my knowledge of sentence structure hmm, with Yoda on par it is. I think this idea was first proposed by someone on either Cypherpunks, Coderpunks or Cryptography a couple of years ago. I don't remember who proposed it but I think the example passphrase given was "the happy duck slowly kisses the yellow book". I don't really expect to generate passphrases that are _that_ easy to remember (there's probably not much entropy there due to the simple words) but I would at least like to generate passphrases that can conjure up some kind of mental image to aid memorization.
key agility and IPsec
(Note to ipsec@ readers -- this is a follow-up to a discussion on the cryptography list a week or so ago. To spare folks who subscribe to both, I've directed followups to the cryptography list ONLY. Subscription to it is via [EMAIL PROTECTED]) Following my exchange of notes with Ron Rivest on key agility for IPsec, I decided to gather some real data. I used a monitoring station on the plaintext side of one of our IPsec gateways to gather 7,000,000 packets in three sessions, two afternoon and one evening. Note carefully that this experiment is preliminary and small-scale. That particular gateway is a Linux box running FreeSWAN; it serves about 180 homes running Linux IPsec appliances (for details on the setup, see http://www.quintillion.com/moat/lisa-moat.ps or .pdf). Most of our endpoints have high-quality (i.e., short path) connections to the gateway. Packet headers were captured via tcpdump; lacking access to the ciphertext (and hence the SPI), I intuited the SA from the remote IP address and knowledge of our address assignment plan. Thus, since most people are assigned /29s, I assumed that I could mask off the low-order three bits of IP addresses in that range and get the security association. I split the received traffic depending on whether the gateway was encrypting or decrypting the packet. Users of this gateway typically have either a non-Windows machine or more than one machine on a home LAN. (People with a single Windows machine generally use a software client, and are homed on a different gateway.) I picked up converstations to about 145 home networks, and about 300 different machines. I made no attempt to account for rekeying; that should be infrequent enough that it wouldn't affect key agility requirements. The network behavior was about as expected. There were more packets to the home than from it (4,189,877 vs. 2,810,123) and many more bytes (1,705,033,395 vs. 297,915,963), for an average of 406 bytes/packet downstream and 106 bytes/packet upstream. While I haven't yet analyzed packet size distributions for upstream vs. downstream, the different average sizes certainly suggest that a larger percentage of the upstream packets are made up of tinygrams. To assess the key agility requirements, I simulated an LRU cache of infiite depth. The number of cache hits at a given depth should then indicate how large a cache would be needed to avoid a new key schedule calculation. (Note: I think that this approach is reasonable -- does anyone disagree?) I could have, but didn't, discard cache entries when too much time had elapsed since the last use, thus indicating a likely rekeying operation. To achieve an 80% hit rate, a cache size of 5 entries is needed for the encrypt (to the home) side, while a 8-element cache would be needed for decryption. To achieve a 95% hit rate, 11 and 17 element caches would be needed. The cache size differences agree with intuition. The gateway decrypt side requires a bigger cache than the encrypt side to achieve the same hit rate; this is probably a function of the mechanisms I suggested a few days ago: smaller packets which allow for more interleaving, delayed ACK strategies, and some lack of "packet trains". IPsec decryption is in some sense more demanding than encryption; since MAC-checking can be done in parallel with decryption, multiple packets can be decrypted back-to-back, without needing to reuse the data path for serial encrypt/MAC generation. On the other hand, the upstream data rate was considerably less, allowing more time for key-switching. I did some preliminary analysis of packet train lengths. Downstream packets show some evidence of packet clustering, though not as much as I had expected -- 60% of the trains downstream were of length 1, compared with 70% of upstream trains. I'm not sure what further analyses I should perform on this data. I do caution people that these are small-scale measurements from one site; I would be very interested to see data from other sites with IPsec gateways, especially big gateways. As I noted, I saw less than 150 SAs; it is not clear to me what would happen with 1500 or 15,000 SAs. For actual assessment of key agility requirements, a larger study is needed. I've attached the output summary files. The first column is the LRU depth; the second is the number of hits at that depth, and the third is the cumulative packet percentage for that depth. (The first line is the number of different SAs, and while it does figure into the cumulative percentages, its effect is obviously minimal.) 0 147 0.00 0 179123942.76 1 712719 59.77 2 470323 70.99 3 298255 78.11 4 203250 82.96 5 149886 86.54 6 116415 89.32 7 92641 91.53 8 73355 93.28 9 58140 94.67 10 44887 95.74 11 33712 96.54 12 24349 97.12 13 17899 97.55 14 12586 97.85 15
nothing major at AES-3...
I spent the week at the Fast Software Encryption and AES-3 conferences in New York. The big news is that there was no big news. All five candidates still look solid, and there were at least as many papers on performance as on cryptanalytic results. Not only that, the former were more enlightening -- what can one conclude from a result (I won't call it an attack) that requires 2^229 partial encryptions, 2^69 bytes of memory, and 2^69 chosen plaintexts -- all to deal with a significantly-weakened version of a cipher? (Let me be fair -- the authors recognize that that isn't even a certificational attack. At most, they say, it may pave the way for future work that is more substantive.) There were several conclusions from the performance studies. First, RC6 and and MARS are by far the worst at key agility. This may be a serious concern for hardware implementations in some circumstances, especially for VPN gateways. (I spoke briefly at the rump session of AES-3 on why IPsec was a very demanding a situation for key agility.) A fair number of people seemed to feel that key agility is a major performance issue, as opposed to just bulk encryption. When looking at hardware implementations, Serpent did very well. This is in marked contrast to its well-deserved reputation for being slow in software. My own view, not necessarily shared, is that all of the algorithms can do at least 10 Mbps on modern CPUs in software without breaking a sweat, and that above that one is likely to be using hardware regardless. There was fairly strong opposition to the idea of picking two "standards". That said, the notion of a primary and a backup algorithm did seem to have broad support. Note that the criteria for a primary/backup pair versus an AES1/AES2 pair are different -- for the latter, I'd be more inclined to pick two choices with different performance niches, while for the former I'd pick an extremely conservative cipher for the backup. My rationale is that they all look very strong today, which means that a real crack would be likely only from major new cryptanalytic results. Such a result would be likely to affect all of the candidates; thus, one would want a backup with a high margin of safety. Besides, by the time one had to switch, Moore's Law would have dealt with many of the performance issues. Which will be the eventual winner? Rijndael still looks like a very strong contender. It's very fast in hardware and software, and (from the comments during the panel session this afternoon) was the second choice of most of the submitters, if their own algorithm were not chosen. Some people feel that Rijndael should use more rounds, out of conservatism; fortunately, its structure is amenable to that. Each of the finalists submitted a summary statement; these should be on the NIST web site (www.nist.gov/aes) shortly. These are worth reading, since they provide a capsule summary of the strengths of each algorithm, plus (in some cases) refutations of the major criticisms leveled against them.
book by Sarah Flannery
Sarah Flannery -- the Irish teenager who had invented a new public key
cryptosystem -- and her father have written a book, "In Code: A Mathematical
Journey". It doesn't seem to be available yet in the U.S.; however,
amazon.co.uk is perfectly willing to ship it. My copy is on order...
--Steve Bellovin
secret-sharing code
Are there any freely-available secret-sharing packages around? Specifically,
I need to be able to set up modestly complex policies to protect a sensitive
signature key.
While source code would be best, I'd also be interested in smart card-based
products.
--Steve Bellovin
Re: please help FreeNet by becoming a node
At 09:56 AM 3/2/00 -0500, Steven M. Bellovin wrote: >It is worth noting that some bans on running servers are based on technology, >not the business model of the provider. In IP over cable systems, there is >much less bandwidth available upstream than downstream, and it's much more >expensive to add more upstream bandwidth than it is to add downstream >bandwidth. If you run a server, you're chewing up a lot of capacity, and >affecting your neighbors. > >But you're right, it's a real concern for users of Freenet (btw, isn't that a >trademarked term?) -- I have the same problem as you do. Seems the firewall restriction is more of a concern. Anyone who cares about their PC's integrity and communication privacy should have a firewall for always-on connections. In the next year or so look for many/most cable modems and DSL boxes to provide a firewall function or have it as an option. --Steve
Re: Justice Department criticizes online anonymity
At 01:36 PM 3/1/00 -0500, Declan McCullagh wrote: >Of more relevance to this list, perhaps, is yesterday's testimony of the >FBI's Michael Vatis with the bureau's usual crypto-complaints: Michael was the FBI chief I put on the spot at the '98 RSA conference. He proudly pitched how the FBI's National Infrastructure Protection Center would deter foreign countries from snooping and penetrating the Internet and communication systems of U.S. corporations. However, he quickly fell silent and stammered when I asked how they intended to protect us from the ECHELON activities of our UKUSA partners. --Steve
Re: Predictable IVs
On Sun, Feb 27, 2000 at 11:36:17PM +1100, Damien Miller wrote: > What risks does using a predictable IV bring? > Background: I am interested in writing an encrypting swap driver for > Linux using a fast cipher in CBC mode keyed from /dev/random at boot > time. If you just use the block number, there are vulnerabilities when you try to encrypt data of a form like this: block 0: 0x123456789abcdef0 block 1: 0x123456789abcdef1 XOR with the block number and you get the same input and output. Anyone who knows what block 0 is can easily figure out what block 1 is, and vice versa. I'm not sure what else can be done with this. The bottom line is that IVs should be random or pseudo-random so that these things can only occur by random chance. Related IVs are bad because they are more likely to coincide with structure in the plaintext. You should probably do what Matt Blaze did for CFS. ECB-encrypt the block number under one key (which should be secret but I don't think needs to be), XOR the plaintext with that, then ECB-encrypt the result with your secret key. This requires two block encryption operations instead of one but at least you're doing something that has stood up to some analysis.
The Zimmerman Telegram
John Keegan's book "The First World War" states that although the U.S. government was informed of the Zimmerman Telegram by British intelligence, the "U.S. State Department" had also intercepted it. This particular claim is not footnoted. Does anyone know anything more about this? I know that Zimmerman (ab)used U.S. facilities to transmit the message, but it was encrypted in 0075 code, as I recall. --Steve Bellovin
Re: The problem with Steganography
On Tue, Jan 25, 2000 at 04:51:12PM -0800, Nelson Minar wrote: > Of course, this isn't easy to do - "matching statistical properties" > isn't a simple closed problem. But I bet you could do fairly well in > certain circumstances. For instance, Linux uses a strong random number > when starting a TCP connections. I bet you can hide a few bits of data > in there and no one will see it. Any protocol that uses MACs (message authentication codes) could also work. Replace the last N bits of the MAC with your encrypted data. The MAC verification would fail at the other end, but if the recipient expected stegoed data there they could check the first (MACsize - N) bits and still detect tampering while receiving the hidden data. This should work because only the participating parties can verify the MAC. To an observer the MAC is just cryptographic noise with exactly the same statistical properties as the ciphertext you want to hide. If the remaining MAC bits authenticated the embedded ciphertext as well as the normal plaintext data then your protocol would function exactly as it did before- If anyone tampered with your data or the MAC then your software would reject the altered data just as it would if you weren't doing any stego at all. This is important because it would prevent your stego activities from being detected by an active attack on the protocol. I think I suggested something like this before, shortly after Rivest's "Chaffing and Winnowing" hit the 'net.
Re: PGP on an e-commerce site
The party that might have a claim against the CA, however, would be the site that was spoofed by an interloper using a bogus certificate improperly issued by the CA. I'm not a lawyer, but off the top of my head I can think of several claims the compromised site could make, including perhaps trademark infringement, interference with contract, neglience, conspiracy... Actually, from that perspective, I don't see why an individual who relied on representations of trustworthness made by a CA and was adversely affected by the negligent actions of that CA would not have a claim, either. Depending on the scale, it might even get picked up by the Federal Trade Commission and/or filed as a class action. At 11:46 PM 1/3/00 -0600, William H. Geiger III wrote: >Well I seriously have my doubts on the liability of any CA as to the >accuracy of their assertions of identity. If you go to a website that has >a VeriSign cert, and the identity info in the cert is wrong, there is no >contractual obligation between VeriSign and yourself. It would be >different if you were paying VeriSign to provide you with certified >identities of 3rd parties but last I looked this is not the business model >that they are using (nor is any other CA).
Re: Debit card fraud in Canada
On Mon, Dec 13, 1999 at 12:12:42PM -0800, David Honig wrote: > Wouldn't a thumbprint reader on the card (to authenticate the meat to the > smartcard) be a tougher thing to shoulder surf? > Does raise the cost over a PIN. I'm not sure if biometrics would help with the sort of attack this appears to be. It sounds like the modified card readers/number pads record everything. The information on the magnetic strip, the PIN entered on the keypad, possibly everything going over the wire too (these devices dial the bank to authenticate). Any biometric information could also be recorded and replayed. I guess it would be more difficult because you couldn't use the information at a regular ATM the way you can with card+PIN; you'd need a compromised machine to feed the information to. > Aren't there protocols where the exchange can't be replayed, but > proof-of-knowledge is demonstrated? That would require a smart card, or a cryptographicly strong operation that the user could do in their head (which would probably get filed under "too hard to use"). Anything depending on a regular magnetic card and PIN would probably be vulnerable to whatever attack we're seeing here. > Or would these exchanges require on-line connectivity, thereby defeating > the utility of smartcards some? I'm not sure if I'd trust a smartcard-based system that didn't require on-line connectivity. From what little I've seen such things usually (always?) depend on the tamper resistance of the device for their security (eg. M*nd*x). The current debit card system requires on-line connectivity to verify the card+PIN and transfer the funds. It's basicly the same as using an ATM machine. If you have a bank account and a card to access that account from an ATM machine, you can use it all over the place instead of cash. Some places even let you withdraw cash when making a transaction. Here in Canada it's about as widely used now at point-of-sale as credit cards are, maybe even more common, but you can't order stuff over the phone the way you can with credit cards.
Debit card fraud in Canada
A real-world example of the fact that cryptography is only part of the equation, and "tamper-proof" devices are not necessarily so. Article: http://www.globeandmail.ca/gam/National/19991210/UDEBIN.html Mirror: http://www.efc.ca/pages/media/globe.10dec99.html
Re: IP: IETF considers building wiretapping into the Internet
On Wed, Oct 13, 1999 at 03:08:49PM -0400, Steven M. Bellovin wrote: > But it's also clear that folks who manufacture this gear for sale in > the U.S. market are going to have to support CALEA, which in turn > means that someone is going to have to standardize the interface -- > the FBI regulations at the least strongly urge that > industry-standard protocols be used for such things. I'm no lawyer, so I'm probably going out on a limb here, but I don't think CALEA can apply to encryption. If you use a 3DES-encrypted phone over a CALEA-compliant carrier it doesn't invalidate the carrier's CALEA compliance. The LEAs still have access to the communications, just not to the plaintext. So in practice CALEA does not guarantee access to plaintext. If CALEA _does_ specify access to plaintext, then what we have are domestic restrictions on encryption, with all of the constitutional issues that go with it. To date the export restrictions have been the only legal means of slowing the spread of strong crypto. CALEA is something entirely different. But I'm still not a lawyer.
Re: Is SSL dead?
On Wed, Oct 06, 1999 at 06:28:45PM -0700, Greg Broiles wrote: > This deserves further explanation. In order to begin an SSL session, the > server must present its public key and its site certificate to the client. I think you're missing the point of the article. The issue is, what happens when the imposter site simply doesn't use SSL? It looks perfectly normal, like the thousands of other sites out there that don't use SSL. The "Location:" field shows http instead of https. How many people would think twice about seeing "http://" in the Location field? The little lock icon in the lower left corner of Netscape stays unlocked, like it does 99% of the time. You wouldn't notice unless you're savvy and alert enough to specificly check for it. The only warning message that might appear is the "You are submitting a form insecurely" dialog. But with all of the web forms out there (search engines, web-based email, useless chrome, etc) that dialog is quickly disabled on many systems- I'd bet nearly all of them. No warnings about certificates because there just aren't any certificates to warn about. Anybody who doesn't make a point of ritualisticly checking security information would likely be taken in.
Re: Ecash without a mint, or - making anonymous payments practical
At 01:36 PM 9/26/99 +0300, [EMAIL PROTECTED] wrote: >There are two reasons. First, as you say below, there is simply the reality of >there being multiple systems. Second, and more essential, there are some >important advantages e.g. in efficiency to non-anonymous payment mechanisms. >BTW, non-anonymous here does not necessarily mean `identity-based`, but rather, >payment mechanism which do not offer complete, secure anonymity. The problem is >of course that if such non-anonymous payment mechanisms are common, it may I wonder, if anonymous systems should get the lion's share of attention so that the shoe is on the other foot, how will you see this situation? >become difficult to convince merchants to support also an anonymous payment >mechanism (with relatively few customers - assuming most customers will not be >willing to `pay` for the anonymity). There is no reason to expect anonymous system will be more expensive than the current book-entry variety, in fact quite the contrary. Furthermore customers choosing the >anonymous mechanism may attract attention to themselves (I guess the use of >`anonymous` for e-mail is a good example!). No more than cash. --Steve
Re: more re Encryption Technology Limits Eased
When we got an export license for Stronghold earlier this year (don't ask), the process consisted of filling out an application form listing the types of encryption and ciphers supported, key sizes supported, etc., then answering a few follow-up questions of that sort from some NSA staffer, and then pestering them for 5 or 6 weeks until they provided a response. No source code review. --Steve Cook At 01:27 PM 9/16/99 -0700, Tom Weinstein wrote: >John Gilmore wrote: >> >> There's a vague and undefined term in the press leaks so far: >> >> One-Time Technical Review >> >> What does this mean? It appeared in some early crypto liberalization >> bills floated in Congressional committees. > >Based on my previous experience with the export process, here's what I think >this means: > > You have to tell the NSA what you're doing and let them think > about it for a while. You'll have to answer any questions they > have, but they aren't likely to ask for source code. It's not > something you want to do the week before you ship. It's a process > that's likely to take a couple months and involve more than one > face to face meeting with NSA people. > >Of course it may mean something completely different. I've been surprised by >what the NSA does more often than not. -- Steve Cook e-mail: [EMAIL PROTECTED] C2Net Software, Inc. http://www.c2.net/ 1440 Broadway, Suite 700fax: 510-986-8777 Oakland, CA 94612 USA tel: 510-986-8770 Ext. 312
Re: crypto file system for Linux: which?
On Fri, Aug 27, 1999 at 11:21:50PM +0100, Antonomasia wrote: > Steve <[EMAIL PROTECTED]>: > > I'm under the impression that CFS uses inode numbers to compute an > > IV. If you restore the ciphertext from backups the inode numbers will > > probably be different and the files will not decrypt properly. > > Seems not. I think the dangling symlinks do the IV. You're right. I wonder when that was added. The first time I configured CFS (I think it was version 1.1.something) I read the docs and was left thinking that inode numbers had to be preserved for proper decryption. My little experiment works as I described it, even on version 1.3.3.1. I didn't copy the .pvect_* symlink and apparently the software reverted back to using the inode information, thus the ln worked while the cp didn't. I'm guessing this is for backwards compatibility. So the bottom line seems to be that it's version-dependent. As long as the .pvect_* dangling symlinks get backed up along with the ciphertext files things are in good shape, unless your CFS is too old to create those symlinks in the first place.
Re: crypto file system for Linux: which?
On Thu, Aug 26, 1999 at 06:55:20PM +0100, Antonomasia wrote: > I have tested that samba and cfs under linux will work together, > i.e. you serve plaintext across the net and it's magnetic home is > as cyphertext where CFS directories have been made. It's the cyphertext > that you get backed up on tape. Have you tried restoring from backup to make sure that it works? I'm under the impression that CFS uses inode numbers to compute an IV. If you restore the ciphertext from backups the inode numbers will probably be different and the files will not decrypt properly. Try this: copy a CFS ciphertext file from one ciphertext directory to another. Then attempt to read the plaintext of the new file. The filename and length are correct but the contents are corrupt. If you use ln instead of cp the file will read correctly, because the inode number is still the same. > I have not tried soft RAID and how it might interact with the above. It should not be a problem. CFS doesn't really care how the ciphertext is stored as long as the inode numbers don't change.
Internet lobbying group
According to the Wall Street Journal, nine Internet firms (AOL, Amazon.com, Yahoo, eBay, Excite@Home, DoubleClick, Inktomi, theglobe.com, and Lycos) have formed a Washington lobbying group. The purpose is to focus on issues of concern to Internet companies. The article does list privacy regulation as a concern of the group; it does not list encryption, which strikes me as an obvious choice. It is possible that this group will be quite influential, especially if more online firms join. To the extent that our employers are or may become involved, we may want to lobby internally to make sure that the group does the right thing about encryption. (There are also privacy issues; those are largely out of charter for this group, so I'll say no more on that subject here.)
Re: Encrypting filenames
> From: Bill Stewart <[EMAIL PROTECTED]> > To: Steve Hawkinson <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: Encrypting filenames > > At 04:00 PM 7/10/99 -0500, Steve Hawkinson wrote: > >Does anybody have any ideas on what would be a good algorithm for > >encrypting filenames? I would like for the alogorithm to do compression > >also. CFS uses an algorithm that lengthens the filename, thereby shortening > >the maximum allowed length of the clear text filename. I want to avoid > >this and possibly store extra metadata in the filename. > > What are you trying to accomplish by encrypting them? I want to provide as much security as possible for the clear text name of the file. > What's the environment you're planning to use them in? I am working on a piece of middleware that modifies the system calls of programs that are running on top of it. I can change an open(foo) system call to open(xdsxfda) and close(foo) to close(xdsxfda). I can also change the size of the file so stat(foo) is stat(xdsxfda) and in the process of changing the name I change the file size in the stat buffer also. The kernel sees all the operations on "xdsxfda" and the program and user think the operations are being performed on "foo". It runs in linux right now. I don't think the OS should make a difference in the algorithm we use, except that it limits the length of the filenames. I will probably truncate the filenames to the max length of the OS and then apply the cryptographic algorithm. I also would like to store the length of the file in the filename. That is why I need compression. If I have a MAX_PATH length of 14 and my file size is 1 meg and the clear text filename is 14 characters long. I have a clear text of "fourteenletter.100". I would like to be able to store that securely using 14 printable characters. This is a worst case scenario since most modern filesystems have a much longer filename length, more like 255 characters. Plenty of room for my metadata, he, he. I should get more compression on a filename that is 255 characters long also. I realize that any compression technique is going to have a worst case of no compression or even increase redundancy. However I would still like to make an attempt at compression of the filenames. > What's your threat model? This is a tool that people can use to encrypt arbitrary data. Any program that writes to disk can be run on top of it. So the data can be anything from Grandma's secret cookie recipe to medical records. The data will be stored for long periods of time in an untrusted environment. ex. filesystems that a sysAdmin can browse. > Is it ok to always use the same key? (Thus, 3-DES is fine.) I would like to change the key for each file. > Do you need two-way encryption, or is a 1-way hash adequate? Yes I need two-way encryption. So I guess a more quailfied question is what is a good two-way, multikeyed, high-compression, highly-secure over indefinite periods of time, cryptographic algorithm? Thanks for your time, Steve
Encrypting filenames
Does anybody have any ideas on what would be a good algorithm for encrypting filenames? I would like for the alogorithm to do compression also. CFS uses an algorithm that lengthens the filename, thereby shortening the maximum allowed length of the clear text filename. I want to avoid this and possibly store extra metadata in the filename. Also does anybody know of an encrypted filesystem that encrypts the names of files, besides CFS. Steve
Padlock Size was Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
On Sat, Jun 26, 1999 at 01:09:36PM -0400, Nelson Minar wrote: > popped up. I was shocked to see that the certificate was being used > with a 40 bit cypher. I have no idea what info has been leaked out > that channel. You can disable 40 bit crypto via 'Security>Navigator>Configure SSL v2/3' > The point is that in Netscape, it is very hard to tell if a given link > is 40 bit or 128 bit. Sure, with enough poking around looking at page > info you could probably figure it out. Or maybe someone knows if the > little padlock means something like the little key used to. But I'm a > crypto-sophisticated person, and I don't know. What about people who > don't understand the technology at all? Good point There used to be two keys I believe a little (weak) key and a larger (strong) key. In the (patched to domestic US strength) version of Netscape I use (Linux 4.07) the padlock is always the same size. It may be my version is broken. Anyone with a legit. US browser confirm that this visual cue (icon size) has been removed? -- 1024/D9C69DF9 steve mynott [EMAIL PROTECTED] http://www.pineal.com/ the older i grow the more i distrust the familiar doctrine that age brings wisdom. -- h. l. mencken
Shamir's factoring machine
Shamir's paper describing his design for a factoring machine is now available (with permission) at http://www.research.att.com/~smb/twinkle.ps -- I'll leave it there for a few weeks.
tapping the nte
To: [EMAIL PROTECTED] From: Dave Farber <[EMAIL PROTECTED]> Subject: IP: "Intercepting the Internet" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: [EMAIL PROTECTED] Precedence: list Reply-To: [EMAIL PROTECTED] >From: "Caspar Bowden" <[EMAIL PROTECTED]> >To: "Dave Farber (E-mail)" <[EMAIL PROTECTED]> > > >http://www.newsunlimited.co.uk/The_Paper/Weekly/Story/0,3605,45981,00.html >Intercepting the Internet > >A secret international organisation is pushing through law to bring in >eavesdropping points for websites and other forms of digital communication. >Duncan Campbell reports > >Thursday April 29, 1999 > >European commission documents obtained this week reveal plans to require >manufacturers and operators to build in "interception interfaces" to the >Internet and all future digital communications systems. The plans, drafted >by a US-led international organisation of police and security agencies, will >be proposed to EU Justice and Home Affairs ministers at the end of May. They >appear in Enfopol 19, a restricted document leaked to the London-based >Foundation for Information Policy Research >(http://www.fipr.org/polarch/index.html) > >. The plans require the installation of a network of tapping centres >throughout Europe, operating almost instantly across all national >boundaries, providing access to every kind of communications including the >net and satellites. A German tapping centre could intercept Internet >messages in Britain, or a British detective could listen to Dutch phone >calls. There could even be several tapping centres listening in at once. > >Enfopol 19 was agreed by an EU police working party a month ago. It was >condemned last week by the civil liberties committee of the European >Parliament. But the European Parliament will shortly dissolve to face >elections in June. Meanwhile, EU ministers are preparing to adopt a >convention on Mutual Legal Assistance, including international interception >arrangements. > >If the Enfopol 19 proposals are enacted, internet service providers (ISPs) >as well as telecommunications network operators face having to install >monitoring equipment or software in their premises in a high security zone. > >Ministers were told two months ago that an international committee of >experts regarded new European policy on tapping the internet "as an urgent >necessity". But they will not be told that the policy has been formulated at >hitherto secret meetings of an organisation founded by the FBI. Known as the >International Law Enforcement Telecommunications Seminar (Ilets), police and >security agents from up to 20 countries including Hong Kong, Canada, >Australia and New Zealand have been meeting regularly for seven years. > >The Ilets group was founded by the FBI in 1993 after repeatedly failing to >persuade the US Congress to pass a new law requiring manufacturers and >operators to build in a national tapping network, free of charge. Since >then, Ilets has succeeded in having its plans adopted as EU policy and >enacted into national legislation in a growing number of countries. > >The group first met at the FBI research and training centre in Quantico, >Virginia, in 1993. The next year, they met in Bonn and agreed a document >called the International Requirements For Interception, or IUR 1.0. Within >two years, the IUR "requirements" had, unacknowledged and word for word, >become the secret official policy of the EU. They became law in the United >States. > >In June 1997, the Australian government succeeded in getting the >International Telecommunications Union (ITU) to adopt the IUR requirements >as a "priority". It told the ITU that "some countries are in urgent need of >results in this area". Ilets and its experts met again in Dublin, Rome, >Vienna and Madrid in 1997 and 1998, and drew up new "requirements" to >intercept the Internet. Enfopol 19 is the result. > >Linx, the London Internet Exchange, is the hub of British Internet >ommunications. According to Keith Mitchell, chairman of Linx: "Anything >along the lines of the Enfopol scheme would probably have astronomical cost >implications. In the event such a scheme was ever implementable, the costs >should be met by the enforcement authorities. Since the industry cannot >afford it, I doubt the public sector could "This kind of monitoring approach >is based on a world view of telecomms operators which is both technically >and economically outdated." --- End of Forwarded Message
McCain and 64-bit crypto
Before cheering too much about McCain's apparent change of heart, it's worth doing some arithmetic. 64-bit ciphers are vulnerable to a brute force attack that costs 256 times what an attack on the same 56-bit cipher would cost. Plug in EFF's 250K and you see that a similar design would cost $64M. That's probably adequate for commercial security, but it won't protect you against a government. Add in a few generations of Moore's Law, and it becomes obvious that even business-grade security won't be available for very long. Is the bill an improvment? Sure. And the new review board is a definite improvement. But I think that there's less here than meets the eye -- or the wiretap.
Re: [John Gilmore ] RSA claiming trademark on all uses of "RSA" to describe algorithm
At 02:09 PM 4/1/99 -0500, Perry E. Metzger wrote: >> Security Dynamics Technologies, Inc. has sent a letter to the P1363 >> working group regarding trademark protection of the RSA name. The letter >> is now available from our patents page >> http://grouper.ieee.org/groups/1363/patents.html >> or directly at >> http://grouper.ieee.org/groups/1363/letters/SecurityDynamics.jpg > >Now that their patent is getting ready to expire (next fall), RSA is >trying to crack down on anyone who refers to the use of the >algorithm by calling it "RSA". They don't mind if you call it "type >1" or something else meaningless and irrelevant, though. This is a >new low for a company known for self-serving legal bluster. I should think that the approach taken by generic pharmaceuticals, 'compare with Brand X,' would also suffice to get around RSA's trademark issue. --Steve
Re: 1024 bit RSA exportable?
At 01:46 PM 3/31/99 -0800, John Gilmore wrote: >> The way I read it, if you are using RSA for authentication, there are no >> export restrictions (except perhaps the awful 5 nations). You do not need >> to get a license. > >I concur. The awful 5 nations aren't even embargoed, if your export >is "publicly available", which exempts you from the EAR totally >(section 732.2). However, if you *ask* BXA about this, they may well >tell you that your export is illegal even if the regs plainly exempt >it. (They did that to Hugh Daniel about an old DNSSEC prototype; see >http://www.toad.com/dnssec/. Hugh has appealed this and we'll see >what the result is.) Meanwhile, my suggestion is to: > > * Get a good export lawyer > * Read the regs. Follow the instructions in them. > * Export what the regs permit you to export. > * Don't ask BXA any questions if you can help it. Rely on > the well established principle of "rule of law". Yes, at the President's Export Council Subcommittee on Encryption meeting in Palo Alto a few months back, William Reinsch (Under Secretary for Export Administration) grudgingly admitted that companies and individuals were under no obligation to submit their wares to the BXA prior to export. --Steve
Re: Status of Fortezza and/or Smart Card Encryption Technology
http://www.jya.com/fort-cancel.htm This URL is somewhat contradictory to what is written below. "Arnold G. Reinhold" wrote: > At 8:17 AM -0500 3/25/99, Roberts Teddy wrote: > >Does anyone know what the current ((March 99) status of fortezza > >encryption? The NSA waiver for using this card to protect classified > >data over unclassifed networks has expired. Does this mean that > >Fortezza no longer provides "adequate" protection for sensitive data? > >Or...how strong is fortezza now? > > > > Are there any other cards presently out there that are sanctioned for > >use to protect classified data over unclassified networks? > > > > From NSA's home page: http://www.nsa.gov:8080/programs/missi/frt+.html > > >FORTEZZA® Plus (KOV-14) > ... > > > >FORTEZZA Plus is an evolutionary member of the FORTEZZA PC card family, > >providing additional security > >capabilities. The Government algorithms employed in the FORTEZZA Plus card > >can provide security services to > >protect information of any classification level, although system security > >capabilities depend on many other > >components. The FORTEZZA Plus algorithm set maintains backward > >interoperability with the FORTEZZA Sensitive > >But Unclassified (SBU) security services. > > See also Mykotronx's Fortezza Plus page: > http://www.rnbo.com/MYKOWEB/fzplcard.htm > The performance numbers are interesting. > > Arnold Reinhold begin:vcard n:McGee;Steve tel;pager:888 762 4062 tel;fax:732 229 7275 tel;home:732 229 7275 tel;work:732 389 6709 x-mozilla-html:FALSE adr:;; version:2.1 email;internet:[EMAIL PROTECTED] fn:Steven McGee end:vcard
Re: questions on AES analysis
At 10:00 AM 3/25/99 -0800, Eric Murray wrote: >Yow! That doesn't sound like any smart card I know. >Does it have a display and keyboard and run WindowsCE :-) > >Currently shipping 7816 cards max out at about 32k of FLASH >for program and data, and a few K of RAM. Most are 8-bit processors >but there's been some work on putting a 32-bit ARM in cards. I worked on a Cylink smart card a few years back. Besides cost, two of the toughest challenges to advaced smart cards are staying with the power supply budget and meeting the flex test (particularly bad on large die sizes). --Steve
Re: references to password sniffer incident
At 08:35 AM 3/25/99 -0800, Jurgen Botz wrote: >Yes, I could demand that all my remote users be running NT4.0SP4 with >some additional security patches and have all their services turned >off (or better still, Linux or *BSD configured by my network >engineers), but how am I going to enforce this? Simply put it's >administratively impossible... the machines of the remote users are >beyond my control and must be assumed to be completely insecure. > >The approach I'm hoping to take (for lack of a better alternative) is >to give people IPSec access but to try to ensure that at any time that >they are tunneling into our network their machine is not reachable by >any means /except/ through the tunnel. Establishing the tunnel will >require authentication with a hardware token (this is what we're >currently doing for Ssh, too... I've learned the hard way that I can't >trust people to use strong passphrases even after practically pleading >with them to do so). The result will be that at least their machine >can't become an outright gateway into our network, although it might >still be used as a springboard by an attacker aware of the mechanisms. >Compromises, compromises. Its no worse than allowing laptop telecommuters (with possibly compromised systems) dial-in, as is now the common practice. --Steve
Re: VeriSign OK'd for strong-crypto exports (was Re: ECARM NEWS for March 10,1999 Second Ed.)
VeriSign received permission to issue VeriSign's Global Server ID digital server certificates to several, fairly broad categories of users located in any of the 44 listed countries. This permission was granted under the BXA's recently-issued license exception "ENC". This same license exception is available for most crypto products; C2Net recently received an "ENC" export license for our Stronghold web server. Stronghold is made outside the US, so it's available worldwide even the export license, but we had to get a license for it so VeriSign could be allowed to issue GSID certs to sites running Stronghold. GSID certs were announced last year by VeriSign and Netscape. Microsoft quickly followed with their equivalent "Server Gated Crypto". These systems use special certs to switch regular 40-bit "export grade" browsers into 128-bit mode. (Obviously, the browsers must be designed to recognize the certs and must have 128-bit code built in. All Netscape and MSFT "export" browsers released since early last year have this facility.) Web sites wishing to conduct secure e-commerce with non-US based customers are the primary audience for the GSID certs. Companies can also use GSID certs on intranet servers to provide secure access from their non-US sites. The beauty of the system is that it's already built into most of the browsers currently in use around the world, so it's completely transparent for the end user. VeriSign has a real lock on this; the problem for competitive CA's is that the system requires a corresponding root cert be installed in the browser. VeriSign's have been distributed with the browsers for over a year now. In theory, a user could install a new root cert upon visiting a site for the first time, but few e-commerce sites are interested in putting off potential customers with such a procedure. For this reason, VeriSign can get away with charging $895 per year for GSID certs as opposed to $349 for regular certs. The downside of the GSID scheme is that the certs expire annually, and companies who rely on them are at the mercy of whatever rule changes might be made in the future (mandatory escrow of the private key for the GSID cert comes to mind). The GSID certs are hopefully a temporary "solution" and it would be best to discourage anyone from relying on them too much. C2Net's SafePassage Web Proxy is an alternative solution, but it must be downloaded and installed by the end user. Fortify is another solution, basically a patcher that "upgrades" export-grade Netscape browsers to run 128-bit crypto but it likewise requires active effort by the end user. Ultimately, widespread use of Cryptozilla or other full-strength browsers is the best solution. At 02:50 PM 3/11/99 -0500, Richard D. Murad wrote: >Does anybody know if any "strings" were attached to this? > >Rick Murad > >At 07:02 PM 3/10/99 -0500, Robert Hettinga wrote: >>At 2:00 PM -0500 on 3/10/99, [EMAIL PROTECTED] wrote: >> >> >>> Title: VeriSign OK'd for strong-crypto exports >>> Resource Type: News Article >>> Date: March 8, 1999, 12:10 p.m. PT >>> Source: CNET News.com >>> Author: Bloomberg News >>> Keywords: EXPORT CONTROL ,ENCRYPTION ,SOFTWARE,GOVT APPROVAL >>> >>> Abstract/Summary: >>> VeriSign, a top maker of encryption software that keeps online >>> transactions secure, said it was given approval by the government >>> to sell strong versions of its software outside the United States, >>> sending its shares to a record high. >>> >>> VeriSignsaid the Commerce Department's Bureau of Export >>> Administration gave approval for it to sell 128-bit data >>> encryption technology to overseas subsidiaries of U.S. companies, >>> online merchants, and health-care and insurance organizations. >>> >>> >>> Original URL: http://www.news.com/News/Item/0,4,33447,00.html?pfv >>> >>> Added: Tue Mar 0 9:0:0 22:2 1999 >>> Contributed by: Keeffee >> >>- >>Robert A. Hettinga >>Philodox Financial Technology Evangelism <http://www.philodox.com/> >>44 Farquhar Street, Boston, MA 02131 USA >>"... however it may deserve respect for its usefulness and antiquity, >>[predicting the end of the world] has not been found agreeable to >>experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' -- Steve Cook e-mail: [EMAIL PROTECTED] C2Net Software, Inc. http://www.c2.net/ 1440 Broadway, Suite 700fax: 510-986-8777 Oakland, CA 94612 USA tel: 510-986-8770 Ext. 312
Re: PGP compromised on Windows 9x?
> But what you imply, that PGP (and other programs that request passwords > and passphrases from the user) should be more picky in what it accepts, is > an excellent idea. Of course, it's impossible to force the user to choose > a good passphrase, but requiring no fewer than, say, 12 characters that > look 'random' (upper, lower, digits, and punctuation), or no fewer than 30 > characters that look 'regular' (English text) would not be a bad idea. In principle, that's not a bad idea. In practice, it's very hard to make something foolproof because fools are so damned clever and persistent. In other words, people *aggressively* pick bad passphrases.
Re: Pop Count Instruction and crytanalysis
In message <00a701be4bcc$7c9f9f80$[EMAIL PROTECTED]>, "Jitze Couperus" writes: > > Some 30 years later, I find the paper cited by Steve Bellovin > on "Probable Plaintext Cryptanalysis" to be extrememely > interesting - in particular it cites another paper > about "A Programmable Plaintext Recognizer". This is > the only open documentation I have ever come across that > discusses this kind of mechanism in any detail. Thanks for a very interesting article. The other paper you cite is by David Wagner and myself, and can be found at http://www.research.att.com/~smb/papers/recog.ps (or .pdf).
Re: Pop Count Instruction and crytanalysis
In message <003901be4af4$ea5b9a20$[EMAIL PROTECTED]>, "Jitze Couperus"
writes:
> John Mckay wrote:
>
> About the "sideways add" or pop-count instruction - indeed
> Seymour Cray's first supercomputer (the Control Data 6600)
> sported such an instruction, as did all subsequent Control
> Data machines until the advent of the 180 series in the mid
> '80s.
>
...
>
> We always wondered what such an instruction might be useful for -
> until one of the first of the 180 series (n'th generation successor
> to the 6600) was delivered to such a customer, and cries of
> anguish erupted that this machine didn't have such an instruction.
> We scrambled and had to create a very tight code sequence within the
> instruction stack that could be generated via a Fortran intrinsic
> function.
For years, I had heard the story about NSA liking that instruction.
But I never understood why, until I started working on plaintext recognizers,
and independently derived the need for it. See, for example,
http://www.research.att.com/~smb/papers/probtxt.ps.
There are other instruction types that are useful for cryptanalysts.
The CDC Star had a lovely set of vector operations under masks. And
the Harvest add-on to the IBM 7030 (Stretch), described in a book by
Buchholz ("Planning a Computer System", McGraw-Hill, 1962) was intended
for NSA as well.
Re: Intel announcements at RSA '99
In message <[EMAIL PROTECTED]>, Colin Plumb writes: > > Well, as I mentioned, I said so in fairly emphatic terms once already, > although I don't know whether such access was planned or if my comments > had any effect. I'm having another, more detailed discussion with the > responsible designers on thursday. I'll have to find out what details > are okay to repeat here, but I can obviously discuss what I plan to > bring in. What I was told at RSA was that the SHA-1 whitening was done by the driver. The driver (I think it was the driver, rather than the hardware) also does its own quality checks on the hardware RNG. > > My basic point is the same as the above: software can whiten the bit > stream just as easily as hardware, so including any such processing > in hardware is not a very valuable use of transisitors. However, > access to the unwhitened bitstream is essential for quality assurance > purposes. Serious users need that to assess the quality of the random > numbers and, indeed, whether the generator has failed entirely. > > If anyone would like to add the weight of their names to my discussion, > I'd be happy to include a list of people who agree with me. > > Just send me some e-mail with > - Any contact information beyond name @ e-mail you want oe to include > - Any amplification on my basic point that you'd like to include. > - A title, position, or similar brief statement of qualifications > > Does that seem reasonable? > -- > -Colin > > (I'm also curious what people think is a good rate. I think we surprised > them by saying that one bit per second was adequate. Anything more can > be generated by cryptographic means.) I asked about speed; I was told that that isn't public yet. I do not agree that one bit per second is adequate. Apart from any question of the strength of the cryptographic RNG, it means that it would take many minutes to have enough entropy for even a single true-random DH exchange. Their own goal was "fast enough for IPSEC", which is not that fast, though more, I would guess, than your statement.
Intel announcements at RSA '99
Intel has announced a number of interesting things at the RSA conference. The most important, to me, is the inclusion of a hardware random number generator (based on thermal noise) in the Pentium III instruction set. They also announced hardware support for IPSEC.
DES Cracked in 22 hrs 30 mins
Date: Tue, 19 Jan 1999 14:08:10 -0600 To: [EMAIL PROTECTED] From: Scott Schram <[EMAIL PROTECTED]> A partnership between Distributed.net and the Electronic Frontier Foundation has successfully decoded a DES message encrypted as a challenge by RSA, demonstrating that DES is not secure. http://www.distributed.net http://www.rsa.com "You don't have to work all day long to break DES Press announcement soon!" http://www.eff.org "EFF's DES Cracker makes headlines again! Working with Distributed.Net, our machine was the winner of RSA's DES-III Challenge (DES Cracker accounted for 80mil. of the total Distributed.Net 220mil. keys per second) - press release forthcoming (Jan. 19, 1999)" and >From http://www.distributed.net (Since it's difficult to get on there right now:) --- It is with considerable excitement (and quite a bit of relief) that I can now announce that the DES-III contest is officially ended. At 07:15 am PST (14:15 UTC), just about the time when we all started getting worried about the 24-hour waypoint, the solution to DES-III arrived. The winning key, 92 2C 68 C4 7A EA DF F2, revealed the plaintext message: The unknown message is: See you in Rome (second AES conference, March 22-23, 1999 The winning key was found by EFF's Deep Crack hardware, and submitted to the distributed.net servers immediately. RSA confirmation of the success followed shortly thereafter. It's truly been a joy and a thrill to work with John Gilmore and the other talented and clued people at EFF. Were it not for their contributions to distributed.net, the 24-hour deadline would have been a much more difficult goal to reach. I'll be running stats for the partial 19-Jan work up to the point of success and posting them this afternoon for the archives. More details will follow soon as the dust settles, RSA is planning a 12:00 noon PST announcement at the RSA '99 Convention. Both John Gilmore and our own Peter Gildea will be in attendance. Here's a few statistics on our aggregate success: Start of contest: January 18, 1999 at 09:00 PST End of contest: January 19, 1999 at 07:15 PST Elapsed Time: 22 hours 15 minutes Percentage Complete: 22.2% Size of keyspace: 72,057,594,037,927,936 Keys Tested: 16,017,142,616,948,736 Blocks Tested: 29,834,253 Overall Keyrate: 199 Gkeys/sec Peak Keyrate: 250 Gkeys/sec --
"publishing" inventions
I asked a friendly patent attorney. The Patent Office accepts what are called "statutory invention registrations" that serve this purpose. I don't know how to file one, or what they cost.
US Law re Foreign Residents
Greetings, all. I'm trying to get a handle on US law regarding sharing of crypto with foreign nationals. Let's say I'm a US citizen residing in the US, have an interest in strong crypto, and have an acquaintance who is a foreign national. How much access can I give my friend to my computer and my home office? I've identified a few dimensions to create scenarios, and a few points on each dimension. - An allied nation, eg Canada - A friendly or neutral nation, eg Finland - An awkward nation, eg PRC - A hostile nation, eg Libya - A friend who comes by to use my computer on occasion - A roommate who uses my computer regularly - A girlfriend who sometimes uses my computer - A live-in girlfriend - A new spouse who plans to become a US citizen but is currently a foreign national - I have install disks for the domestic-only versions of commercial apps such as Netscape Communicator - I have PGP or GPG installed and configured but it does not automatically run for email - PGP/GPG is always available for email or from the Windows Explorer - I have the source code for strong crypto in electronic form - I have source code for strong crypto in treeware - I have articles and books discussing crypto, possibly with code snippets, in printed or electronic form - I develop strong crypto, and have code, working papers, and the like available in printed and electronic form - I am helping my friend become a more proficient computer user by showing the use of "user" apps, which may have built-in strong crypto - My friend is already a proficient user and can encrypt or sign a document or mail message - I am helping my friend become a more proficient programmer and he or she has an interest in crypto - My friend is already a proficient programmer and can implement strong crypto Now, since answers to all of the cases is a bit much to ask, here's one scenario of particulerest to me: A girlfriend from the PRC; she's a new programmer and I'm working with her on improving her skills; I have _Applied Cryptography_ on the shelf, source code on my computer, and PGP installed. Thankee Kindly, Steve Furlong
RSA's Australian deal
According to today's Wall Street Journal, RSA is going to market "compatible technology" developed by Eric Young and Tim Hudson, via an Australian subsidiary. This is an end-run around the export rules, and has already been approved by the U.S. Dept of Commerce. "The key to that is neither U.S. technology or U.S. personnel could be involved in making the product", according to DoC. The article does note the recent Wassenaar Agreement, which might induce Australia to regulate crypto exports, too.
Re: Commerce Press release on Wassenaar "adjustment"
This really is _really_ bad. Finland, Canada, Ireland..all member countries of this arrangement, had previously liberalized their encryption export policies. Not really too surprising. The U.S. gov't has been pushing for this for some time. This may make things a bit more difficult for some software developers for a while, but not for long. The major companies will, of course, immediately knuckle under (look for NA to adjust PGP to adhere). This will leave the road wide open for the adventurous among us, especially the open source folks (e.g., Mozilla tweekers). Like a fistfull of sand, the harder they squeeze the more will run through their fingers. --Steve
Re: Wassenaar vs. CipherSaber
In message <[EMAIL PROTECTED]>, Jim Gillogly writes: > "Arnold G. Reinhold" <[EMAIL PROTECTED]> writes: > > ... descriptions on the CipherSaber web site http://ciphersaber.gurus.com . > .. > > > Any comments, suggestions, endorsements and publicity are welcome. > > I'll endorse it -- the pages give a good overview of the problem and solution > , > and it is indeed easy to implement and test: one interested novice programmer > with little crypto background was able to crank out a version (I think he > used VB) in under a day that interoperated with mine. I've plugged it here > and there, including in my "President's Column" for the American Cryptogram > Association during my tenure (which ended this year). > > It's a nice idea, since it's still legal in most countries to write and > run your own code and to exchange encrypted information, even if you're > not allowed to export the code. I'm glad the site is up, but for many purposes it solves the wrong problem. Encryption algorithms are easy to write, or even to type in or scan from printed programs. But what's interesting is easy-to-use crypto, or crypto that can interoperate. Remember that most of PGP is *not* crypto algorithms.
Re: Reuters story-Wassenaar on crypto
In message <896C7C3540C3D111AB9F00805FA78CE2013F85F3@MSX11002>, "Brown, R Ken" writes: > > More to the point - I have*only* seen that Reuters press release or comments > based on it so far. The NY Times story is at http://www.nytimes.com/library/tech/98/12/biztech/articles/04encrypt.html
