The W3C has released XML Encryption Syntax and Processing
http://xmlhack.com/read.php?item=1570 Encryption, Decryption reach Candidate Recommendation 20:01, 6 Mar 2002 UTC | Simon St.Laurent The W3C has released XML Encryption Syntax and Processing and Decryption Transform for XML Signature as Candidate Recommendations, as well as a new XML Encryption Requirements Note. None of these documents appear to have changed substantially, and expectations for further progress are high: The exit criteria for this phase is at least two interoperable implementations over every feature, one implementation of all features, and one report of satisfaction in an application context (e.g., SOAP, SAML, etc.) Note, this specification already has significant implementation experience which will soon be reflected in its Interoperability Report. We expect to meet all requirements of that report within the two month Candidate Recommendation period (closing April 25). Remaining issues for XML Encryption include performance and interaction with validation. XML Decryption performance is also important, as is the development of interoperable implementations. The Requirements Note, after minor changes... serves to document the agreed upon set of requirements the specification will address. Related stories: XML Encryption moves to Last Call New Encryption and Decryption drafts XML Encryption Activity started by the W3C - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Interesting new cipher patent
A question: assuming, you have a class of random number generators with lots of internal state. (Lots: like 10^6 bits). Let's say the evolution through state space of that generator is provably reversible (or nearly reversible), and that the Hamiltonian of the system is stochastic (system evolution is a randomwalk in state space). The result is a pseudorandom number generator with a ridiculously long periode, and good randomness of output, obviously. A simple cypher based on it would exchange the pseudorandom generator state (the key) through a secure channel, similiarly to a one time pad. Can someone point me towards papers describing construction of above generators? I'm thinking about reversible cellular automata (is Gutowitz the only guy who did CA crypto?) or automata networks with changing connection geometry (i.e. the connection is also encoded in the state and changes with each iteration) with the number of total iterations estimated from lightcone considerations. Point of this: * algorithmic construction of PRNGs with provable properties * lots of internal state, hence bit leakage even for a lot of messages buys attacker little * scalable (add more state as hardware improves) * directly mappable to hardware, very good parallelism Any pointers? On Wed, 27 Feb 2002, Khoder bin Hakkin wrote: Cipher mixer with random number generator Abstract An encryption device has a random number generator whose output is combined by exclusive-or with plaintext input which has been encrypted by a first block cipher. The combined exclusive-or output is encrypted with a second block cipher mechanism which produces a second enciphered output. The output of the random number generator is also encrypted by a third block cipher mechanism which produces a third enciphered output. The first and second block cipher mechanisms differ from each other. United States Patent 6,351,539 February 26, 2002 -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBMTO: N48 04'14.8'' E11 36'41.2'' http://www.leitl.org 57F9CFD3: ED90 0433 EB74 E4A9 537F CFF5 86E7 629B 57F9 CFD3 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd)
-- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBMTO: N48 04'14.8'' E11 36'41.2'' http://www.leitl.org 57F9CFD3: ED90 0433 EB74 E4A9 537F CFF5 86E7 629B 57F9 CFD3 -- Forwarded message -- Date: Tue, 5 Feb 2002 11:10:49 +0100 (CET) From: Robert Harley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Cringely Gives KnowNow Some Unbelievable Free Press... Eugene Leitl wrote: If you want to see EC used you need to describe a specific algorithm which has the following three properties: (1) widely agreed to be unencumbered, [...] No problem. Use a random secure curve over a binary field with a polynomial basis (or over a random prime field). Do it in software using standard text-book algorithms. Use a protocol that is in the clear such as plain Diffie-Hellman key exchange. That is what we do e.g., sharing a symmetric key for encryption/decryption using Rijndael. The only patent that is relevant for us is our own one (pending) on a fast method for generating random secure curves. EL: (2) significantly better than RSA (this generally means faster) This seems a little bit simplistic... Whatever way you cut it, RSA will beat ECC on public key ops (encryption, signature verification...) whereas ECC will beat RSA on private key ones (decryption, signing...) The speed argument can be compelling or not depending on what you want to do. On standard PCs doing occasional crypto operations, both ECC and RSA are plenty fast. The speed issue is on small devices like hand-helds or mobile phones, and on heavily loaded servers. For instance with signatures, people might want to sign on slow client devices which take 1 second with ECC but many seconds with RSA; and then verify the signatures on servers fast enough for thousands per second. It is easier to upgrade your servers if needed than to upgrade the users who aren't using your service because it is too slow. One hears of crazy stuff like network setups which time out when you try to do DH with 1024-bit RSA on some slow hand-helds, but work fine when doing equivalent DH with 163-bit ECC. In our work with Mailwatcher, servers talk to each other doing equal numbers of encryptions and decryptions for many users. Even according to RSA Security's own numbers, ECC wins easily in this case! EL: (3) has seen a significant amount of analysis so that we can have some reasonable confidence it's secure. The FUD campaign on this point has been too successful. Serious study of factoring and related stuff dates from the early 19th century with people like Gauss. Serious study of elliptic curves and related stuff dates from... umm... the early 19th century with people like... umm... Gauss. Modern study of discrete-log based cryptosystems dates from the invention of public-key systems in 1976. Modern study of factoring based cryptosystems dates from the invention of RSA in 1977. ECC is in the former family, although it dates from 1985. The relative paucity of results on ECC is a good thing. There has been no progress on breaking ECC with properly chosen curves. On the contrary there is a negative result that discrete logs using generic group operations do take exponential time. The problem in this area is with some people sailing too close to the wind and picking curves with tonnes of useful properties to speed up their cryptosystems (and, unfortunately, attacks on some of them). For RSA, it was claimed in 1977 that factoring a certain 426-bit number would take quadrillions of years. This in spite of the fact that a sub-exponential algorithm for factoring was already known. Knowledge was pretty fuzzy about its runtime and practicality. Some widely-deployed big-budget systems were designed using RSA as low as 320 bits. That's easily broken. During the 1980's, the research community perfected the early sub-exponential methods and the 426-bit number was broken in 1994 by a team led by Arjen Lenstra (I was in it...) There was also a new faster algorithm, the NFS. Knowledge was pretty fuzzy about its runtime and practicality. During the 1990's, the research community perfected it. Then recently 512 bits was broken. The current record, as of a few days ago, is 524 bits attained by Jens Franke et al. when completing the factorization of 2^953+1 (there were three other factors previously found by Paul Zimmerman, Torbjorn Granlund and myself). It would be feasible to break 600 bits or more with some effort. Things have been quiet on the new algorithms front for a few years. But at Crypto last August, Dan Bernstein announced a new design for a machine dedicated to NFS using asymptotically fast algorithms and optimising memory, CPU power and amount of parallelism to minimize asymptotic cost. His conclusion, recently detailed in a paper, should be a bombshell, but apparently everyone is asleep: DB: This reduction of total cost [...] means that a [approx 3d-digit
Re: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd)
-- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBMTO: N48 04'14.8'' E11 36'41.2'' http://www.leitl.org 57F9CFD3: ED90 0433 EB74 E4A9 537F CFF5 86E7 629B 57F9 CFD3 -- Forwarded message -- Date: Tue, 5 Feb 2002 11:10:49 +0100 (CET) From: Robert Harley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Cringely Gives KnowNow Some Unbelievable Free Press... Eugene Leitl wrote: If you want to see EC used you need to describe a specific algorithm which has the following three properties: (1) widely agreed to be unencumbered, [...] No problem. Use a random secure curve over a binary field with a polynomial basis (or over a random prime field). Do it in software using standard text-book algorithms. Use a protocol that is in the clear such as plain Diffie-Hellman key exchange. That is what we do e.g., sharing a symmetric key for encryption/decryption using Rijndael. The only patent that is relevant for us is our own one (pending) on a fast method for generating random secure curves. EL: (2) significantly better than RSA (this generally means faster) This seems a little bit simplistic... Whatever way you cut it, RSA will beat ECC on public key ops (encryption, signature verification...) whereas ECC will beat RSA on private key ones (decryption, signing...) The speed argument can be compelling or not depending on what you want to do. On standard PCs doing occasional crypto operations, both ECC and RSA are plenty fast. The speed issue is on small devices like hand-helds or mobile phones, and on heavily loaded servers. For instance with signatures, people might want to sign on slow client devices which take 1 second with ECC but many seconds with RSA; and then verify the signatures on servers fast enough for thousands per second. It is easier to upgrade your servers if needed than to upgrade the users who aren't using your service because it is too slow. One hears of crazy stuff like network setups which time out when you try to do DH with 1024-bit RSA on some slow hand-helds, but work fine when doing equivalent DH with 163-bit ECC. In our work with Mailwatcher, servers talk to each other doing equal numbers of encryptions and decryptions for many users. Even according to RSA Security's own numbers, ECC wins easily in this case! EL: (3) has seen a significant amount of analysis so that we can have some reasonable confidence it's secure. The FUD campaign on this point has been too successful. Serious study of factoring and related stuff dates from the early 19th century with people like Gauss. Serious study of elliptic curves and related stuff dates from... umm... the early 19th century with people like... umm... Gauss. Modern study of discrete-log based cryptosystems dates from the invention of public-key systems in 1976. Modern study of factoring based cryptosystems dates from the invention of RSA in 1977. ECC is in the former family, although it dates from 1985. The relative paucity of results on ECC is a good thing. There has been no progress on breaking ECC with properly chosen curves. On the contrary there is a negative result that discrete logs using generic group operations do take exponential time. The problem in this area is with some people sailing too close to the wind and picking curves with tonnes of useful properties to speed up their cryptosystems (and, unfortunately, attacks on some of them). For RSA, it was claimed in 1977 that factoring a certain 426-bit number would take quadrillions of years. This in spite of the fact that a sub-exponential algorithm for factoring was already known. Knowledge was pretty fuzzy about its runtime and practicality. Some widely-deployed big-budget systems were designed using RSA as low as 320 bits. That's easily broken. During the 1980's, the research community perfected the early sub-exponential methods and the 426-bit number was broken in 1994 by a team led by Arjen Lenstra (I was in it...) There was also a new faster algorithm, the NFS. Knowledge was pretty fuzzy about its runtime and practicality. During the 1990's, the research community perfected it. Then recently 512 bits was broken. The current record, as of a few days ago, is 524 bits attained by Jens Franke et al. when completing the factorization of 2^953+1 (there were three other factors previously found by Paul Zimmerman, Torbjorn Granlund and myself). It would be feasible to break 600 bits or more with some effort. Things have been quiet on the new algorithms front for a few years. But at Crypto last August, Dan Bernstein announced a new design for a machine dedicated to NFS using asymptotically fast algorithms and optimising memory, CPU power and amount of parallelism to minimize asymptotic cost. His conclusion, recently detailed in a paper, should be a bombshell, but apparently everyone is asleep: DB: This reduction of total cost [...] means that a [approx 3d-digit
Re: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd)
-- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBMTO: N48 04'14.8'' E11 36'41.2'' http://www.leitl.org 57F9CFD3: ED90 0433 EB74 E4A9 537F CFF5 86E7 629B 57F9 CFD3 -- Forwarded message -- Date: Sun, 27 Jan 2002 21:10:09 +0100 (CET) From: Robert Harley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Cringely Gives KnowNow Some Unbelievable Free Press... Adam Beberg wrote: I'm preaty sure the reason we're all using RSA _now_ is the same reason we were using DH a couple years ago - the patents are all expired. ECC has a bunch of patents still living, and the word among the crypto crowd I know is still avoid like the plague. I usually have no particular desire to respond to Beberg's negativism, but I suppose that I should do so this time. The basic patent on RSA has expired (RSA was widely used before that too - you might have noticed). An equivalent basic patent on ECC never existed. There are various other patents to be aware of, and this is the case whether you're working with ECC or RSA, or making paper clips. You can avoid them if you know what you're doing, and walk right into them if you don't. For instance RSA Security holds a patent on fast exponentiation, which can be used for RSA or ECC (but not paper clips, AFAIK). Various protocols, whether used over RSA or ECC, are patented. The Diffie-Hellman patent expired (before that people often used El Gamal instead). Other protocols such as Nyberg-Rueppel or Menezes-Qu-Vanstone are still covered. Specific to ECC: There are Crandall's patents on using certain primes of a special form. So don't use them. I recommend using random primes anyway (patent or no patent) or else binary fields. The NSA has patented a particular exponentiation algorithm for Koblitz curves. So don't use it. However they will probably place it in the public domain like their DSA patent. I recommend not using Koblitz curves anyway (patent or no patent). Certicom has some patents on fast arithmetic (whether for ECC or other stuff) but they cover circuit designs for finite-field multipliers, with low transistor count and/or using normal bases. They are irrelevant for software and irrelevant for polynomial bases which I recommend anyway. For hardware they can be avoided e.g., Siemens has ECC hardware which doesn't infringe. I think the only patents of particular note for ECC are Certicom and H.P.'s ones on point-compression. For DH, you just use the x-coordinate so you don't need points, never mind point-compression. For signatures such as ECDSA, you need points so just use them uncompressed. It makes very little difference. The issue is if you want to verify signatures produced by somebody else who used point-compression. I would hazard a guess that in such a situation it would be OK to check the x-coordinate and ignore the one bit of extra information in y (but I would have to study the details to be sure). Patents are a pain in the ass but, in this instance at least, they hardly constitute a minefield. We wont be touching ECC for a very long time. Fine! Bye, Rob. .-.[EMAIL PROTECTED].-. / \ .-. Software Development .-. / \ / \ / \ .-. _ .-. / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / `-' `-' \ / \ / \ \ / `-' ArgoTech `-' \ / `-'http://argote.ch/ `-' http://xent.com/mailman/listinfo/fork - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [linux-elitists] Re: Looking back ten years: Another Cypherpunksfailure (fwd)
anybody used that combo? -- Forwarded message -- Date: Sun, 27 Jan 2002 12:45:21 -0800 From: Don Marti [EMAIL PROTECTED] To: Linux Elitists List [EMAIL PROTECTED] Subject: Re: [linux-elitists] Re: Looking back ten years: Another Cypherpunks failure (fwd) begin Eugene Leitl quotation of Sun, Jan 27, 2002 at 09:22:57PM +0100: Why is there no secure telephony package coming with debian? How about gnome-o-phone over rtptunnel over ssh? I know gphone is packaged; don't know if rtptunnel is. If that's acceptably fast it reduces the key management problem to the previously solved (kind of) problem of ssh key management. If you want someone to be able to call you, just add his or her key to a special authorized_keys for a dial-in account. http://gphone.sourceforge.net/ -- Don Marti http://zgp.org/~dmarti Join the Distributed Unisys Google Experiment. [EMAIL PROTECTED] a href=http://burnallgifs.org/;Unisys/a KG6INA everywhere. ___ linux-elitists http://zgp.org/mailman/listinfo/linux-elitists - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
On Tue, 15 Jan 2002, D. A. Honig wrote: [Moderator's note: Except that's precisely the point: Modulo MIM attacks is like saying we're all immortal, modulo death. The question isn't some sort of mystification of identity -- it is being able to know that you're talking to the same Dear Abby your friends have talked to and that you talked to last week. Now that MIM attacks have been automated they don't even need sophistication to conduct. --Perry] It requires sophistication to do MIM on a large scale. Active realtime manipulation of traffic on the global scale is currently beyond the scope of TLAs (but they're probably rather good at passive listening by now). Especially, if the initial key exchange is cached, as there's temporal constraints on the window of vulnerability. It's not a minor point, and hence needs repeating. Plus, web of trust mechanisms can always be added later. Rolling out crypto on a massive scale (MUA-MTA, MTA-MTA, IM, P2P) is where's it's at. [Moderator's note: This is simply wrong in a commerce situation. I cannot emphasize that strongly enough. There are tools to assist in doing MIM attacks out there, and doing it globally isn't needed -- doing it in front of one of amazon.com's ssl servers is what you need to do, and there are few large installations out there without even a single vulnerable machine. You need authentication to trust an encrypted connection, and if you use a connection in commerce you need to trust it. Even if your one transaction is low value a large site puts through huge numbers of those low value transactions. --Perry] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Hackers Targeting Home Computers
On Fri, 4 Jan 2002, Hack Hawk wrote: It surprises me that providers like Earthlink GTE (I have one DSL on each) aren't taking measures to filter out virus traffic from infected systems. It seems a simple enough task to me. A *very* bad idea. First, the traffic doesn't bother me, personally. In fact, it creates a need to use more diverse, and more secure systems. Secondly, building realtime pattern recognition and traffic blocking capability is something certainly to be abused in future. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: key logger (FBI or otherwise)
On Tue, 27 Nov 2001, P.J. Ponder wrote: It seems to me that something like Integrity Master from Stiller Research (http://www.stiller.com) would detect the installation of the FBI (or other) logger. This type of anti-virus software notes changes to files, Of course you use OS functions to access the file system. A virus at OS level can cloak itself perfectly. You'd have to reboot from a certified clean source (say, a write-protected Linux floppy) and then mount and inspect the file system for unauthorized changes. and alerts the user if a file changes (or is added to the system), as opposed to signature-based anti-virus software that looks for a virus's signature. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: FBI-virus software cracks encryption wall
On Tue, 27 Nov 2001, Gilles Gravier wrote: Jetico ( http://www.jetico.com/ ) has a hard disk encryption software called BestCrypt, which can actually intercept the keystrokes at BIOS level, get the correct keys and re-maps them to random for upper Linux doesn't have a BIOS level so this approach wouldn't work. In fact Linux can be used instead of a BIOS (LinuxBIOS), in case you don't trust the BIOS (some viruses can write themselves into BIOS flash). layers... like keystroke loggers. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[linux-elitists] W3C last call on XML Encryption... (fwd)
-- Forwarded message -- Date: Thu, 25 Oct 2001 11:32:53 -0400 From: Dan York [EMAIL PROTECTED] To: linux-elitists [EMAIL PROTECTED] Subject: [linux-elitists] W3C last call on XML Encryption... FYI, the W3C has issued a last call for comments on several proposals related to XML encryption. More info at: http://www.w3.org/Encryption/2001/ Since I know a good number of folks on this list are interested in encryption and Internet communication, I thought I would pass it along as it involves encrypting XML, much of which will no doubt be passed across the Internet. The specific documents are at: XML Encryption Requirements http://www.w3.org/TR/xml-encryption-req This document lists the design principles, scope, and requirements for the XML Encryption. It includes requirements as they relate to the encryption syntax, data model, format, cryptographic processing, and external requirements and coordination. XML Encryption Syntax and Processing http://www.w3.org/TR/xmlenc-core/ This document specifies a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption element which contains or references the cipher data. Decryption Transform for XML Signature http://www.w3.org/TR/xmlenc-decrypt This document specifies the decryption transform, which enables XML Signatures verification even if both signature and encryption operations are performed on an XML document. Dan -- Dan York, Director of Training, Network Server Solutions Group Mitel Networks Corporation [EMAIL PROTECTED] Ph: +1-613-751-4401 Cell: +1-613-263-4312 Fax: +1-613-564-7739 150 Metcalfe Street, Suite 1500, Ottawa,ON K2P 1P1 Canada http://www.e-smith.com/ http://www.mitel.com/sme/ ___ linux-elitists http://zgp.org/mailman/listinfo/linux-elitists - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
secure IRC/messaging successor
Gale http://www.gale.org/ seems a well thought out infrastructure. Is the consensus this is it, or have I missed any alternatives? TIA, -- Eugen* Leitl a href=http://www.lrz.de/~ui22204/;leitl/a __ ICBMTO : N48 10'07'' E011 33'53'' http://www.lrz.de/~ui22204 57F9CFD3: ED90 0433 EB74 E4A9 537F CFF5 86E7 629B 57F9 CFD3 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Welcome to Vegas, You're Under Arrest (fwd)
-- Eugen* Leitl a href=http://www.lrz.de/~ui22204/;leitl/a __ ICBMTO : N48 10'07'' E011 33'53'' http://www.lrz.de/~ui22204 57F9CFD3: ED90 0433 EB74 E4A9 537F CFF5 86E7 629B 57F9 CFD3 -- Forwarded message -- Date: Wed, 18 Jul 2001 11:50:30 -0400 From: Matthew Gaylor [EMAIL PROTECTED] To: Matthew Gaylor [EMAIL PROTECTED] Subject: Welcome to Vegas, You're Under Arrest Welcome to Vegas, You're Under Arrest According to Midnight Express, hashish trafficking can earn you a few decades in a Turkish prison. And according to U.S. law, making software that decrypts Adobe's eBook format can get you up to five years in an American one. Maybe Dmitry Sklyarov, who was busted by the FBI for trafficking in software to circumvent copyrighted materials, can recoup some of his legal costs by selling the movie rights. Sklyarov was arrested in Las Vegas a day after giving a speech on digital book security at the hacker conference Def Con, but we think that's just a coincidence. Free speech is still legal in America, but his company's software defies the Digital Millennium Copyright Act. The Moscow-based company ElcomSoft makes the Advanced eBook Processor, a program that cracks the encryption on Adobe eBooks and converts them to the Adobe PDF format. This is all squeaky clean in Russia, but since some of the software made it to the U.S., Adobe wasn't amused. The New York Times and Wired detailed the recent back-and-forth between Adobe and Elcom, including Adobe's successful attempts to get Elcom booted from several ISPs - and get the feds involved.. ZDNet's Robert Lemos appeared to be the only writer to credit Planetebook.com with breaking the story. Planet eBook also posted the affidavit (ominously referring to United States of America v. Dmitry Sklyarov), court documents indicating that Adobe itself bought and tested a copy of the forbidden software, and other tidbits for the legal-minded. A few outlets noted that Sklyarov is being held without bail; some pointed to the rarity of criminal charges for copyright infringement. I thought maybe I would be arrested because I am the owner and the president of the company, but not Dmitry, said Elcom's head honcho, who also attended Def Con. But I think this is the easiest way to send a message that it is a single Russian hacker at work, but really it is the entire encryption that is flawed. If Adobe or the FBI intended to plant hysteria about a Russian hacker, it didn't work too well. Journalists usually referred to Sklyarov as an expert, cryptographer or programmer. True, one Wired News headline called him a hacker, but from those folks, that's a compliment. - Jen Muehlbauer Index of ElcomSoft, Dmitry Sklyarov, Adobe, US Government and DMCA-related articles from around the Web http://www.planetebook.com/mainpage.asp?webpageid=170 FBI nabs Russian expert at Def Con http://www.zdnet.com/zdnn/stories/news/0,4586,5094266,00.html U.S. Arrests Russian Cryptographer as Copyright Violator http://www.nytimes.com/2001/07/18/technology/18CRYP.html (Registration required.) Russian Adobe Hacker Busted http://www.wired.com/news/politics/0,1283,45298,00.html eBook security debunker arrested by Feds http://www.theregister.co.uk/content/55/20444.html Hacker Arrested at Def Con http://www.techtv.com/cybercrime/digitaldisputes/story/0,23008,3337541,00.html FBI Arrests Russian Creator Of E-Book-Decoding Software http://www.newsbytes.com/news/01/168042.html ### Excerpted = THE INDUSTRY STANDARD'S M E D I A G R O K A Commentary on What the Press Is Reporting and Why = | http://www.thestandard.com | Wednesday, July 18, 2001 ** Subscribe to Freematt's Alerts: Pro-Individual Rights Issues Send a blank message to: [EMAIL PROTECTED] with the words subscribe FA on the subject line. List is private and moderated (7-30 messages per week) Matthew Gaylor, (614) 313-5722 ICQ: 106212065 Archived at http://groups.yahoo.com/group/fa/ ** - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Adobe Jail (fwd)
-- Eugen* Leitl a href=http://www.lrz.de/~ui22204/;leitl/a __ ICBMTO : N48 10'07'' E011 33'53'' http://www.lrz.de/~ui22204 57F9CFD3: ED90 0433 EB74 E4A9 537F CFF5 86E7 629B 57F9 CFD3 -- Forwarded message -- Date: Tue, 17 Jul 2001 08:44:57 -0700 (PDT) From: Tom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Adobe Jail I report on this over at Plesant[1] yesterday but todays update is pretty damn amazing, So I will recap the old and new story here. The Battle of the Ebooks rages on. Adobe is trying hard to be the leader of the Secure Ebook initiative on the web, selling the idea that publishing companies can securely sell their books over the web as PDF files while keeping those files locked to anyone but the person who purchased them. The problem is, the files are far from secure. The good folks at ELCOMSOFT[2] are proving this with some great reasoned explanations and some sample code which in the end show that Adobe's security is open for copying. Adobes response, at first, is to try to shut down ELCOMSOFT rather than their own security problems. This whole battle is also part of the ongoing fight over wether its legal for a person to make a back up copy of something they purchase, be it a cassette tape, dc, dvd, software or ebook. The copyright laws [3] used to allow this but now thanks to the Bono Laws and the Digital Millennium Copyright Act [4] this is being phased out in favor of the publishers holding total control over what and when and how a copy can be made. Its fascinating to watch all this play out over the course of decades running from Fair Use [5] to Fairly Usless[4]. said Tom Higgins on Monday, July 16, 2001 Then this morning I read this over at Slashdot[6] Posted by michael on Tuesday July 17, @08:09AM from the welcome-to-the-U.S.,-now-go-to-jail dept. Richard and many other people sent in news about Dmitry Sklyarov, a programmer at Russian software company Elcomsoft, who was arrested after giving a talk at Def Con 9 in Las Vegas titled eBook Security: Theory and Practice.[7] Elcomsoft publishes a program to remove restrictions from encrypted PDF files, which has severely annoyed Adobe Corporation. Adobe was apparently responsible for the arrest, charging that Elcomsoft is violating the Digital Millennium Copyright Act by publishing the software and giving the presentation at Def Con. (The presentation, by the way, is great - he compares the claimed features of ebook protection schemes with their actual features.) Also at Def Con 9: Hacking for Human Rights. [1] http://www.pleasant.blogspot.com/ [2] http://www.elcomsoft.com/aebpr.html [3] http://www.copyright.gov/ [4] http://www.educause.edu/issues/dmca.html [5] http://www.negativland.com/intprop.html#copyright [6] http://slashdot.org/yro/01/07/17/130226.shtml [7] http://www.download.ru/defcon.ppt /\ [---=== WSMF http://wsmf.org---===---] \ / X ASCII Ribbon Campaign / \ Against HTML Mail http://xent.com/mailman/listinfo/fork - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Sender and receiver non-repudiation
On Tue, 3 Jul 2001 [EMAIL PROTECTED] wrote: there is even simpler misappropriation ... that of virus on the machine ... how do you really know what your computer is doing. The more control you have over your machine, and the environment, the more security you have. By hiding sensitive tasks into armored compartments you can push this way further, making it sufficiently secure for all practical purposes. with paper signatures it is somewhat more clear-cut that the person signing a document ... is actually looking at the document they are signing. With digital signatures it becomes murkier ... how does somebody But you are looking at a representation of a document, as rendered in the frame buffer. If you're worried about your machine being compromised, either use armored crypto hardware protected by clean protocols/interfaces, or an air gap protected machine containing only the barest OS essentials and crypto binaries, only transferring _passive_ (thanks to MS, it's essentially just plain ASCII) documents via sneakernet. For practical purposes you would use a smart card with a crypto processor on it. I personally think it would be interesting to see what can be done with polymer/OLED frame buffers printed directly on the top of a deep embedded, which does both video and crypto directly in the framebuffer compartment, and only talks via a fast packet switched network to the rest of the (wearable) computer. The less code and state is in there, the less potential for exploits. know that what they are looking at is the same thing that the computer is calculating a digital signature for. -- Eugen* Leitl a href=http://www.lrz.de/~ui22204/;leitl/a __ ICBMTO : N48 10'07'' E011 33'53'' http://www.lrz.de/~ui22204 57F9CFD3: ED90 0433 EB74 E4A9 537F CFF5 86E7 629B 57F9 CFD3 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: undersea taps
Military intelligence folks have always been very adept in playing with the press. By throwing a juicy sausage one after another into the kennel, you can keep the dogs chasing their own tails indefinitely. (It's fun, too, unless you happen to be a dog). Professional paranoia would seem to require to assume any disclosures about spooks' limitations and capabilities to be deliberately planted, attempting to hog limited resource (human attention span and mentation). An advanced sleight of hand, to distract your attention from what is really going on, so to speak. (Pray pay no attention to the man behind the curtain). Whether they're really tapping them, or not, and by whatever means, the sane assumption is that everything that goes out in clear is stored for later analysis, if any. The real issue, of course, is to get strong cryptography deployed ubiquitously, so that anything intercepted will require considerable resources (whether man in the middle (by no means academic, if you control the bulk of the traffic), or breaking a cryptosystem), and making mass screening for keywords (such as in this mail -- welcome to Echelon's database, email is low-bandwidth, and storage is cheap these days) impractical. Perry E. Metzger wrote: To me, it seems reasonably obvious that the targets of undersea tapping would not be cables that make landfall in the U.S., but those that do not. The point would be to tap lines that travel between two non-US landfalls. The US is not a terminus for all the world's communications, although it is involved in a surprising fraction of international calls... __ ICBMTO : N48 10'07'' E011 33'53'' http://www.lrz.de/~ui22204 57F9CFD3: ED90 0433 EB74 E4A9 537F CFF5 86E7 629B 57F9 CFD3 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Tamperproof devices and backdoors
David Honig wrote: Under an assumed name SOP pp. 5-7. Both Altera and Xilinx have their own FPGA-embeddable soft CPUs, as well as supporting other popular CPU designs (e.g., ARM) which are also available in HDLs. Unfortunately, I think here's another nucleus for future bloat growth, and hence nooks and crannies to hide nasty nuggets. Amen. But putting a trapdoor in a HDL synthesizer (analogous to KT's evil compiler) would be a real chore. Though some easy holes, It *is* more difficult, but why unnecessarily exposing attackable angles? like inserting a covert oscillator modulated by an interesting signal, could be a covert RF-emission 'asset'. Those long cross-chip routing wires are cm-sized antennae, no? Still, your (vendor-specific) HF-tight packaging is another issue. Incidentally, tamperproof packages with fiber optic I/O and power supply are extremely RF-silent, not susceptible to EMP (of course, you have still protect the semiconductor laser outside powering it as well as the external part of the system as a monocular display with drivers) and since you've got photonic coupling you can't analyze power fluctuations, so it is a far more opaque box. Plus galvanic separation, of course. It does really make a lot of sense, but I haven't seen any such system in the field yet. FPGA-specific place route tool (analogous to an assembler) would show the gates unless it too had been subverted. And the test structures (JTAG? JEDEC? lets you read out otherwise hidden internal state via a special test mode) are almost always there ---even in crypto chips. A real Achilles heel one imagines. Chuck Moore (a lunatic twin of late Seymour Cray) makes interesting excursions into minimalism. I think he has got lot to say, unfortunately in an extremely personalized, quirky way. He doesn't care what people think of him, nor seems he to be interested in eventually producing a viable product but just runs around and having loads of fun. Essentially, he's bypassing the HDL level by using a roll-your-own silicon simulator (written in Forth, naturally, and running on the current iteration of the stack CPU hardware he designs and tweaks stuff at bare silicon level or only slightly above. He can afford so because he can pack ridiculous amounts of functionality into a mere 12 kTranstor core, including analog I/O, high-speed networking and video (!). For instance, by tweaking the size of a critical (literally so) hot spot transistor he suddenly was capable to dramatically enhance the CPU clock while not touching the rest. He doesn't advertize the current capabilities, but despite being forced to use obsolete fabbing processes for cost reasons (prototyping hardware is currently a very costly enterprise) his stuff seems to be very, very fast. For instance, he has made a counter which uses a 1-wire keyboard, where the key pressed is detected by relativistic TOF, in a process where this was supposedly impossible. It would be a real shame if his set of skills would get lost, he's not exactly the youngest anymore. But he seems to be a rather difficult fellow. I hope someone is looking over his shoulder, and taking notes. I definitely think that -- provided inkjet circuit printers become available such extreme minimalism would be very useful for roll-your-own deep crypto embedding. You sure can't hide anything in the hardware layer, and you can read the OS (I've got a Novix 4k dev kit from mid-1980s, and it came with the 2 kByte OS listing as printout -- you could read it as if was a newspaper, and I don't even know Forth). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
