Re: copy protection
Lenny Foner wrote: But the world is -different- now. The DMCA exists, and its anticircumvention language will be used as a bludgeon to sue and perhaps even lock up people who do anything to bypass the crypto in the disk. Thus, a purely technical solution This assumes I own the disk. Why should I be so stupid as to pay for my own bondage tools, not even being kinky? As long as there are alternatives? Don't tell me I can't find a crypto-free mass storage vendor. Especially, since they have to pay *royalties* for putting it in. IBM does make fine drives, I'll be sad to buy Maxtor's. My heart is bleeding, honestly. Can't say anything about Intel, never bought their silicon. Toshiba, either. The fourth one in the quartumvirate I forgot, so it can't be all that important. Dust in the wind. can't be deployed in any way that really helps a large number of people---it can't be put into Linux, for example, if the CSS cases Why? Anything The Man can do about Freenet, or MojoNation? Especially, if the successors of it are indistinguishable from an SSL browser session? No one can pull the plug on the Net now, and we're faster than the countermeasures. are won by the DVDCCA, and no commercial vendor will risk it, either. The worse for the commercial vendors. I can get my Debian off the net just fine, thanks. Remember also that in the case of DeCSS, the original creator wasn't even in a region that is subject to US law! At least, in theory... Right, in theory. Unenforcible laws are not worth the dead tree they're printed on. In fact, any unenforcible laws make immature me violate them as frequently as possible, just because I can, and not supposed to, and no one can do anything about it. Kinda makes one look stupid for concocting the law in the first place. So -if-, by some happenstance, commercial vendors somehow manage to convince themselves and their customers that this is somehow a better world, and their customers fail to vote with their feet (perhaps Don't kid yourself. No one is that kind of stupid. If they indeed are, then it's not worth fighting for, anyway. Looks clearly win/win to me. because they are given no choice? there aren't -that- many hard disk vendors these days), technical workarounds will be litigation targets. The more pressing the need for open hardware, and putting the means of production on people's desks. Less than a decade to wait, I'm betting. -- __ icbmto:N 48 10'07'' E 011 33'53''http://www.lrz.de/~ui22204 ED 90 04 33 EB 74 E4 A9 53 7F CF F5 86 E7 62 9B 57 F9 CF D3
Re: /. Yahoo delivers encrypted email
Bram Cohen writes: To be fair, Yahoo handles so much mail that the CPU power necessary to start SSL sessions for all of them gets pretty expensive. They'll probably start doing end-to-end encryption when the prices of that drop lower, Moore's law and all that. Of course, this assumes that secure mail will be a major hit amongst Yahoo users. Somehow, I doubt it.
Lots of random numbers
Rich Salz writes: I'm putting together a system that might need to generate thousands of RSA keypairs per day, using OpenSSL on a "handful" of Linux machines. What do folks think of the following: take one machine and dedicate it as an entropy source. After 'n' seconds turn the network card into promiscuous mode, scoop Why don't you stick a sound card (the noisier, the better) into each node, and dump /dev/dsp (LSB) input at max amplification into the randomness pool?
And so it begins
Only laptops, eh? Encrypted media are not mentioned, obviously. And clearly every modern OS (IPsec, ssh, even Winders' weak encryption) has "encryption capability". Spytool Netscape, who would have thought. Matt Crawford writes: This came third-hand, Sandia - DOE - me "Per the Office of Diplomatic Security, Department of State, Egypt, France and Russia have instituted the following: Laptop computers with encryption capability are considered "SPY TOOLS" and will be seized or denied entry into the country." We understand that Kazakhstan has a similar position. "With encryption capability" sounds a little vague, but that's par for the course. There's also an old note on this subject wrt. Russia at http://travel.state.gov/gps.html.
Re: A proposal for secure videoconferencing and video messaging over the Internet
James A. Donald writes: In real life situations where one wishes a conversation to be secure, are people most commonly authenticated by true name, or by face. We're mixing several unrelated items in one pot here. One thing is authentication, the other is securety. Authentication is when Alice can prove with a very high probability that the current transaction is being conducted with Bob, while in the past Alice or a party Alice trusts has already had dealings with Bob. This creates a machinery for maintaining a private (but publicable) list of identities which can build trust, which is clearly useful to distinguish defectors from the good guys. To best of my knowledge, authentication can be currently only conducted with one-time pads (too inconvenient for large groups of people) or public key cryptography (where in principle you could put meddling black boxes downstream of public key servers, and perform transparent key substitutions on the fly, or just spoof the IP address of the keyserver(s), or just hack the key server, or remotely compromise the local machine you're using). Above does not say anything about whether this transaction is in cypher or clear. Of course you would typically want to conduct the session via a block cypher channel, exchanging session keys either via one time pad or a public key protocol. Clearly, you can maintain a secure connection to an anonymous party. Authentication and securety only touch shoulders when you're trusting the public key server (and the local machine, and the network in between) to give you the right public keys which match advertised identity. It would be obviously a good idea to generate a small set of public/private key pair for every key server (putting them in the keyring of well known privacy packages as default), and authenticate each session with the key server. Another good idea is to conduct random consistency checks against a pair of keyservers each residing in different countries by yourself (of course this would make both the privacy packages and the packets travelling between you and the world more opaque), or someone who is widely trusted. Anyone knows whether this is being done? Think of every secure conversation you have had. Did the participants know your true name?
airport searches
SteveC writes: At the risk of going against the tide, I would rather be in a country where they did search some percentage of the incoming passport holders belongings than one where they didn't. They can search for things which can harm other people on the flight. This involves plastique, weapons, hot isotopes, nerve agents et al. I can hardly blow a hole in the hull with a DAT tape, can I? A combination of intelligence and criminalality does not happen that often, so criminals encrypting all their secret stuff is not of import to Great, then why screening the file systems at entry, then? Moreover, what precludes me from putting the encrypted stuff online on http://www.netdrive.com/ Co., crossing the boundary empty-handed, and then accessing the warez by ssh or SSL session, Echelon being none the wiser? So why this hard drive searching farce, then? me. What I do worry about is paying my taxes so people can walk in the country and claim benefit. I was unaware that U.S. (judging from the traceroute on your domain) grants financial support to steenkin furriners illegally entering their borders. I was under the impression that even (and perhaps especially) illegal immigrants had to work hard to keep their and their families' bellies full. As late FM2030 has so succintly put it, there are no illegal immigrants, only irrelevant boundaries. Not that I am in favour of the RiP bill, it is terrible but in order to have some kind of democracy you have to protect it from other forms of government, terrorism and criminals. The best thing for us to do is I have yet to see terrorists and criminals in an industrialized country threatening to overthrow its democratic structure. If anything, the resident goverments are the ones chipping away at it (see U.K., Echelon and Carnivore for a few recent examples). promote tools like pgp or hushmail, so those who really do need free speech can get it. PGP and hushmail do not grant free speech if you can track and filter all Internet traffic at IP level. (Moreover, as a good German, you should have nothing to hide, anyway. The thought police has been notified).
Re: UK searching traveler's disk drives for pornography (fwd)
David Honig writes: Again, if they have the 'right' (as border agents) then the technical difficulty translates into a battle of wills. A non-citizen would lose. A citizen *might* have a case but might also spend a few weeks in a Customs' hotel... Essentially, this means a storage medium not immediately readable by the customs (naked hard drives would certainly qualify) can be legally confiscated, at least in theory (somehow, I think they'll have to be pretty selective about it, as the screening alone will take too much time). I, also, would like to know how frequently this is being enforced in practice.
RE: NSA back doors in encryption products
From: "Minow, Martin" [EMAIL PROTECTED] Jim Choate writes: Bull, the hardware companies aren't any more trustworthy. I've been recommending the Dallas Semiconductor "iButton" http://www.ibutton.com for secure storage. The Java version also lets you implement your own on-chip algorithms so you can implement time- and usage-limited encryption. The chip has an on-board 1024 bit RSA engine and other useful features. Also, the Dallas folk put a lot of effort into making the iButton secure against a variety of physical attacks, including power analysis, probing, and physical dissassembly (all code is on battery backed-up SRAM). The iButton is FIPS-140 certified. On the other hand, there is no way for a customer without access to "national resources" to determine whether there is an undocumented way around their protection mechanisms (such as a hard-wired master password). About all you can say is that, if a back-door was discovered, the company would lose all credibilty. Is this good enough for all but the most paranoid? Martin Minow [EMAIL PROTECTED]
Re: GPS and cell phones
Bill Stewart writes: That doesn't mean that the author isn't mixing up two concepts - GPS vs cell phone location by the phone system's signalling. GPS burns too much power to be used in typical cellphones - I'd like to point out an emerging technology (based on digital pulse radio, implementable in SiGe processes) which could create a very low-power high-accuracy (cm range) realtime (multiple fixes/s) global or local positioning system, using the cellphone handsets themselves, and the base stations. http://www.aetherwire.com/Aether_Wire/aether.html
Re: GPS integrity
I presume the paper in question is http://www.cs.georgetown.edu/~denning/infosec/Grounding.txt Ian BROWN writes: Dorothy Denning wrote an interesting paper on authenticating location using GPS signals... I think it's reachable from her home page as well as the following citation: D. E. Denning and P. F. MacDoran, "Location-Based Authentication: Grounding Cyberspace for Better Security," Computer Fraud and Security, Feb. 1996 Ian :)
Re: New York teen-ager win $100,000 with encryptionresearch(3/14/2000)
Arnold G. Reinhold writes: I am not sure I understand the difference between "random" and "pseudorandom" as you are using it here. In any case, I expect more There is no difference from an attacker's point of view. He can't tell random from pseudorandom without extra knowledge. But he sure can tell a high-entropy sequence from a segment encoding, say, a vanilla transmembrane protein. Check out the genome of a real critter, a standard model nematode C. elegans http://elegans.swmed.edu/genome.shtml Doesn't look exactly random, does it? It would be interesting to analyse the genome from a cryptoanalyst's point of view. Any takers? sensitive cryptoanalytic tools for DNA can be developed if the need (and funding) arise. For example, has anyone done an n-tuple frequency analysis on natural DNA? Probes targeting n-tuples that are significantly less likely to occur in nature could be used to find human generated DNA strings without total sequencing. It might even Indeed. There are short subsequences which never or almost never occur in biology. This is the reason why you need to camouflage/steganograph as a biological sequence. Which, of course, dramatically reduces your payload, if you want to stay below individual/species variability threshold. The problem seems to be error rates. Here is what one DNA synthesis company has to say: http://www.alphadna.com/special.html#long Error-correction/redundant encoding. A mer (as in polymer) is a DNA base pair. There are four possibilities, so a mer encodes two bits. A 200-mer chain holds 400 bits. That's long enough to start thinking about packet technology. You could use ECC to deal with the base errors, or just assume you will have enough copies of each packet to do majority voting. Anyway, I expect Moore's law will apply here as it does in electronics. Price per base might be a good number to chart over Sure, designer enzymes and palmtop sequencers will be the vogue. time. I don't think that Moore's time constant is due to the peculiar nature of semiconductors, but rather it is results from the so-far-unlimited richness of the technology. DNA technology is just as rich in possibilities as semiconductors. I think Moore's 18 months DNA is just a particular instance of molecular nanotechnology. There is a very rich set of opportunities there, whether solvated/biologically inspired or dry/machine phase. Even a partial closure would make pretty useful things. is the limit as resources go to infinity of the time needed for humans to understand the limitations of the last innovation and come up with an approach to overcome them. One of the bottlenecks of molecular manufacturing is a decent fully interactive realtime molecular dynamics simulator, and another which has enought quantum clue do reliably predict chemistry. We do have the hardware power for that already (at least in form of clusters), it is really the question of writing the codes. You are right, of course, about density, but I'd be reluctant to rely on DNA's destructibility. On the contrary, I am told that PCR can reliably detect ten molecules and has a good chance of detecting a single molecule. If you are synthesizing 160 nmole, that is 10**20 molecules. You must completely destroy every one with high certainty. The whole point about DNA is that you can have few 100-1000 molecules, and yet still reliably amplify from these microscopic amounts. A drop of such DNA solution dropped into 98% HClO4 has a half life time of seconds at best.
New York teen-ager win $100,000 with encryption research (3/14/2000)
Of course it ain't actual encryption, only (high-payload)
steganography at best. Now, if you sneak a message into a living
critter (a pet ("the message is the medium"), or creating the ultimate
self-propagating chainletter, a pathogen), that would be an
interesting twist.
Interesting is that you can tag the message with a longish
pseudorandom base sequence, which allows you to fish for the fragment
(from digests) via a complementary sequence. Anyone not in posession
of that sequence would have to do a total sequencing.
Of course, using real steganography (camouflaging messages in DNA
(say, "(c) by God, Inc.") as genes or ballast as highly repetitive
sequences) is also an option.
David G. Koontz writes:
http://www.sjmercury.com/svtech/news/breaking/merc/docs/013955.htm
Re: New York teen-ager win $100,000 with encryption research(3/14/2000)
Arnold G. Reinhold writes: If you know the DNA sequences of alphabet letters, you can PCR probe for common words or word fragments like "the" or "ing" and avoid total sequencing. That's true. Luckily, there is no such test for random base sequences, though a pseudorandom sequence would certainly be very visible, but only if the genome has been totally sequenced (currently, an expensive and slow enterprise, despite Celera making large headways into it). Hence the need for steganography, which is further worsened by significant evolutionary conservation throughout the biological kingdom. The payload will be not be very high. A recent Genetic Engineering News says the price for synthetic DNA is dropping from $1 per base to about $0.50 per base. That works out to $0.25 per bit. That's about 8 orders of magnitude more expensive than PC disk storage. This only applies to short sequences. If you have to (PCR-) ligate your sequences from shorter segments as output by the synthesizer robot, the price will skyrocket. Hey, nobody said it's going to be cheap, nor fast ;) The good part is extremely dense storage (i dot can contain far more than microfilm), and potential for destruction on demand: via packaging in a container bisected with a breakable membrane, one part containing the DNA (precipitated, or as solution) and the other a strongly fragmenting chemical (DNAses probably too slow, something strongly oxidizing like concentrated perchloric acid should do).
Re: [FYI] ECHELON for combat of european national culture of bribery?
Of course U.S. companies are entirely innocent of that practise. Right. Sounds just like another lame excuse to me. Pedophiles, terrorists, hackers, now it's Evil Euros, snatching up contracts using bribes. Yawn. I'm surprised Janet Reno has this time nothing to say about this. Bill Stewart writes: Well, of course they do. Knowing who to bribe, what they're selling, and how much they're charging can be really valuable for "national security" interests - not only lets you bargain down your bribery payments, but occasionally lets you use blackmail to get stuff for free :-)
/. Mozilla Crypto Released for Windows, Linux
http://www.mozillazine.org/ Thursday March 9th, 2000 Mozilla Crypto Released for Windows, Linux! The first crypto-enabled builds of Mozilla have come online. Currently there are Windows and Linux builds available - a Mac version will be available soon. Enabled in these initial builds are SSL, the Security Advisor, and IMAPS. Signed mail and encrypted mail are not yet implemented. To try out the PSM (Personal Security Manager), first you need to grab a special version of M14. There are Talkback and no-Talkback versions available for Windows, and Talkback and no-Talkback versions available for Linux. After you have installed this build, run Mozilla and browse to the PSM page at iPlanet. You can get details on the release, as well as any special instructions you may need (and instructions for Linux if you are building the M14 build from scratch). Scroll down the page, and you will see buttons to install the PSM version for your system. Clicking the button will start up the XPI installation routine, and the PSM will be downloaded and installed. After installation, close Mozilla and reopen to use the PSM. You should be able to visit secure websites now, and view the Security Advisor (available from the Tasks menu). The source code for the PSM has not yet been released. We will let you know when it is.
please help FreeNet by becoming a node
(((I urge you to donate some of your computational/networking resources to the Freenet project, even if it's a single xDSL box. Details how to help see Latest News below.))) http://freenet.sourceforge.net/ "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'" -Mike Godwin FreeNet Latest News 18th Feb 2000 - Now is your chance to help Freenet is now in its testing phase, to facilitate this we need people who can run a Freenet node on their computers. To participate you will need a computer capable of running java 1.1 which has a permanent connection to the Internet, a fixed IP address, and is not behind a firewall. If you have access to such a beast and would like to help the Freenet project please click here for instructions on how to install a Freenet server. What is Freenet? The Freenet project aims to create an information publication system similar to the World Wide Web (but with several major advantages over it - see next section), where information can be inserted into the system and associated with a "key" (the key is normally some form of description of the data such as "freenet source code V1.0"). Later anyone else can retrieve the data using the appropriate key. In this respect it is a little like the World Wide Web which requires a "URL" to retrieve a particular document. To participate in this system users will simply need to run a piece of Java software on their computer, and optionally use a client to insert and remove information from the system. Anyone can write a client (or indeed a server) however the reference implementations will be written in Java. If you are interested in why someone might want to create a system like Freenet please take a look at the philosophy page. Why is Freenet interesting? Click on any of the following reasons for more information about each: Freenet does not have any form of centralised control or administration It will be virtually impossible to forcibly remove a piece of information from Freenet Both authors and readers of information stored on this system may remain anonymous if they wish Information will be distributed throughout the Freenet network in such a way that it is difficult to determine where information is being stored Anyone can publish information, they don't need to buy a domain name, or even a permanent Internet connection Availability of information will increase in proportion to the demand for that information Information will move from parts of the Internet where it is in low-demand to areas where demand is greater What is Freenet's current status? Much of the server is complete, and a command line client (which is developed in parallel and shares some code with the server) is also nearing completion. As of 8th Feb 2000 the following remains to be done: Some minor changes to message behaviour Fix hashing on Liberator (a contributed Perl implementation of a Freenet client) Implement tunneling (a mechanism which will dramatically improve Freenet response times) Speed up handshaking mechanism (which will also improve response times) Conduct a wide-scale multi-node beta-test (at present most tests have been conducted by running several nodes on the same computer). You should subscribe to the announcement mailing list to be informed of major releases (this is a low traffic mailing list). Can I help? Yes, definitely. If you have Java programming experience, or are familiar with cryptography then you will be particularly useful, but everyone is welcome. If you just want to find out more make sure you have read everything on this site - and then join the General mailing list. If you are keen to contribute, first take a look at the code in CVS, then you should join the Development mailing list and let us know what you think you can do. Why implement the first Freenet server in Java? Because: Java is the most cross-platform language currently available There are free Java implementations available such as Kaffe, we will ensure that Freenet is always compatible with these versions even if Sun attempt to make it more difficult for free Java implementations to keep up. Java has excellent network support Java is easier to debug than other languages such as C++, and this lets us get on with the business of implementing Freenet quickly and reliably!
Re: Napster - the quiet revolution
I haven't had the opportunity to try Napster yet (upgrade to glibc is way overdue). Everybody is raving about it, though, so it is probably very good. It seems however, that Napster suffers from a few design flaws: centralism (there is a central database, right?); it seems to produce cleartext traffic in certain patterns on a certain port (otherwise the protocol wouldn't have been reverse engineered so quickly and it would not be so easily detectable/blockable, as recently happening in certain university networks striving to conserve bandwidth). Is this correct? It would have been nice to to be able to run the global title index via a distributed database (no single point of failure, e.g. due to unfriendly legal action), which establishes connects through addresspace searches of nearby (in terms of number of hops and/or bandwidth) nodes, and sending something very much resembling a SSL connection as created by a vanilla secure browser session, both in in regards to used protocol and traffic pattern. Scanning for/blocking Napster traffic would so become much more difficult. An obvious problem is how to avoid collision with vanilla https (other than intercepting/redirecting https://aaa.bbb.ccc.ddd/napster/ traffic. Perhaps just using https on a different port would be a smarter idea, though usage of a nonstandard port is bound to draw closer scrutiny). A moderate connectivity (say, ~10), with each node acting as a relay, would allow each node to reach any other node within just a few hops over the virtual network. Caching the index of titles stored directly on these nodes could probably reduce the traffic quite a bit. A top-100 list and related-list (users who downloaded this title also downloaded the following titles, ranked by total downloads) would seem to greatly increase program functionality. It would seem to be necessary to limit the scope of visibility to direct neighbours only, to prevent malicious users from obtaining extensive lists of other Napster users' addresses. To increase obfuscation, introducing some traffic mixing should be contemplated, injecting pseudorandom garbage traffic between direct neighbours to foil statistical traffic attacks./paranoia The program should be capable of serving arbitrary types of digital content. The rationale is to sneak code into a widely used utility which would create an infrastructure for secure anonymous peer to peer communication, content sharing and digital payments (let's call it CryptNet) on top of insecure, increasingly monitored/filtered public networks. Comments? -- Eugene
Copy protection proposed for digital displays
http://www.eetimes.com/story/OEG2217S0039 Copy protection proposed for digital displays By David Lammers EE Times (02/17/00, 7:02 p.m. EST) PALM SPRINGS, Calif.-At the Intel Developer Forum here, Intel Corp. unveiled a copy protection scheme that will add a layer of encryption between the system and the digital display. The High-bandwidth Digital Copy Protection (HDCP) approach encrypts each pixel as it moves from a personal computer or set-top box to digital displays, such as digital flat panels and high-definition televisions. HDCP is an Intel-developed specification that will complement the work developed with the Digital Display Working Group (DDWG), said Mark Waring, an Intel technology initiatives manager who is the DDWG secretary. While the Digital Transmission Content Protection approach provides encryption for digital content as it moves over a 1394 interface, the HDCP is complementary. "HDCP encrypts the final link, from the device to the display, that has been the missing link" in the various copy protection schemes developed thus far, said Waring, who earlier worked as a display engineer at Sharp Corp. Intel will release a draft version of the license agreement by Monday, Feb. 21, at the Digital Content Protection web site. Also, individuals can go to the site to request a copy of the specification. At IDF's product demo pavilion, Silicon Image, Inc. (Sunnyvale, Calif.) demonstrated what it said was the first implementation of HDCP on its digital video interface (DVI) silicon. Transmitter and receiver silicon performed the HDCP authentication, encryption, and decryption functions, while supporting the DVI digital transmission rate of 5 G-bits/sec between the host and display. HDCP uses a 56-bit key, with individual keys distributed to the various vendors. A violated key could be tracked down and revoked over a satellite broadcast network, for example. Waring said he expects the major silicon vendors to have HDCP-compliant silicon ready by the July-August time frame.
Re: Blue Spike and Digital Watermarking with Giovanni
Well, the deformations must be smooth, so this just describes an attack against a certain type of watermarks. As I said, it is difficult to resiliently watermark a single image. Paul Crowley writes: As far as I know, all fielded watermarking schemes can be defeated with simple, invisible distortions of the image - see http://www.cl.cam.ac.uk/~fapp2/steganography/ for work done by Fabien Petitcolas and Ross Anderson. You don't even have to have more than one copy of the picture or know very much about the scheme in use.
Re: Debit card fraud in Canada
Arrianto Mukti Wibowo writes: About Mondex, probably you are right. No information is available about the internals of Mondex, and is kept secret, unlike CAFE which the specification The fact that Mondex keeps its VM specs secret does not forebode well for its security. Apparently, the VM designer also doesn't know squat about good VM design for C programs. Make from it whatever you will. was made open (it was a research project anyway). We can assume that Mondex does rely heavily on the tamper resistant device.
Re: Semantic Forests, from CWD (fwd)
Steven M. Bellovin writes: The problem, from the perspective of an intelligence agency, is figuring out what to listen to. Let's do some arithmetic. The product you cite requires at least a 133 Mhz Pentium; 200 Mhz preferred. How many such chips are needed? Well, according to a map on a wall near my Ahem. DSPs are very cheap (like $10) in large quantities, and are roughly comparable or better than a P200, especially for numerical purposes and if properly optimized. From a certain scale onward (I'm sure that Echelon exceeds the threshold easily) you can use ASICs, at least for the most computationally intensive algorithm stages, which makes it even cheaper (also in terms of footprint and power/airconditioning, which can be surprisingly expensive). Then of course you can hard-disk record a temporal window of every current conversation (which can be as deep as a whole call: compressed voice is low-bandwidth and hard drives are cheap), while sifting for certain keywords (with recent neuronal hardware techniques looking for keywords from a limited vocabulary or looking for specific speakers should be a piece of cake). If no hits occur, you discard the call. (Or process random calls if there is too much slack in the pool). If if the hits are over threshold, you keep the hitherto recorded call window plus intercept the whole call, then submit the job for (computationally expensive) high-fidelity crunching (which is probably not better than the best commercially available), which may give you -- how much? -- maybe 90-95% of recognition rate. If the AI (which can be something trained on a large real-world case knowledge base) deems the conversation to be hot, it passes on the transcript to a human. If you swamp their (limited, expensive, slow to expand) processing capabilities, you tweak the threshold until they just can cope. Of course there are conversations from certain people (crypto activists, politicians, criminals, C.E.Os etc.), which get filed automatically. I don't think the fact that most of Echelon is about industrial espionage is a big secret. Even if above isn't true (yet), it is imo sound practice to assume a worst case. office (see http://www.telegeography.com/Publications/cmap99.html), there are currently about 150 Gbps worth of fiber across the Atlantic. That's about 2.7 potential million phone channels. A lot of that is data, of course -- shall we say 75%? That still leaves us with ~675K simultaneous calls. That's an awful lot of CPU power, even by NSA's standards. Afaik the current telephone system can't work if more than (order of magnitude) ~10% of customers attempt to speak simultaneously. The world population might be 5-6 billion, but most of them don't have phones. The amount of international calls must be but a tiny fraction of total calls. And it gets worse -- within a year, the FLAG and TAT-14 cables will come online, adding at least 800 Gbps of capacity... As far as I know the transatlantic fibers are mostly idling. There aren't that many humans around who want to make international calls. I'd surmise the growth saturates sooner or later. The fraction of voice vs. data will be increasingly skewed towards data. Of course currently voice is typically much more important than data... Tentative conclusion: they need to listen to the signaling channels, so that they can focus their efforts. *Then* they can do the voice recognition and pattern-matching tricks. Afaik focusing has been intelligence's basic tenet since time immemorable. --Steve Bellovin
Re: 56 Bits?????
I presume if he fails to deliver the goods on time you'll henceforth consider 56 bit secure, in all eternity (=5-10 years)? Strange kind of reasoning. Marshall Clow writes: OK, Bob. You have claimed to be from Missouri. Show me. Here's an encrypted file, encrypted with a 56 bit key. Return to me the plaintext contents and I will pay you $175 plus $25 so you can claim a profit. Since you say it will take about 3 days, I'll give you 10. This offer expires on at 11:59 PST November 7, 1999. Well?
Re: grabbed video as a source of entropy
David Honig writes: Even if I had the same hardware, perhaps the tolerances on my ADCs are different from yours. And illumination levels will affect certain kinds of noise. Sure, but the entropy generation rate will be in any case higher than stuff coming from /dev/dsp The point: Measure it. Use Shannon's entropy formula, for instance. I'm not very well versed in such matters, and pressed for time in my day/night job. I wouldn't mind any pointers to sources extracting, say, LSB from grabbed frames. Distill (irreversibly compress, e.g., by xor'ing several words together) your data. Measure again; distill again until 1 bit/baud. Hash before use. I was looking for sources performing such steps. And I wouldn't want to crypto-hash lest the raw entropy gets debased by hidden algorithmic order. Any OTP tool should facilitate or automate these steps.
grabbed video as a source of entropy
I've recently aquired a video camera (bttv-based 3Com Bigpicture, can do 30 fps true color 640x480). I've noticed that under certain conditions images can become quite noisy. Does anyone has data on the amount and quality of the entropy produced? I wouldn't mind any pointers to sources extracting, say, LSB from grabbed frames.
Re: having source code for your CPU chip -- NOT
For the truly paranoid: it is perfectly possible to boostrap a working Forth environment *by hand*, whether by hand assembly and flashing the resulting image, or by porting eForth (or any Forths written in C) to an embedded target. You simply can't fit any Trojan in there: a minimal Forth OS can fit into just 2 k, typical environments take 12..16 kBytes. Of course you're abandoning any GNU/Unix compatibility, but the intrinsic rewards of a Forth environment can be considerable -- I don't know of any more productive system. Is there a crypto code library out there? Greg Rose writes: At 09:02 23/09/1999 -0400, Steven M. Bellovin wrote: By example, I could verify the machine code for IDEA, but not PGP and certainly not your favorite version of UNIX. Actually, while there are bugs and security holes, it's pretty certain that V6 Unix didn't have any crypto trapdoors ... and you can now own your very own source code license for early Unix including C compiler, complete with source for a PDP-11 emulator to run it on... this might come in handy one day as a stable, recreatable base. See http://minnie.cs.adfa.edu.au/PUPS , the PDP and Unix Preservation Society. [Of course, what guarantees does one have about the provenance of the code? --Perry]
Re: Power analysis of AES candidates
Eli Brandt writes: If so, doubling the cap size halves the cutoff frequency (right?), halving the leaked power. Integrating runs gives signal voltage linear in n and noise voltage sqrt(n); voltage ratio is sqrt; power ratio is linear. So leaked-signal power is Theta( (attacker's number of runs) / (capacitor size) ). No asymptotic edge either way; attacker wins against bounded cap size. /handwave I don't quite understand your handwave analysis: if we use supercapacitors we can power the embedded unit for hours straight. A typical encryption round completes in milliseconds at best, I don't see how microsecond spike demands can ever leak out regardless whether we measure till the Big Crunch or the day after tomorrow. Apart from such crude-but-effective countermeasures we haven't even begun tackling lunatic fringe stuff like reversible computation.
Re: Power analysis of AES candidates
John Gilmore writes: What are you guys talking about? Differential power analysis doesn't require any physical attack, nor does it deal with voltage variations. (You are probably thinking of Shamir's fault-injection You can't do differential power analysis if you supply power photonically to an encapsulated unit. Power dissipated gets averaged out over time so you can't just monitor the temperature. attacks.) Differential power analysis measures the current consumption of the part as it operates, completely outside the device. 1) A self contained, sealed unit is immune to this 2) What prevents us from measuring the power fill out lacunes a la resistance heating? The unit would then show constant dissipation regardless of which computation it performs. It uses statistical techniques to confirm or reject hypotheses about the key values being operated on in the final rounds of encryption algorithms. Paul Kocher's team has developed some countermeasures, see the end of the technical discussion linked from: http://www.cryptography.com/dpa/index.html John
crypto file system for Linux: which?
Hi, recently we had a break-in where very valuable intellectual property was stolen along with (negligeable) hardware. To prevent this in future I'd like to establish a (physically secured) Linux SMB server running a cryptographic file system. I've taken a quick look, and there seem to exist essentially two packages: one which encrypts at the partition, and the file system level. (There seems to be also a system which encrypts/decrypts ~/ at each login, but I doubt that's compatible with Windows). Which cryptographic file system would you recommend? Also, I'm unsure how authentication is accomplished. Are passwords/phrases required at each access/session? Do passwords go encrypted over the network? Also, in future I'd like to use soft RAID (at least mirroring) and XFS. It would be nice to have a crypto file system which can be mounted over that. TIA, Eugene
Re: depleting the random number generator -- repeated state
David Honig writes: One of the many uses of nitric acid. Ie, take random samples I thought this is mostly done by removing the bulk of the package polymer by grinding, and then subjecting the rest of it to a plasma etch. I haven't put a processed wafer into nitric acid yet, but I could imagine it does horrible things to small structures. apart and look at them. There are commercial places that will do the lab work for you. Since this involved manual work and heavy apparatus (UHV plasma etch chamber, EM, etc.) as well as know-how (finding a structure and guessing what it does) it won't be exactly cheap.
RE: US Urges Ban of Internet Crypto
Lucky Green writes: [Before a reader replies with an argument based on a claim that strong crypto is in the process of becoming ubiquitous, please take a look at your phone. Does it perform 3DES encryption? Do the phones of the majority of Phone? Why do I need a stupid phone if there's http://www.speakfreely.org/ It's cheaper, too. people you call perform 3DES encryption? Alternatively, you could take a look your email client. Does it support strong crypto? Great! Now what Sure. percentage of emails you send *and receive* each day use strong crypto? If your answer is 95% or higher, you might have a point, if it wasn't for the fact that the Minister hasn't been shown the video tape just yet]. Should strong crypto be outlawed, my mail traffic will consist mostly of Pretty Goofy Pictures, and snowy video feed from the webcam. Most of them will be really just pretty goofy pictures, with a wee bit of nondeterministic noise added. Besides, you can control buddy-to-buddy software distribution exactly as well as prevent people from swapping mp3 warez among friends. What next, outlaw compilers? Outlaw hardware? Outlaw people? Don't think so.
US Urges Ban of Internet Crypto
John Young writes: Nations do not control distribution of intangible items. While I recognize that this issue is controversial, unless we address this situation, use of the Internet to distribute encryption products will render Wassenaar's controls immaterial." I just love this sentence. So, let's create unenforcible legislation, and then try to pave over all the world in the attempt to make reality comply. Name's Janet Reno, huh? What's worse, the gullible Germans will probably heel.
A Massively Parallel Cryptosystem Based on Cellular Automata
What is your oppinion on the security of this system. Any obvious flaws? http://www.santafe.edu/~hag/ca11/ca11.html A Massively Parallel Cryptosystem Based on Cellular Automata Howard Gutowitz ESPCI; Laboratoire d'Electronique 10 rue Vauquelin; 75005 Paris, France [EMAIL PROTECTED] The DES is an example of an iterated cryptosystem, a cryptosystem in which a function is applied many times to a message in order to encrypt it. From the physicists point of view, an iterated cryptosystem is an example of a dynamical system, a system whose state evolves over time. Dynamical systems theory encompasses the study of a wide range of phenomena, chaos being the most well known. Some of these phenomena have correlates in cryptography, and can be used as the basis of cryptographic schemes. A certain type of dynamical system, called cellular automata, are particularly well suited for cryptographic application. A cellular automaton is a discrete dynamical system. Space, time, and the states of the system are discrete. Each point in a regular spatial lattice, called a cell, can have any one of a finite number of states. The states of the cells in the lattice are updated according to a local rule. That is, the state of a cell at a given time depends only on its own state one time step previously, and the states of its nearby neighbors at the previous time step. All cells on the lattice are updated synchronously. Thus the state of the entire lattice advances in discrete time steps. Since the update rule is simple, local, and discrete, it can be executed in easily-constructed massively-parallel hardware at extraordinary speeds, without round-off errors. I have developed a cryptosystem, called CA-1.1, which illustrates some of the principles of encryption with cellular automata. In CA-1.1, a message is encoed as a state of the system, and various cellular automaton rules applied to it to produce a new state which is the ciphertext. To decrypt, the same cellular automaton rules are applied in reverse order. The cellular automata employed are derived from a secret key. CA-1.1 uses both reversive and irreversible cellular automaton rules. Under a reversible rule, each state of the lattice comes from a unique predecessor state, while under an irreversible rule, each state can have many predecessor states. During encryption, irreversible rules are iterated backwards in time. To go backward from a given state, one of the possible predecessor states is selected at random. This process can be repeated many times. Backward iteration thus serves to mix random information with the message information. CA-1.1 uses a particular kind of partially linear irreversible rule which is such that a random predecessor state for any given state can be rapidly built. Reversible rules are also used for some stages of encryption. The reversible rules (simple parallel permutations on sub-blocks of the state) are fully non-linear, while the irreversible rules are partially linear. The irreversible rules are derived entirely from information in the key, while the reversible rules depend both on key information and on the random information inserted during the stages of encryption with irreversible rules. CA-1.1 features an authentication mechanism which renders chosen-ciphertext attack difficult. This authentication mechanism ensures that only ciphertext produced by the system loaded with a given key is decrypted using the same key. CA-1.1 is built around a block-link structure. That is, the processing of the message block is partially segregated from the processing of the stream of random information inserted during encryption. This random information serves to link stages of encryption together. It can also be used to chain together the encryption of a stream of blocks. The information in the link is generated within the encryption apparatus. It is not accesible even to legitimate users of the system, hence it is not available for chosen-plaintext attacks. A detailed explanation of how CA-1.1 works can be found in references [1,2]. Further details, as well as U.S. licensing information can be obtained from the author at the above address. References: [1] H. Gutowitz, "Method and Apparatus for Encryption, Decryption, and Authentication using Dynamical Systems", U.S. patent application (100 pg. 1992) [2] H. Gutowitz, "Cryptography with Dynamical Systems" to appear in: "Cellular Automata and Cooperative Phenomena", Eds: E. Goles and N. Boccara, K. Reidel Press (38 pg. 1993)
Re: depleting the random number generator
bram writes: Most of the fancy reseedable PRNG schemes people have come up with are based on using secure hashes. They are sure validated, but are they the best we can do? MD5, the nonplusultra, really?
Re: depleting the random number generator
bram writes: I'm not sure if anybody's yarrowified /dev/random yet - I think someone from coderpunks was working on it. Does anybody know how cellular automata perform re cryptographically solid random number generators? They can crank out a lot of integers with a minimum investment in instructions executed.
how secure is digital pulse radio?
I assume you are aware of the forthcoming digital pulse radio technology http://www.time-domain.com/technology.html It is not exactly crypto, but uses ultra-wideband low-power (they claim 10 miles with 500 uW) emissions and pseudo random codes to shift the spike train encoding the information stream. It looks very like white noise. What is your estimate how difficult it would be to screen for such communication channels, and how rapidly could one crack them (assuming no further encryption of the traffic)? -- Eugene Leitl
Python RSA
Got this from Mordy Ovits [EMAIL PROTECTED] Is the following of more than trivial value? It does seem to use L integers... #!/usr/bin/python from sys import*;from string import*;a=argv;[s,p,q]=filter(lambda x:x[:1]!= '-',a);d='-d'in a;e,n=atol(p,16),atol(q,16);l=(len(q)+1)/2;o,inb=l-d,l-1+d while s:s=stdin.read(inb);s and map(stdout.write,map(lambda i,b=pow(reduce( lambda x,y:(x8L)+y,map(ord,s)),e,n):chr(b8*i255),range(o-1,-1,-1))) Invoked as: echo 'Top secret message.' | rsa.py 10001 1967cb529 ciphertext cat ciphertext | rsa.py -d ac363601 1967cb529 * rsa.py (4 lines): Performs RSA public key encryption/decryption. It requires two arguments, and can accept a single option: '-d' for decryption (the default action is encryption). The first argument must be the required exponent, expressed in hexadecimal, and the second is the modulus, also in hex. You still have to choose the correct exponent, whether the '-d' option is present or not; '-d' simply changes the number of bytes read at a single time. As an example: Let us assume the modulus is 6819722537, the encryption exponent is 65537, and the decryption exponent is 2889233921. Then, after converting the numbers to hex, we can encrypt and then decrypt by the following commands:
Re: 56 Bits?????
Wiping is not enough in some cases. With magnetical proximal probe microscopy one can read residual magnetisation even in low-level formatted disks. First wiping with ones and zeroes and then overwriting several times with (pseudo)random sequences offers better protection. The optimal solution would seem to use cryptographical files systems, and enough RAM not to use a swap file/partition. Since modern RAM supposedly almost operates in the nonvolatile ferroelectric regime (the next generation of RAM), true paranoids would probably want ot apply above wiping technique to RAM at each shutdown. Arnold G. Reinhold writes: On the specific complaint that seems to have started this thread, the lack of a wipe option in the file encryption, I would just like to point out that wiping the original file when you encrypt it is nowhere near enough. Many popular applications, such as MS Word, create temp files all over the place. A better approach is to wipe all disk free space regularly. This can be easily automated in the MacOS using shareware utilities and Applescript.
