RE: Run a remailer, go to jail?
Derek, etal If you (or anyone) goes, I'm sure we'd all appreciate some notes on what transpired. I understand 17 different bills are being considered at this hearing, so don't blink or you may miss it. Peter Trei -- From: Derek Atkins[SMTP:[EMAIL PROTECTED] Dave Emery [EMAIL PROTECTED] writes: For those on this list in the Boston area there is a hearing scheduled on the Mass Bill at 10 Am in Room 222 of the Mass State House in Boston. 10am on what date? -derek -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Run a remailer, go to jail?
Sidney Markowitz writes: They both require that the use of such technologies be for the purpose of committing a crime. The Massachusetts law defines as a crime: (b) Offense defined.--Any person commits an offense if he knowingly (1) possesses, uses, manufactures, develops, assembles, distributes, transfers, imports into this state, licenses, leases, sells or offers, promotes or advertises for sale, use or distribution any communication device: [ ... ] or; (ii) to conceal or to assist another to conceal from any communication service provider, or from any lawful authority, the existence or place of origin or destination of any communication; [...] (5) Assist others in committing any of the acts prohibited by this section. To heck with remailers, anonymizing proxies, etal. As I read this, the USPO is liable if it accepts a letter without a correct return address. Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Russia Intercepts US Military Communications?
reusch[SMTP:[EMAIL PROTECTED] wrote: Via the Cryptome, http://www.cryptome.org/, RU sure, look at http://www.aeronautics.ru/news/news002/news082.htm. I'm amazed at their claims of radio interception. One would expect that all US military communications, even trivial ones, are strongly encrypted, given the ease of doing this. Someone, more well informed, please reassure me that this is the case. Otherwise, yet another thing is very wrong about this war and the infrastructure that supports it. -MFR There are a lot of people who don't consider this source credible. After the site was cited on the Interesting People list, the following appeared. I'll leave it up to the reader as to who to believe. Peter From: Stephen D. Poe [EMAIL PROTECTED] Subject: Venik iraqwar.ru Follow-Ups To: [EMAIL PROTECTED] Date: Thu, 27 Mar 2003 21:42:48 -0600 Organization: Nautilus Solutions Reply-To: [EMAIL PROTECTED] Dave - There's currently several newsgroup threads discussing iraqwar.ru (see sci.military.naval:The credibility of Iraqwar.ru or lack thereof and smn:Intel evaluation 2003.03.25, in rec.aviation.military:The Noted Waterhead: Venik and even in alt.engr.exploisves:Russian analysis of the ongoing battles in Iraq). Regarding Venik and his site at http://www.aeronautics.ru; I suggest a few minutes spent on Google will be informative. He's well know to both sci.military.naval and rec.aviation.military posters and lurkers. Historically he's not known for his accuracy. He's probably best known for his heated assertions during the Yugoslavia conflict as to how many planes NATO lost, NATO's deliberate targeting of civilian targets, and NATO's use of chemical weapons. His claims of multiple shoot-downs of everything from F-16s to B-2s and B-52s were somewhat quickly quashed given the hobby of tail spotters worldwide. Many of his other claims, such as A NATO pilot admits that civilian targets were deliberately attacked during the operation Allied Force and that NATO aviation used chemical weapons were likewise not later confirmed. See: http://www.aeronautics.ru/natodown.htm and a Google search for Venick B-2 Shoot Down as examples. I would have to view anything with his name associated with it with suspicion. -- Archives at: http://www.interesting-people.org/archives/interesting-people/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Encryption of data in smart cards
John Kelsey[SMTP:[EMAIL PROTECTED] At 11:08 PM 3/12/03 +0100, Krister Walfridsson wrote: ... This is not completely true -- I have seen some high-end cards that use the PIN code entered by the user as the encryption key. And it is quite easy to do similar things on Java cards... With any kind of reasonable PIN length, though, this isn't all that helpful, because of the small set of possible PINs. And smartcards don't generally have a lot of processing power, so making the PIN-key mapping expensive doesn't help much, either. /Krister --John Kelsey, [EMAIL PROTECTED] Every PINned SC I've seen has a very limited (typically 3) number of failed attempts before it locks itself up. Once it's locked up, it can only be reactivated by an administrator PIN, which is held at much higher security by the issuer, and not available to the card user. Peter - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Scientists question electronic voting
Ian Brown[SMTP:[EMAIL PROTECTED] wrote: Ed Gerck wrote: Printing a paper receipt that the voter can see is a proposal that addresses one of the major weaknesses of electronic voting. However, it creates problems that are even harder to solve than the silent subversion of e-records. For example, using the proposed system a voter can easily, by using a small concealed camera or a cell phone with a camera, obtain a copy of that receipt and use it to get money for the vote, or keep the job. And no one would know or be able to trace it. As a voter could record what they did with pencil-and-paper or a mechanical voting machine. The partial defence in all three systems is that the voter should be able to void the vote after photographing a receipt to hand over later to the vote-buyer, and then cast a real vote. In the UK, for example, you can obtain a new ballot paper from a polling station official in exchange for a spoiled one. I believe Rebecca Mercuri has always suggested that a voter should be able to confirm whether a receipt printed by an electronic voting machine correctly records their intended vote, and if not to void it. I'd prefer that the printed receipt be retained at the polling station, after the voter has had an opportunity to examine it. This serves two purposes: First, it prevents the vote selling described above, and second, if a recount is required, it allows the recount to be done on the basis of a trustworthy record, already certified by the voter as accurate. This loses some of the economic benefits of all-electronic systems, since security still needs to be provided for the receipts for some period, but is far less prone to invisible abuse. Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Scientists question electronic voting
Francois Grieu[SMTP:[EMAIL PROTECTED] Peter Trei wrote: I'd prefer that the printed receipt be retained at the polling station, after the voter has had an opportunity to examine it. This serves two purposes: First, it prevents the vote selling described above, and second, if a recount is required, it allows the recount to be done on the basis of a trustworthy record, already certified by the voter as accurate. Then there is the problem that the printed receipt must not be usable to determine who voted for who, even knowing in which order the voters went to the machine. Therefore the printed receipts must be shuffled. Which brings us straight back to papers in a box, that we shake before opening. Every way I look at it, electronic voting has a hard time to match the resilience to abuse of the traditional bulletin-in-an-enveloppe-in-a-box. Francois Grieu I absolutely agree. Here in the US, where voters often have to make over a dozen choices each time they vote, the value of automating the process is significant. But it *must* be done in a way which increases voter confidence in the result. Ballot boxes are also subject to many forms of fraud. But a dual system (electronic backed up by paper) is more resistant to attack then either alone. Peter - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Columbia crypto box
Pete Chown[SMTP:[EMAIL PROTECTED]] Arnold G. Reinhold wrote: Indeed, but it is important to remember just how thickheaded the anti-crypto effort of the '80s and '90s was and how much damage it did. As a footnote to those times, 2 ** 40 is 1,099,511,627,776. My PC can do 3,400,000 DES encryptions per second (according to openssl). I believe DES key setup is around the same cost as one encryption, so we should halve this if a different key is being used each time. Brute force of a 40-bit DES key will therefore take about a week. In other words 40-bit DES encryption is virtually useless, as brute force would be available to anyone with a modern PC. -- Pete You can actually do much better that that for key set up. To toot my own horn, one of the critical events in getting software DES crackers running at high speed was my realization that single-bit-set key schedules can be OR'd together to produce any key's schedule. Combining this with the use of Grey Codes to choose the order in which keys were tested (Perry's idea) led to key scheduling taking about 5% of the time budget. Peter - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Columbia crypto box
Arnold G. Reinhold[SMTP:[EMAIL PROTECTED]] wrote: It's worth remembering that the original WEP used 40 bit keys. For some time, RC4 with 40 bit keys was the only crypto system that could be exported without a license. It's hard for me to believe that export concerns were not the primary factor in the initial choice of RC4. Arnold Reinhold If I recall correctly (dee3: Can you help?) WEP is actually derived from the encryption system used in the Apple Mobile Messaging System, a PCMCIA paging card made for the Newton in the mid-90s. This used 40 bit RC4. Though only a few years have passed, it's difficult to remember now what an encumberance the ITAR export regulations were. Essentially, there was a (very short) list of ciphers and modes you could export. 40-bit RC4 was relatively easy to export. Anything better,or anything which had not been already approved by the NSA, faced a bureaucratic nightmare and huge delays if it was approved at all. Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Columbia crypto box
Steven M. Bellovin[SMTP:[EMAIL PROTECTED]] wrote: In message [EMAIL PROTECTED] m, Trei, Peter writes: If I recall correctly (dee3: Can you help?) WEP is actually derived from the encryption system used in the Apple Mobile Messaging System, a PCMCIA paging card made for the Newton in the mid-90s. This used 40 bit RC4. Though only a few years have passed, it's difficult to remember now what an encumberance the ITAR export regulations were. Essentially, there was a (very short) list of ciphers and modes you could export. 40-bit RC4 was relatively easy to export. Anything better,or anything which had not been already approved by the NSA, faced a bureaucratic nightmare and huge delays if it was approved at all. The 40-bit issue is orthogonal to the other problems with WEP. Look at IBM's Commercial Data Masking Facility (CDMF), a way to degrade the strength of DES from 56 bits to 40 bits, while still ensuring that they didn't enable any less-expensive attack. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) I totally agree that WEP has/had problems well beyond the export issue, but that's not my point. A product which cannot be exported will not be developed, generally speaking. I quote from AC2 (Schneier), page 615 (which was published in 1996): The State Department does not approve of the export of products with strong encryption, even those using DES. [...] The Software Publishers Association (SPA) has been negotiating with the government to ease export license restrictions. A 1992 agreement between them and the State Department eased the export license rules for two algorithms, RC2 and RC4, as long as the key size is 40 bits or less. So, it doesn't matter how espionage-enabled CDMF was, if you wanted to export crypto for general use, you were stuck with RC2 or RC4. This situation eased slightly (to 56 bits) around 1997, but did not reach today's conditions until 2000. The AMMS system cited above dates to 1995. (It feels weird to be citing Schneier as a historical document). Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Columbia crypto box
Matthew Byng-Maddick[SMTP:[EMAIL PROTECTED]] writes: On Sun, Feb 09, 2003 at 11:43:55PM -0500, Donald Eastlake 3rd wrote: been that you either throw away the first 256 bytes of stream key output or use a different key on every message. WEP does neither. TKIP, the new You NEVER, EVER, re-use the key for a stream cipher, if you do, you might as well just give up. By re-using the key, I can get plaintext (combinator) plaintext, which is easier to solve than plaintext (combinator) cipherstream. It's one of those things, like re-using a pad. MBM The weird thing about WEP was its choice of cipher. It used RC4, a stream cipher, and re-keyed for every block. . RC4 is not really intended for this application. Today we'd have used a block cipher with varying IVs if neccessary I suspect that RC4 was chosen for other reasons - ease of export, smallness of code, or something like that. It runs fast, but rekeying every block loses most of that advantage. Just my personal musings Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: A talk on Intellectual Property and National Defense
Adam Shostack[SMTP:[EMAIL PROTECTED]] writes: I believe that DRM systems will require not just an authorized boot sequence, but a secure remote attestation that that boot sequence was followed, and a secure attestation as to the versions of the software on your system. So, while a secure system is needed for AT/DRM, its not enough. Let me get this straight - in order to make the RIAA and MPAA richer, we're going to ban off-net computer use? If you're not near a WiFi hotspot you won't be able to boot your laptop? Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: RIAA turns against Hollings bill
John Gilmore[SMTP:[EMAIL PROTECTED]] writes: Nomen writes: How does this latest development change the picture? If there is no Hollings bill, does this mean that Trusted Computing will be voluntary, as its proponents have always claimed? And if we no longer have such a threat of a mandated Trusted Computing technology, how bad is it for the system to be offered in a free market? The detailed RIAA statement tries to leave exactly this impression, but it's the usual smokescreen. Check the sentence in their 7 policy principles joint statement, principle 6: ... The role of government, if needed at all, should be limited to enforcing compliance with voluntarily developed functional specifications reflecting consensus among affected interests. I.e. it's the same old game. TCPA is such a voluntarily developed functional spec. So is the broadcast flag, and the HDCP copy protection of your video cable, and IBM's copy-protection for hard disk drives. Everything is all voluntary, until some competitor reverse engineers one of these, and builds a product that lets the information get out of the little consensus boxes. Consumers want that, but it can't be allowed to happen. THEN the role of government is to eliminate that competitor by outlawing them and their product. John enforcing compliance with voluntarily developed functional specifications appears to be NewSpeak for: Let the RIAA, not Congress, write the laws, and then send in Men With Guns to enforce them. Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: 'E-postmark' gives stamp of approval
The PO tried marketing this service about 6 years ago. As far as I can see, this is almost identical to the last try. It failed in the marketplace then, and I see no reason whatsoever to think it will suceed now. Favorite paragraph: Having a feature certified as secure by a federal agency contributes to the sense of trustworthiness Microsoft is trying to impart after numerous high-profile security lapses. Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: New Protection for 802.11
James A. Donald[SMTP:[EMAIL PROTECTED]] wrote: Reading the Wifi report, http://www.weca.net/OpenSection/pdf/Wi- Fi_Protected_Access_Overview.pdf it seems their customers stampeded them and demanded that the security hole be fixed, fixed a damned lot sooner than they intended to fix it. I am struck the contrast between the seemingly strong demand for wifi security, compared to the almost complete absence of demand for email security. Why is it so? --digsig James A. Donald How many stories have you read in the last year about non-LEOs stealing email? How many stories in the last year have you read about wardriving? Further, tapping into 802.11b nets * gives the attacker access to your internal network. You already know what you're sending in email, and eavesdropping on data you've already decided to send to someone else feels different than someone trolling through your file system without your knowledge. * requires that the tapper be more or less nearby physically. This feels a lot different than worrying that a distant router is compromised. Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Did you *really* zeroize that key?
[Moderator's note: FYI: no pragma is needed. This is what C's
volatile keyword is for. Unfortunately, not everyone writing in C
knows the language. --Perry]
From RISKS:
http://catless.ncl.ac.uk/Risks/22.35.html#subj6
Those of us who write code need to be reminded of this
now and then.
Peter Trei
---
Software leaves encryption keys, passwords lying around in memory
Monty Solomon [EMAIL PROTECTED]
Wed, 30 Oct 2002 22:31:46 -0500
http://online.securityfocus.com/archive/82/297827
Date: Thu, 31 Oct 2002 05:11:31 +1300 (NZDT)
From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Software leaves encryption keys, passwords lying around in
memory
The following problem was first pointed out (in private mail) by
Michael
Howard from Microsoft. His writeup is now available at
http://msdn.microsoft.com/library/en-us/dncode/html/secure10102002.asp.
From a representative check of a few widely-used open source crypto
programs, this affects quite a bit of software.
The problem he points out is that clearing sensitive information such
as
encryption keys from memory may not work as expected because an
optimising
compiler removes the memset() if it decides it's redundant. Consider
for
example the following:
int encrypt( const void *key )
{
puts( key ); /* Normally we'd encrypt here */
}
void main( void ) /* Because we can */
{
char key[ 16 ];
strcpy( key, secretkey );
encrypt( key );
memset( key, 0, 16 );
}
When compiled with any level of optimisation using gcc, the key
clearing
call goes away because of dead code elimination (see the MSDN article
for
more details on this, which uses VC++ to get the same effect). While
you
can kludge enough stuff around a custom memory-clear call to fool the
optimiser (hacks with 'volatile', touching the memory after it's
cleared and
hoping the optimiser is fooled, etc etc) there's no guarantee that
it'll
work for anything but the compiler(s) you happen to test it with -
any
future enhancement to the optimiser may turn it back into a nop.
What it
really needs is the addition of a #pragma
dont_remove_this_code_you_bastard
in the compiler. Until then, a lot of security code will be affected
by
this problem.
[In RISKS, I tend never to alter British spellings. However,
in American English, an optimiser must be the ultimate miser.]
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: QuizID?
Branchaud, Marc writes: Any thoughts on this device? At first glance, it doesn't seem particularly impressive... http://www.quizid.com/ Lovely idea of two-factor authentication: The user then enters their user name (something they know) and the 8-digit Quizid passcode (something they have) into the login screen of their application. BBC NEWS | Technology | Handy future for online security http://news.bbc.co.uk/1/hi/technology/2334491.stm Excerpt from the BBC article: Users are issued with a card and a personal code, based on a set of colour keys on the card. Each time they wish to conduct a secure transaction, they punch in the colour code and a random number is generated. M. [Note of vested interests: I work on RSA SecurID, which is a competing product.] Based on the information at the site, and Quizid's statement that their hardware is manufactured by ActivCard, I have to say that this looks an *awful lot* like the ActivCard Keychain Token, repackaged into a bigger form factor. Peter Trei Disclaimer: The above represents only my personal opinion. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: RSA's RC5-64 Secret Key Challenge has been solved.
Ralf-P. Weinmann[SMTP:[EMAIL PROTECTED]] wrote: On Thu, Sep 26, 2002 at 02:45:12PM -0700, John Gilmore wrote: [...] After getting that getting started, though, I suggest beginning a brute-force attack on the GSM cellphone encryption algorithm. That's in use in hundreds of millions of devices worldwide, protecting (or failing to protect) the privacy of billions of phone calls a day. Is A5/3 deployed yet? If not, a brute force attack is not needed, for A5/1 and A5/2 more efficient tools exist to cryptanalyse it. Even in real-time, although you might need to invest in some hard disk space before being able to eavesdrop and intercept. See the following paper for more information: A. Biryukov, A. Shamir and D. Wagner, Real Time Cryptanalysis of A5/1 on a PC As for A5/3, I'm not really sure what key length network operators are/will be using, 64-128 bits are allowed in the design requirements documentation. The specification should be available on the 3GPP website. A5/3 is based on Kasumi. Cheers, Ralf I spoke to David McNett ([EMAIL PROTECTED]) yesterday. He told me that they intend to fire up a the RC5-72 challenge, hoping to get lucky and find the key near the beginning. I think they're open to other suggestions, however. Factoring may or may not be reasonable. While RC5, DES, etc require minimal memory and storage, and can so run unobtrusively in the spare cycles of almost any machine, factoring, - even the seiving step - has large memory and storage requirements. The matrix reduction step at the end does not have any efficient distributed implementation I'm aware of. I think the lower RSA factoring challenges *may* be possible - RSA-576 is still standing, with a $10k prize. Other factoring challenges have up to $200k prizes. Challenges need to be carefully set up. It must be legal - hacking a deployed system in the face of the objections of the owner won't fly. It must be credible, in that there must be no reason to suspect collaboration between the challenger and the attacker. It must be realistic - it should model a real-world use closely enough to show that changes need to be made (the RSA secret key challenges where designed with IPSEC headers in mind - the single DES option was deprecated as soon as we showed that to be weak). This is an exciting time. With RC5-64 fallen, there are a lot of options for what to do next. The most interesting thing may not involve cryptanalysis. Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RSA's RC5-64 Secret Key Challenge has been solved.
First, the official PR release: --- Distributed Team Collaborates to Solve Secret-Key Challenge Contest designed to keep the cryptographic community updated on new achievements and help organizations maintain highest levels of security Bedford, MA, Thursday, September 26, 2002 - RSA Laboratories, the research center of RSA Security Inc. (Nasdaq: RSAS), the most trusted name in e-security(r), today announced that a coordinated team of computer programmers and enthusiasts, known as distributed.net, has solved the RC5-64 Secret-Key Challenge. The distributed.net team solved the challenge in approximately four years, using 331,252 volunteers and their machines. Distributed.net receives a cash prize of $10,000 for solving the challenge. Established in 1997, RSA Laboratories' Secret-Key Challenge is offered to quantify the strength of symmetric encryption algorithms such as DES and the RC5(r) algorithm with various key sizes. By sponsoring an actual contest, RSA Laboratories helps the industry confirm theoretical estimates, and through this constant evaluation, vendors are motivated to continue to improve their security solutions. The distributed.net consortium utilized the idle time of computers throughout the world to search through the list of all possible 64-bit keys for RSA Security's RC5 algorithm to find the one secret key selected at random by RSA Laboratories that decrypts a given message correctly. RSA Laboratories sponsors a series of cryptographic challenges that allow individuals or groups to attempt to solve various encryption puzzles for cash prizes. The RC5-64 Challenge is one of a series of contests held to determine the difficulty of finding a symmetric encryption key by exhaustive search (trial-and-error). Previous contests include the DES Challenge, the RC5-40 Challenge and the RC5-56 Challenge. We're very appreciative of all the volunteers who offered their time and computer's idle processing time to help solve this challenge, said David McNett, distributed.net co-founder and president. We have once again shown how collective computing power can be applied to security technology with ordinary PCs. We look forward to future RSA Laboratories-sponsored challenges that will assist in helping the cryptographic community gauge the strength of an algorithm or application against exhaustive key search. RSA Security congratulates the distributed.net team in solving the RC5-64 Secret-Key Challenge, said Burt Kaliski, chief scientist at RSA Laboratories. We appreciate the persistence of distributed.net and the many individuals involved in completing the search for this one key. Their work helps the industry confirm how much work is involved to search exhaustively for a key - and how a huge volume of computing time can be harnessed. The various challenges we sponsor are very useful for tracking the state of cryptographic achievements and helping ensure that organizations are maintaining the highest levels of security to protect their most critical data assets. About RSA Security Inc. RSA Security Inc., the most trusted name in e-security, helps organizations build trusted e-business processes through its RSA SecurID(r) two-factor authentication, RSA ClearTrust(r) Web access management, RSA BSAFE(r) encryption and RSA Keon(r) digital certificate management product families. With approximately one billion RSA BSAFE-enabled applications in use worldwide, more than 12 million RSA SecurID authentication users and almost 20 years of industry experience, RSA Security has the proven leadership and innovative technology to address the changing security needs of e-business and bring trust to the online economy. RSA Security can be reached at www.rsasecurity.com. RSA, RC5, BSAFE, ClearTrust, Keon, SecurID and The Most Trusted Name in e-Security are registered trademarks or trademarks of RSA Security Inc. in the United States and/or other countries. All other products and services mentioned are trademarks of their respective companies. - A personal note: In case people are wondering, the key turned out to be 63 DE 7D C1 54 F4 D0 39 and the encrypted message was The unknown message is: Some things are better left unread. I'm really happy with this - I wrote to Jim Bidzos proposing the contests way back in the fall of 1996, long before I came to work at RSA. At the time, I was aimed at killing DES, and creating pressure to ease the export limits on key size (they had just been raised from a ludicrous 40 up to 56. I didn't think this was good enough). I feel that I entirely suceeded. So I was in at the start of the contests, and at the end of this one (I was one of the two people at RSA who independently confirmed the decryption). I expect that this will be the last one attacked for a while - the next keylength is 72 bits, and at d.net's current rate, that would take them several centuries. Peter Trei
RE: Cryptogram: Palladium Only for DRM
Niels Ferguson[SMTP:[EMAIL PROTECTED]] wrote: Well, I'm tired of this. AARG, or whoever is hiding behind this pseudonym, is obviously not reading the responses that I send, as he keeps asking questions I already answered. I'm not going to waste more of my time responding to this. This is my last post in this thread. Have Fun! Niels Of course, this is just what AARG wants - he has never actually been interested in trying to persuade you. He just wants to wear down the people who are able to effectively dispute his claims to the point where they shut up, abandon the field of battle, and leave his position trimphant by default. He doesn't care about the truth, or whether you have shown him to be false. He just wants to win. Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: trade-offs of secure programming with Palladium (Re: Palladium: technical limits and implications)
Russell Nelson[SMTP:[EMAIL PROTECTED]] writes: You're wearing your programmer's hat when you say that. But the problem isn't programming, but is instead economic. Switch hats. The changes that you list above may or may not offer some security advantages. Who cares? What really matters is whether they increase the cost of copying. I say that the answer is no, for a very simple reason: breaking into your own computer is a victimless crime. In a crime there are at least two parties: the victim and the perpetrator. What makes the so-called victimless crime unique is that the victim is not present for the perpetration of the crime. In such a crime, all of the perpetrators have reason to keep silent about the comission of the crime. So it will be with people breaking into their own TCPA-protected computer and application. Nobody with evidence of the crime is interested in reporting the crime, nor in stopping further crimes. [...] Russ: Take off your economic hat, and try on a law-enforcement one. With DMCA, etal, the tools to get around TCPA's taking of your right to use your property as you please have been criminalized. (Don't argue that TCPA will always be voluntary. I don't beleive that). I have little patience with arguments which say 'Yeah, they can make X against the law, but clever people like me can always get around it, and won't get caught, so I don't care.' Maybe you can, some of the time, but that's not the point. Most people won't, either because it's too hard, they don't know what they've lost, or because of a misplaced respect for the whims of The Men with Guns. This is not a Good Thing. A freedom to skulk in the shadows, hoping not to be noticed, is not the legacy I wish to leave behind. Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Challenge to David Wagner on TCPA
Jon Callas[SMTP:[EMAIL PROTECTED]] On 8/1/02 1:14 PM, Trei, Peter [EMAIL PROTECTED] wrote: So my question is: What is your reason for shielding your identity? You do so at the cost of people assuming the worst about your motives. Is this a tacit way to suggest that the only people who need anonymity or pseudonymity are those with something to hide? Jon Not really. However, in todays actual environment, this is frequently true that those with something to hide use anonymity. While some people have maintained nyms for many years (I can't think of anyone maintaining explicit stong anonymity right now, actually - remember Sue D. Nym? ), and used them to talk about a variety of issues, it's pretty rare. It's rare enough that when a new anononym appears, we know that the poster made a considered decision to be anonymous. The current poster seems to have parachuted in from nowhere, to argue a specific position on a single topic. It's therefore reasonable to infer that the nature of that position and topic has some bearing on the decision to be anonymous. Since the position argued involves nothing which would invoke the malign interest of government powers or corporate legal departments, it's not that. I can only think of two reasons why our corrospondent may have decided to go undercover... 1. If we know who he/she/them were, it would weaken the argument (for example, by making it clear that the poster has a vested interest in the position maintained, or that 'AARGH! is the group effort of an astroturf campaign). 2. If the true identity of the poster became known, he/she/them fears some kind of retribution: * The ostracism and detestation of his peers. * The boycotting of his employer. * His employer objecting to his wasting company time on Internet mailing lists. Our corrospondent has not given us any reason not to infer the worst motives. This is, after all, a discipline where paranoia and suspicion are job requirements. Peter Trei Disclaimer: The above represents my private , personal opinions only; do not misconstrue them to represent the opinions of others. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Challenge to David Wagner on TCPA
AARG! Anonymous[SMTP:[EMAIL PROTECTED]] writes [...] Now, there is an optional function which does use the manufacturer's key, but it is intended only to be used rarely. That is for when you need to transfer your sealed data from one machine to another (either because you have bought a new machine, or because your old one crashed). In this case you go through a complicated procedure that includes encrypting some data to the TPME key (the TPM manufacturer's key) and sending it to the manufacturer, who massages the data such that it can be loaded into the new machine's TPM chip. So this function does require pre-loading a manufacturer key into the TPM, but first, it is optional, and second, it frankly appears to be so cumbersome that it is questionable whether manufacturers will want to get involved with it. OTOH it is apparently the only way to recover if your system crashes. This may indicate that TCPA is not feasible, because there is too much risk of losing locked data on a machine crash, and the recovery procedure is too cumbersome. That would be a valid basis on which to criticize TCPA, but it doesn't change the fact that many of the other claims which have been made about it are not correct. [...] While I reserve the right to respond to the rest of the poster's letter, I'd like to call out this snippet, which gives a very good reason for both corporate and individual users to avoid TCPA as if it were weaponized anthrax (Hi NSA!). ... OK, It's 2004, I'm an IT Admin, and I've converted my corporation over to TCPA/Palladium machines. My Head of Marketing has his TCPA/Palladium desktop's hard drive jam-packed with corporate confidential documents he's been actively working on - sales projections, product plans, pricing schemes. They're all sealed files. His machine crashes - the MB burns out. He wants to recover the data. HoM:I want to recover my data. Me: OK: We'll pull the HD, and get the data off it. HoM:Good - mount it as a secondary HD in my new system. Me: That isn't going to work now we have TCPA and Palladium. HoM:Well, what do you have to do? Me: Oh, it's simple. We encrypt the data under Intel's TPME key, and send it off to Intel. Since Intel has all the keys, they can unseal all your data to plaintext, copy it, and then re-seal it for your new system. It only costs $1/Mb. HoM:Let me get this straight - the only way to recover this data is to let Intel have a copy, AND pay them for it? Me: Um... Yes. I think MS might be involved as well, if your were using Word. HoM:You are *so* dead. --- Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: New Chips Can Keep a Tight Rein on Consumers
John S. Denker[SMTP:[EMAIL PROTECTED]] wrote: Peter Gutmann wrote: Actually I'm amazed no printer vendor has ever gone after companies who produce third-party Smartchips for remanufactured printer cartridges. This sounds like the perfect thing to hit with the DMCA universal hammer. I wonder if there's a good reason for this? Why is this particular field immune? I don't know the whole story, and I don't know anything for sure, but here's a hypothesis and a starting point: Expand the acronym DMCA to discover the word copyright. IANAL but: As a rule, copyrights aren't supposed to be used to protect functionality; that's what patents are for. Reverse engineering in general remains legal ... not just laissez-faire legal, but actually protected by the fair-trade laws. DMCA carves out an exception in the case of reverse engineering that promotes violation of copyrights. A micron-by-micron copy of the smartchip would be a violation of somebody's plain-old non-DMCA copyright in the mask, but a clone that reproduces the functionality is fair game. You might wonder about a hypothetical next step: printer vendors could put some crypto in the system (so that every smartchip would _need_ to have a copy of the key) and then invoke copyright on the key. IANAL but that might be asking for trouble. 0) Copyrights are not supposed to be used to protect functionality, as discussed above. 1) Printer vendors aren't analogous to DVD vendors, because the latter have intellectual property rights in the content, long recognized by law, which they are allowed to protect. Preventing piracy is a _perfectly legal_ limitation on trade. In contrast, printer makers have far fewer recognized rights in the ink. Trying too hard to mess up the aftermarket in ink might be considered an _illegal_ restraint of trade. 2) Related point: The printer vendors claim that the chips are there merely to provide necessary functionality, which is legal. Court action against somebody who didn't copy anything but the key would put the lie to this claim. And then you would have questions about the legality of the chips; see item (1). There's related legal precedent, but I'm too lazy to look up the details. Over 10 years ago a game console manufacturer 'Foo' (Nintendo? Atari?) sued an independent game cartridge manufacturer, claiming copyright infringement in that the console checked that a specific location in the cartridge contained the string Copyright (c) Foo Inc. The console maker lost; the judge ruled that including the string was neccesary for perfectly legal compatibility reasons. (I note that it was also only visible to the console, not to the consumer). This seems quite appropos to the printer cartridge situation, but IANAL. Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Followup: [RE: DOJ proposes US data-rentention law.]
Two points: 1. According to Poulson, the DOJ proposal never discussed just what would be logged. Poulson compared it to the European Big Brother legislation, which required storage to Web browsing histories and email header data. 2. After I posted the same info to /. http://slashdot.org/articles/02/06/19/1724216.shtml?tid=103 (I'm the 'Anonymous Coward' in this case), Kevin updated his article. The new version may be found at: http://online.securityfocus.com/news/489 The relevant portions read: - start quote - U.S. Denies Data Retention Plans The Justice Department disputes claims that Internet service providers could be forced to spy on their customers as part of the U.S. strategy for securing cyberspace. By Kevin Poulsen, Jun 19 2002 12:24PM [...] But a Justice Department source said Wednesday that data retention is mentioned in the strategy only as an industry concern -- ISPs and telecom companies oppose the costly idea -- and does not reflect any plan by the department or the White House to push for a U.S. law. [...] - end quote - Peter Trei -- From: David G. Koontz[SMTP:[EMAIL PROTECTED]] Sent: Thursday, June 20, 2002 10:57 AM To: [EMAIL PROTECTED] Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: Re: DOJ proposes US data-rentention law. Trei, Peter wrote: - start quote - Cyber Security Plan Contemplates U.S. Data Retention Law http://online.securityfocus.com/news/486 Internet service providers may be forced into wholesale spying on their customers as part of the White House's strategy for securing cyberspace. By Kevin Poulsen, Jun 18 2002 3:46PM An early draft of the White House's National Strategy to Secure Cyberspace envisions the same kind of mandatory customer data collection and retention by U.S. Internet service providers as was recently enacted in Europe, according to sources who have reviewed portions of the plan. In recent weeks, the administration has begun doling out bits and pieces of a draft of the strategy to technology industry members and advocacy groups. A federal data retention law is suggested briefly in a section drafted in part by the U.S. Justice Department. If the U.S. wasn't in an undeclared 'war', this would be considered an unfunded mandate. Does anyone realize the cost involved? Think of all the spam that needs to be recorded for posterity. ISPs don't currently record the type of information that this is talking about. What customer data backup is being performed by ISPs is by and large done by disk mirroring and is not kept permanently. I did a bit of back of the envelope calculation and the cost in the U.S. approaches half a billion dollars a year in additional backup costs a year without any CALEA type impact to make it easy for law enforcment to do data mining. The estimate could easily be low by a factor of 5-10. AOL of course would be hit by 40 percent of this though, not to mention a nice tax on MSN. Call it ten cents a day per customer in fee increases to record all that spam for review by big brother. I feel safer already. Whats next, censorship? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: FC: Hollywood wants to plug analog hole, regulate A-D converters
-- From: Nomen Nescio[SMTP:[EMAIL PROTECTED]] Sent: Thursday, May 30, 2002 12:20 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: FC: Hollywood wants to plug analog hole, regulate A-D converters Peter Trei writes: My mind has been boggled, my flabbers have been ghasted. In the name of protecting their business model, the MPAA proposes that every analog/digital (A/D) converter - one of the most basic of chips - be required to check for US government mandated copyright flags. Quite aside from increasing the cost and complexity of the devices many, manyfold, it eliminates the ability of the US to compete in the world electronics market. This is absurd. In all the commentary on this issue, no one has made the obvious point that the MPAA has no interest or intention in putting watermark detectors into every ADC chip! They don't care about the ADC chip in a digital thermometer or even a cell phone. All they care about are things like PC video capture cards, which are high fidelty consumer devices capable of digitizing copyright protected content. Their white paper is a brief summary of their goals and intentions and does not go into full technical detail. But let's use a little common sense here, folks. This is the actual paragraph that people are refering to: [from http://judiciary.senate.gov/special/content_protection.pdf] - start quote - The primary means to address this issue, dubbed the analog hole, is via embedded watermarks (which have additional applications as will be discussed below). In order to help plug the hole, watermark detectors would be required in all devices that perform analog to digital conversions. In such devices (e.g., PC video capture cards), the role of the watermark detector would be to detect the watermark and ensure that the device responds appropriately. - end quote - Note that is refers to all devices that perform analog to digital conversions. I agree that compromising all a/d chip is probably not what the MPAA had in mind (their example is a video capture card, a much more complex beast), but overbroad language has gotten into too many laws for me to have any faith that it can't happen again. What's going to happen when someone publishes plans to remove the restrictions from a compromised vidcap card, and explains how to mail order standard DACs? Will trafficing in DAC chips become a DMCA violation? It's pointless to try to shoot down this proposal by raising all these horror stories about ADC chips in industrial and technical devices being crippled by a watermark detector which will never be activated. If you waste time developing this line of argument, you will be left with nothing to say when the actual bill focuses only on the specific devices that the content holders are worried about. [...] Please, let's use some common sense and not go overboard with an obviously mistaken interpretation of the MPAA's intentions. That wastes everyone's time. I agree that the MPAA's reccomendation is laughable, but stupidity has never stopped politicians from passing laws. Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Just how bad is the Microsoft Visual C++ 6 rand function, anyway?
Now, I'm sure no one on this list would trust MSVC6 rand() for anything
important, but this post from sci crypt (which I have not cofirmed)
may be of interest:
Peter Trei
- start quote -
Newsgroups: sci.crypt, sci.crypt.random-numbers
Subject: Warning: MSVC6 rand function
Message-ID: fu9G8.288206$[EMAIL PROTECTED]
Organization: Bellsouth.Net
Date: Mon, 20 May 2002 12:31:09 -0400
In case anyone's interested, the rand() function that ships in the C runtime
library with Microsoft Visual Studio 6.0 is a *15-bit* LC-PRNG. Not only
that, but the most significant bit, which is also the most random bit in an
LC-PRNG, is discarded by masking.
Code snippet follows:
int __cdecl rand (void)
{
return(((holdrand = holdrand * 214013L + 2531011L) 16) 0x7fff);
}
- end quote ---
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Schneier on Bernstein factoring machine
Russell Nelson[SMTP:[EMAIL PROTECTED]] wrote Derek Atkins writes: I think it's really about degree. I don't agree that having a non-empty threat model implies you a paranoid. Yes, you're right (and Phil Pennock points out that I meant intersection, not union). Dictionary.com defines paranoia as Extreme, irrational distrust of others. I'm not using the correct word here (nor are other people), because there are rational reasons to distrust nosyparkers. So what *is* the right word for having a non-empty threat model for moderate and rational reasons? Prudence. Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Schneier (and RSA) on Bernstein factoring machine
R. A. Hettinga[SMTP:[EMAIL PROTECTED]] At 3:54 PM -0400 on 4/16/02, Trei, Peter wrote: Well, Lucky's not a business, and he's certainly not a military institution (despite his fondness for ordnance). What does that leave? Most of us who know him got a little chuckle out of this. One should also note, that, last time I looked at least, that Mr. Briceno ended up at RSA as part of the XCert buyout. Cheers, RAH The last time you looked was too long ago, I'm afraid. Lucky is no longer with RSA. Peter - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Schneier (and RSA) on Bernstein factoring machine
Anonymous[SMTP:[EMAIL PROTECTED]] Bruce Schneier writes in the April 15, 2002, CRYPTO-GRAM, http://www.counterpane.com/crypto-gram-0204.html: But there's no reason to panic, or to dump existing systems. I don't think Bernstein's announcement has changed anything. Businesses today could reasonably be content with their 1024-bit keys, and military institutions and those paranoid enough to fear from them should have upgraded years ago. To me, the big news in Lucky Green's announcement is not that he believes that Bernstein's research is sufficiently worrisome as to warrant revoking his 1024-bit keys; it's that, in 2002, he still has 1024-bit keys to revoke. Does anyone else notice the contradiction in these two paragraphs? First Bruce says that businesses can reasonably be content with 1024 bit keys, then he appears shocked that Lucky Green still has a 1024 bit key? Why is it so awful for Lucky to still have a key of this size, if 1024 bit keys are good enough to be reasonably content about? Anonymous is missing the joke here. Bruce suggests that ordinary non-paranoid users (here represented as 'businesses') should feel reasonably content with 1024 bit keys, but 'military institutions and those paranoid enough to fear them should have upgraded years ago'. So, we have three categories of users: 1. businesses (ie, 'ordinary users) 2. Military institutions. 3. The paranoid (whether justified or not). Well, Lucky's not a business, and he's certainly not a military institution (despite his fondness for ordinance). What does that leave? Most of us who know him got a little chuckle out of this. For RSA's 'official' position on this issue, take a look at: http://www.rsasecurity.com/rsalabs/technotes/bernstein.html If there's a call for it, I'll post the whole text so you can read it without visiting our site (it's not too long). Peter Trei RSA Security - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
One for the snakeoil file.
[Note: I'm just passing on posts from sci.crypt. I've not confirmed this independently It appears that not every product which uses smart cards is secure - pt] From: [EMAIL PROTECTED] (Philippe Mestral) Newsgroups: sci.crypt Subject: I've tested the encryption system that comes with Acer laptops, and it's not pretty. Date: 26 Mar 2002 05:48:36 -0800 Message-ID: [EMAIL PROTECTED] Some Acer laptops comes with a built-in smartcard reader and a file encryption program called Platinum Secure. My company recently acquired two of them. I spent some time playing around with that encryption system and came to the following conclusions: - they use a basic XOR stream cipher. - the keystream is always the same for any file, encrypted by any user on any of the two laptops I have. - I was able to generate that keystream with a long enough binary file containing only 0 and encrypting it. - I am now able to decrypt any file encrypted on either laptop without the smartcard. I am no crypto expert. It is surprising to me that a manufacturer would release such a badly designed product. It's even worse that providing no security at all, because with this product the users *think* their files are secure while they obviously aren't. any thoughts/comments? also, has anyone here already had this product in their hands? could someone who has installed that program possibly create a text file, put the string test in it, encrypt the file and send it to me at [EMAIL PROTECTED] so that I can see whether the encrypted file looks like mine or not? (they wouldn't use the same keystream for ALL their laptops would they?) thanks in advance. -- From: Scott Fluhrer [EMAIL PROTECTED] Date: Tue, 26 Mar 2002 07:33:28 -0800 Message-ID: a7q4ni$r77$[EMAIL PROTECTED] Joël Bourquard [EMAIL PROTECTED] wrote in message news:3ca091af$[EMAIL PROTECTED]... Philippe Mestral [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Some Acer laptops comes with a built-in smartcard reader and a file encryption program called Platinum Secure. [...] - they use a basic XOR stream cipher. - the keystream is always the same for any file, encrypted by any user on any of the two laptops I have. [...] - I am now able to decrypt any file encrypted on either laptop without the smartcard. Hi, I'm completely astonished by what you said. What I can't understand, is why they're using a smartcard.. unless they want people to BELIEVE that's secure. Well, the keystreams might be different for different smartcards (not that that would make it any more secure). Alternatively, they might put the keystream generation program on the smartcard, in the vain hope that if people can't look at it, they have a harder time cryptanalyzing it. -- poncho -- From: Philippe Mestral [EMAIL PROTECTED] References: [EMAIL PROTECTED] 3ca091af$[EMAIL PROTECTED] a7q4ni$r77$[EMAIL PROTECTED] [EMAIL PROTECTED] Date: Tue, 26 Mar 2002 18:48:49 +0100 Well, the keystreams might be different for different smartcards (not that that would make it any more secure). Alternatively, they might put the keystream generation program on the smartcard, in the vain hope that if people can't look at it, they have a harder time cryptanalyzing it. Oh yes, I assumed he did use two different smartcards with the two laptops.. and that the keys were the same. Maybe he didn't. I did. - From: Philippe Mestral [EMAIL PROTECTED] Date: Tue, 26 Mar 2002 19:19:28 +0100 Message-ID: 3ca0ba42$0$24006$[EMAIL PROTECTED] Joël Bourquard [EMAIL PROTECTED] wrote in message news:3ca091af$[EMAIL PROTECTED]... Hi, I'm completely astonished by what you said. What I can't understand, is why they're using a smartcard.. unless they want people to BELIEVE that's secure. apparently the card is used to store a unique ID which authenticates the card owner. As several card owners can use the same pc and the encrypting method and key are always the same, they had to find some sort of way to tell what file was encrypted by what user. A registry key contains information regarding encrypted files. For each encrypted file, a string is added to the registry. Its name is the current date concatenated to the encrypted file name, and its value corresponds to the unique ID of the user who encrypted the file (plus the original file extension, go figure). When a request to decrypt an encrypted file is made, the program browses the list of encrypted files in the registry. If it founds a file whose date time and name correpond, it then checks that the user who encrypted that file corresponds to the one whose card is inserted in the reader. If it does, the file is decrypted. Incidentally, modifying the date and/or name of an encrypted file
distributed.net looking for a new ISP.
Distributed.net, which has won several of the RSA Secret Key challenges, and is currently 73% of the way through the RC5-64 contest, has lost it's ISP. Peter Trei From their front page: - start quote We need your help! URGENT: We have recently learned that our long-standing arrangement with Texas.Net (formerly Insync) would end at noon, Friday, March 22. Through an agreement with Insync, we were hosted at no charge for many years. Though we have tried to make other arrangements with them or to continue our current service until we can make other arrangements, in the end we had no choice but to move. Several of the Austin cows made a road trip Friday morning to retrieve our equipment from their colocation facility. We have no reason to complain about Texas.Net or their current decision. As a business, they chose to donate to us for a long time, and have now decided that they must stop. In dbaker's words in a letter to Texas.Net: Our experience with Insync has been excellent; I've never been happier with an Internet provider. I've recommended them (and indirectly, Texas.Net) to everyone and even this [situation] won't change that. Though United Devices has kindly offered to colocate our primary servers for a short time at no expense, we find ourselves in the market for a new ISP. If any of our participants work for a major ISP in Texas (preferably within a few hours of Austin, but we're not picky), and would be willing to donate colocation space and connectivity, we would eagerly like to speak with you. Our typical bandwidth usage is 3Mb/s, and reliable uptime is of course essential. Please e-mail [EMAIL PROTECTED] if you think you may be able to help us in this area. - end quote - - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: 1997 RSA DES Challenge
I might be able to help you. I was the person who initiated the the DES Challenges, getting RSA Data Security to sponsor them, and working with people in RSA Labs on their design (this was before I switched employers to RSA). I also wrote one of the search engines. I have a fair bit of data, but some of it is on Zip disks which may or may not still be readable. I also have a lot of info on the background of the challenges. I gave a keynote speech at the 1997 RSA Conference on the subject. Peter Trei Principal Engineer RSA Security [EMAIL PROTECTED] -- From: Matt Curtin[SMTP:[EMAIL PROTECTED]] Sent: Wednesday, March 06, 2002 5:10 PM To: [EMAIL PROTECTED] Subject: 1997 RSA DES Challenge Hi, I'm writing a book about the 1997 DESCHALL project, tentatively entitled /Brute Force/. I'm using a lot of my own notes and whatnot from the period to reconstruct the whole story. If anyone else has anything that would be helpful for putting the story back together, including the activity in other efforts, political goings-on from the period, etc., I'd be very grateful to receive them. Specifically, I'd like to get ahold of: o SolNET stats, project milestones o SGI DES Challenge stats, project milestones o DES Violation Group stats, project milestones I've been recently in touch with Rocke Verser and Justin Dolske and would also love to hear from other DESCHALL developers. /Brute Force/ is intended to be the story of the project, including basically enough technology for the reader to understand just what we did and how we did it, without becoming a book on DES key cracking optimization. The focus in the story, the groups and people involved, with the political, legal, and Internet computing threads woven throughout the story. I'm hoping to have it finished in time to be in stores on the fifth anniversary of our success. (Yes, it's been five years!) Thanks in advance for any data, pointers, or other help in getting this story told. -- Matt Curtin, Founder Interhack Corporation http://web.interhack.com/ My new book, /Developing Trust: Online Privacy and Security,/ is now available. See site for details. research | development | consulting - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
The Original SSSCA
[The SSSCA would require all devices capable of carrying media content to have hardware locks to prevent copyright violations. Essentially, it turns all computers as closed as set-top boxes - and about as useful. See http://www.politechbot.com/cgi-bin/politech.cgi?name=sssca for background -pt ] I've been watching the entertainment industry's approach to computers with what I can only think of as Kafkaesque horror. It's simply unthinkable that preserving the business models of entertainers trumps the utterly central role of computers and the Internet in improviing our existance. Apparently the politicians are actually *receptive* to this. I guess this just shows how money corrupts - the heavy donor's interests outweigh those of the nation. I've been trying to think of an analogy to show just how awful the idea of the SSSCA is. I've had to go back a way. A long way. -- (start satire) The Original SSSCA. Statement of Yakval Enti, spokesman of the MPAA (Mnemonists, Praise-singers, and Anthemists Association) to His Highness Hammurabi, King of Sumeria: Your Majesty: I wish to call you attention to a severe threat to the security of your kingdom, and the livelihoods of thousands of your subjects. After Shamash sets and the people kick back after a long day of growing millet, they desire entertainment. Their favorite forms are stories, tales, and sagas, told by the members of the MPAA. Talented boys spend up to 12 years learning the tales by heart at the feet of the masters. Any evening MPAA members can be found in the taverns singing the old tales, praising the praiseworthy, and creating new tales from the old. This system has worked well since the beginning of time - there were storytellers at your coronation, there were storytellers at your father's coronation, and there were storytellers in the caves of our ancestors. This natural arrangement is now threatened from an unexpected direction - the scribes and accountants. The geeks' system of recording numbers and quantities has been perverted to freeze speech onto clay. Understand the threat to our business model. At the moment, if someone wants to hear 'The Tale of the Ox, the Ass and the Sumerian', they find an MPAA member, pay him, and sit back to listen to the whole four hour saga. While anyone could recall and tell others the general outline, only MPAA members know every detail and can give the listener the whole story. If you want to hear it again, you pay again. Thousands of MPAA members rely on this fact for their livelihoods. With the recent invention of writing the system is in danger of collapse. We've found that some scribes are actually recording entire sagas onto clay. Any scribe can read these out to people for free or for money, complete and word-for-word, without being a member of or paying the MPAA! A scribe who has obtained a set of tablets of an story can even read it an unlimited number of times, or (worst of all) make copies. This is starting to have an economic impact on our membership. Consider Rimat-Ninsun, whose masterwork The Epic of Gilgamesh took him three years to create, and who looked to it to put bread on his table into his old age, as he told it for money, or let others tell it under paid license after learning it from him. 'Gilgamesh' is now circulating on 12 clay tablets, and Rimat is starving. Who will bother to create new tales if they are just going to be written down? Writing presents insidious dangers to your kingdom as well. It can be anonymous. Before writing, any message arrived with a person to speak it, who could be held accountable for their speech. With writing, it is impossible to tell what scribe wrote a message. Anonymous threats, kidnap notes, and untraceable sedition are now possible. Clearly writing carries with it far greater problems for our civilization than it does advantages. However, scribes, accountants, and their skills are essential to business, contracts, laws, and the collection of taxes. We just need to make sure that they are controlled properly. I therefore propose the Scribal Stylus Safety Control Act. (SSSCA). This requires every scribe to have an MPAA approved, literate slave with him at all times, peering over his shoulder. If a scribe is seen to be writing' something other then accounting information, for example a story (stories are the province of MPAA storytellers), or a message (which should have been given to a paid mnenomist for delivery), or anything seditious, then the slave will take away the scribe's stylus and call the authorities. I ask you to have this Act written into your Code of Law. Is this difficult? Yes. Is it expensive? Yes. However, it is clear that without strict controls, widespread writing will not only destroy the entertainment industry, it will threaten civilisation itself! (end satire) The SSSCA threatens to return us to a Stone Age model of information use. Disclaimer: The above
RE: Cloak, or Cloaca? :-)
Ben Laurie[SMTP:[EMAIL PROTECTED]] Keyring and Strip are both programs that provide secure DBs on Palms. Keyring, at least, is free and open source. However, since Palms have no MMU, there's no security against hostile other apps, which makes them pretty useless devices for this kind of purpose. I'm coming into this a bit late, but the security situation on PalmOS is not quite as dire as you make out (at least thru OS 3.5, maybe later). The reason is that the OS is single-threaded, and does not have preemptive multitasking. The OS sends the current app a message, saying, essentially 'Shut down now and let something else happen'. The app can take it's sweet time about this, and delay things long enough to zeroize or encrypt any sensitive data. Peter Trei The right answer, IMO, is EROS on an MMUed handheld device (not sure about the biometric aspect - as I've stated at tedious length before, I like my appendages and don't want to give people incentive to steal them), such as that thing that runs Linux whose name temporarily escapes me, or the new Sharp gadget. Or a Jornada if they ever make one small enough. We have the technology. All we need is someone to finance it. Cheers, Ben. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Losing the Code War by Stephen Budiansky
I read the article (in the dead tree edition), and despite it's technical inaccuracies, thought it was generally pretty good. Don't forget that the MITM attack (which Schneier claims takes 2^(2n) = 2^112 time), also requires 2^56 blocks of storage. That's a lot, and the attack ceases to be parallelizable, unlike the straight brute-force attack. In fact, it's utterly intractable at the moment. Here's why: 2^56 bytes = 72 petabytes, and I suspect you'd need 8 bytes per entry, or about 1/2 an exabyte. By contrast, all of morpheus is currently less than half of one petabyte. Google indexes about 3 billion documents + 700 million usenet postings. At a an estimated 100kb per item, that's roughly the same as morpheus. I don't lose sleep over MITM attacks on 3DES. Peter Trei -- From: Ben Laurie[SMTP:[EMAIL PROTECTED]] Sent: Saturday, February 02, 2002 8:57 AM To: marius Cc: [EMAIL PROTECTED] Subject: Re: Losing the Code War by Stephen Budiansky marius wrote: But there was an utterly trivial fix that DES users could employ if they were worried about security: they could simply encrypt each message twice, turning 56-bit DES into 112-bit DES, and squaring the number of key sequences that a code breaker would have to try. Messages could even be encrypted thrice; and, indeed, many financial institutions at the time were already using Triple DES. Not quite true. Encrypting each message twice would not increase the effective key size to 112 bits. There is an attack named meet in the middle which will make the effective key size to be just 63 bits. ?? 56 bits plus a little, surely. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Welome to the Internet, here's your private key
One other scheme I've seen, and which, while it doesn't give me warm fuzzies, seems reasonable, is to issue the the enduser a smartcard with a keypair on it. The SC generates the pair onboard, and exports only the public half. The private half never leaves the SC (there is no function on the card to export it). If you trust the above, then the only copy of the private key is on the SC, despite it having been generated without the end users participation. Peter -- From: Jaap-Henk Hoepman[SMTP:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 8:45 AM To: [EMAIL PROTECTED] Subject: Re: Welome to the Internet, here's your private key It's worse: it's even accepted practice among certain security specialists. One of them involved in the development of a CA service once told me that they intended the CA to generate the key pair. After regaining consciousness I asked him why he thought violating one of the main principles of public key cryptography was a good idea. His answer basically ran as follows: if the CA is going to be liable, they want to be sure the key is strong and not compromised. He said that the PC platform of an ordinary user simply wasn't secure/trusted enough to generate keys on. The system might not generate `good enough' randomness, or might have been compromised by a trojan. Jaap-Henk On Sun, 3 Feb 2002 15:09:57 +0100 [EMAIL PROTECTED] writes: It is accepted practice among security people that you generate your own private key. It is also, unfortunately, accepted practice among non-security people that your CA generates your private key for you and then mails it to you as a PKCS #12 file (for bonus points the password is often included in the same or another email). Requests to have the client generate the key themselves and submit the public portion for certification are met with bafflement, outright refusal, or at best grudging acceptance if they're big enough to have some clout. This isn't a one-off exception, this is more or less the norm for private industry working with established (rather than internal, roll-your-own) CAs. This isn't the outcome of pressure from shadowy government agencies, this is just how things are done. Be afraid. -- Jaap-Henk Hoepman | Come sail your ships around me Dept. of Computer Science | And burn your bridges down University of Twente | Nick Cave - Ship Song Email: [EMAIL PROTECTED] === WWW: www.cs.utwente.nl/~hoepman Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590 PGP ID: 0xF52E26DD Fingerprint: 1AED DDEB C7F1 DBB3 0556 4732 4217 ABEF - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Unbreakable? (fwd)
There are plenty of 'thought experiment' crypto systems which are utterly infeasible in practice. Rabin's is one. It does have perfect forward secrecy in that if Eve doesn't know ahead of transmission time what part of the keystream to grab, she can't later decrypt the message. But, as Nicholas points out, it doesn't solve the key distribution problem, merely shifts it. Alice and Bob still have find some way to securely coordinate beforehand what part of the 'random' bitstream they will use as their OTP. There are many other problems: * The HW needed to generate cryptographically sound random data at the required rate is extremely expensive, if it exists at all. * The HW needed to recieve data at that rate is very expensive. * Since accuracy is required, error correcting codes will have to be included, increasing the data rate still further. *putting up a constellation of satellites is also very expensive - where's the revenue to do all this coming from? ...and the big one: Could you *trust* the 'randomness' of a bitstream handed you from a source you cannot check? Sorry, folks, this one is a non-starter. Peter Trei -- From: Nicholas Brawn[SMTP:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 1:47 AM To: Sean McGrath Cc: [EMAIL PROTECTED] Subject: Re: Unbreakable? (fwd) Correct me if I'm wrong, but isn't such a system feasible by: 1. Having the network infrastructure available to support the continuous traffic loads. 2. Having a suitable RNG source that can cope with the reseeding/etc requirements of encrypting bulk data. 3. Having a mechanism to insert genuine information into these massive streams of data. I suppose the issue is communicating to the third party which part of the data contains the interesting stuff. From what Rabin is saying, it appears that the increased security is achieved by the third party not knowing what is important and what isn't. How you communicate this with your trusted third party is the problem. You can't simply send a transmission when a new section of interesting stuff is coming through, because then the evil folk can simply watch for the notification, then capture that section of the traffic. Perhaps you could send a transmission that says in x bytes time for the next x bytes, is the next message. That would include some latency that the evil third party can't reliably interperet. But does that work for frequent transmissions? Seems interesting nevertheless. Nick -- Real friends help you move bodies. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Welome to the Internet, here's your private key
I'm not the local expert on this, but there are SCs with built-in crypto accelerators. They are designed for the use I described: * Generate an RSA key pair on board, * export the public key, * re-import the certificate, * wrap/unwrap a data block (typically a session key or hash for signing) using the onboard key pair without ever exporting the secret half of the key pair. While they typically only use a PIN or passphrase for protection, they usually will commit electronic seppuku if too many (typically 3) bad PINs or passphrases are entered. With these, you can let your CA admin run the SW to create the keys and sign the public key, and still have reasonable assurance that he has not snagged a copy of the private key. Peter Trei -- From: Bill Frantz[SMTP:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 3:41 PM To: Bill Stewart; [EMAIL PROTECTED] Subject: RE: Welome to the Internet, here's your private key At 10:20 AM -0800 2/4/02, Bill Stewart wrote: There are special cases where the user's machine doesn't have the CPU horsepower to generate a key - PCs are fine, but perhaps Palm Pilots and similar handhelds are too slow (though a typical slow 33MHz 68000 or Dragonball is faster than the 8086/80286 MSDOS machines that PGP originally ran on.) Cash machines may be too slow, but they normally run symmetric crypto. A smartcard-only system probably _is_ too limited to generate keys, but that's the only realistic case I see. It may depend on the public key system you are using. Where you have to search for numbers which have certain mathematical properties (like with RSA), then you can indeed use a bunch of CPU. For systems like DSA, where the private key is in essence a random number, there is not searching, and key generation is a lot faster. Cheers - Bill - Bill Frantz | The principal effect of| Periwinkle -- Consulting (408)356-8506 | DMCA/SDMI is to prevent| 16345 Englewood Ave. [EMAIL PROTECTED] | fair use. | Los Gatos, CA 95032, USA - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: password-cracking by journalists...
Karsten M. Self[SMTP:[EMAIL PROTECTED]] writes: Note that my reading the language of 1201 doesn't requre that the work being accessed be copyrighted (and in the case of Afghanistan, there is a real question of copyright status), circumvention itself is sufficient, regardless of status of the specific work accessed: 17 USC 1201(a)(1)(A): No person shall circumvent a technological measure that effectively controls access to a work protected under this title. I'm sure I'm picking nits here (and I praise God every day that I Am Not A L*wy*r), but what does 'effectively' mean? If it can be broken, was it effective? What level of work is required to make it an 'effective technological measure'? If the standard is 'anything, including rot13', then why is the word present in the rule at all? Technological measures can range from violating the CDROM standard and introducing deliberate errors to confuse some readers, all the way up to full real-time, online, 3-factor authentication. The inclusion of the word 'effectively' presumes the existance of 'ineffective' technological measures, which it would be no crime to circumvent. Where, then, is the distinction? I'm reminded of a humorous button I've seen at some SF conventions: Anything not nailed down is legally mine. Anything I can pry up wasn't nailed down in the first place. Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RSA Conference 2002: Free Expo passes, academic discounts and scholarships available.
(feel free to forward this message in its entirety) The RSA Data Security Conference is being held February 18-22, 2001, at the McEnery Convention Center in San Jose, California. This is the biggest computer security conference in the world, with 200 vendors and over 10,000 attendees. Personally, I think it's a blast, and attend every year. I'm sending this to remind list members that, although the full conference is quite costly, there are (as in previous years) a couple of ways to get all or part of the show for free, and a discounted fee for academic types. -- Free Expo Passes: The Expo is the Exposition Hall, where about 200 computer security companies from all over the world will be pushing their products and looking for new hires. Free passes for the expo are available if you register over the web until February 15. After that (or at the door) they cost $50. The Expo is open Tuesday the 19th and Wednesday the 20th from 11AM to 7PM, and Thursday the 21st until 3PM. - Academic Scholarships ssh Communications Security Inc. has sponsored a number of student scholarships. Any full-time student wishing to apply for a RSA Conference 2002 scholarship should submit a curriculum vitae (CV) to RSA Security via email at [EMAIL PROTECTED] Preference will be given to graduate students and advanced undergraduates in relevant disciplines. Please note that scholarships do not cover travel expenses, meals or lodging. - Academic discounts (if you can't get a scholarship :-) The RSA Conference offers a discounted registration fee of $595.00 to students and professors of academic universities. (which is way less than half the regular fee) Full information on the conference can be found at http://www.rsaconference.com (which, as others have pointed out, is Flash-heavy :-( I'm talking to people to try to get that changed next year.) See you there! Peter Trei [EMAIL PROTECTED] [PS: I have no input into the scholarship selection process, so don't send me anything.] This e-mail, its content and any files transmitted with it are intended solely for the addressee(s) and are PRIVILEGED and CONFIDENTIAL. Access by any other party is unauthorized without the express prior written permission of the sender. If you have received this e-mail in error you may not copy, disclose to any third party or use the contents, attachments or information in any way, Please delete all copies of the e-mail and the attachment(s), if any and notify the sender. Thank You. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Stegdetect 0.4 released and results from USENET search available
There's a much simpler reason why few or no stego'ed messages are present in usenet images: They form an inefficient and unneeded distribution mechanism. Try taking a peek at the Usenet newsgroup alt.anonymous.messages. Dozens for PGP'd messages a day, from our old friends Secret Squirrel, Nomen Nescio, and Anonymous. Usenet has some very good properties for those wishing to maintain privacy: multiple entry points, including from mail2news gateways, flooding distribution independent of message content, and knowledge of who reads what is restricted to the server from which the news is read (and there are 1000's of news servers, as well as web based systems such as groups.google.com). But you already know this. Posting PGP to aam also avoids the bandwidth bloat imposed by stego, and the extra complication of having to stego and destego images, as well as generate the images used for cover. Why would anyone bother hide tiny messages in ebay images or alt.binaries.erotica.bestiality.hamster when they can just post to aam? Peter Trei -- From: Niels Provos[SMTP:[EMAIL PROTECTED]] Sent: Friday, December 28, 2001 4:33 AM To: Arnold G. Reinhold Cc: [EMAIL PROTECTED] Subject: Re: Stegdetect 0.4 released and results from USENET search available In message v04210101b84eca7963ad@[192.168.0.3], Arnold G. Reinhold writes: I don't think you can conclude much from the failure of your dictionary attack to decrypt any messages. We are offering various explanations. One of them is that there is no significant use of steganography. If you read the recent article in the New York Times [1], you will find claims that about 0.6 percent of millions of pictures on auction and pornography sites had hidden messages. 2. The signature graphs you presented for several of the stego methods seemed very strong. I wonder if there is more pattern recognition possible to determine highly likely candidates. I would be interested in seeing what the graphs look like for the putative false alarms you found. It also might be interesting to run the detection program on a corpus of JPEGs known NOT to contain stego, such as a clip art CD. The following slides contain examples of false-positives http://www.citi.umich.edu/u/provos/papers/detecting-csl/mgp00023.html http://www.citi.umich.edu/u/provos/papers/detecting-csl/mgp00024.html In my experience, eliminating false-positives is not quite that easy. Some graphs look like they should have steganographic content even though they do not. Any test will have a false-positive rate, the goal is to keep it very low. 3. If you did succeed in decrypting one of Osama Bin Laden's missives, wouldn't he have a case against you under DMCA? Good question. The panel about the DMCA at the USENIX Security Symposium seemed to indicate that the exceptions built into the DMCA have no real meaning. In my understanding of the American legal and judicial system, it is not possible to know what is right or wrong according to some law until one has been taking to court about it. Niels. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] This e-mail, its content and any files transmitted with it are intended solely for the addressee(s) and are PRIVILEGED and CONFIDENTIAL. Access by any other party is unauthorized without the express prior written permission of the sender. If you have received this e-mail in error you may not copy, disclose to any third party or use the contents, attachments or information in any way, Please delete all copies of the e-mail and the attachment(s), if any and notify the sender. Thank You. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: private-sector keystroke logger...
Ben Laurie[SMTP:[EMAIL PROTECTED]] wrote: [EMAIL PROTECTED] wrote: Jay D. Dyson writes: -BEGIN PGP SIGNED MESSAGE- On Tue, 27 Nov 2001 [EMAIL PROTECTED] wrote: Hrm, how about a worm with a built-in HTTP server that installs itself on some non-standard port, say TCP/28462 (to pick one at random)? Craftier still, backdoor an existing service that behaves normally until it receives a few specially-crafted packets, then it opens a high port for direct login or data retrieval. Neither of these will get past a firewall on an uncompromised machine. While I didn't enumerate the service that could be backdoored, I do believe Eric Murray hit the nail on the canonical head when he mentioned that such a beastie could target the firewall's configuration, forcing it to relax its stance enough to allow the automated intrusion agent plenty of latitude to conduct its business. I am assuming a firewall on a separate machine, which simply does not allow incoming connections to the window's boxes, and constrains the outgoing connections. I do not claim that this prevents all covert loss of data, but it constrains the options, and certainly does not permit the described backdoor to work. Yeah right - so it sets up an outgoing connection to some webserver to pass on the info. Firewall that. Cheers, Ben. ...or takes the data of interest (which is generally fairly small), uuencodes it, and sends it in an email or an encrypted usenet posting. Any application which allows in interior machine to send data to the outside creates a potential covert channel. There's a reason why classified machines are airgapped. Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RC4 [was: RE: Passport Passwords Stored in Plaintext]
[This response probably can't get to all of the lists to which the original message was addressed to. Feel free to forward it to those lists, if you can, and to other addresses as needed. -pt] Alex Alten[SMTP:[EMAIL PROTECTED]] wrote: [.discussion of .NET weaknesses deleted]] RC4 is broken. Period. The key setup machinery has been broken and the internal PRNG/pad generation machinery has been partially broken. Just say NO to RC4. Alex Alten [EMAIL PROTECTED] - [I work for RSA, which owns RC4] I strongly suggest that Alex and other interested parties read Ron Rivest's recent paper on precisely this issue. It can be found at http://www.rsasecurity.com/rsalabs/technotes/wep.html (extract) [...] In protocols such as WEP, it is often necessary to generate different RC4 keys from different messages (or packets) from a common base key. A method frequently suggested to obtain the keys is to add or concatenate a counter to the base key. The key-scheduling algorithm of RC4 has been widely recognized to be rather lightweight for this purpose, particularly when the initial few bytes of plaintext are easily predictable. RSA Security has discouraged such key derivation methods, recommending instead that users consider strengthening the key scheduling algorithm by pre-processing the base key and any counter or initialization vector by passing them through a hash function such as MD5. Alternatively, weaknesses in the key scheduling algorithm can be prevented by discarding the first 256 output bytes of the pseudo-random generator before beginning encryption. Either or both of these techniques suffice to defeat the new attacks on WEP and WEP2. [...] (end extract) Essentially, WEP sends successive packets (with well known headers) using the initial output of RC4 keyed with successive keys. This opens WEP up to a related-key attack. I'm really curious what led to the use of RC4 in this weird mode; a block cipher in CBC mode would have been more appropriate. I suspect that the selection was made at a time when 40bit RC4 was [relatively] easy to export, while stronger block ciphers such as 56 bit DES were not. The moral re crypto restrictions is left to the reader. Peter Trei [Disclaimer: I work for RSA, but this note contains my own opinions.] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Effective and ineffective technological measures
-- From: Alan Barrett[SMTP:[EMAIL PROTECTED]] The DMCA said: 1201(a)(1)(A): No person shall circumvent a technological measure that effectively controls access to a work protected under this title. What does effectively mean here? If it has its plain english meaning, then one could argue that ROT13, CSS (and anything else that can easily be broken) are *ineffective* technological measures, so circumventing them is not prohibited by this clause. Distinguishing effective measures from ineffective measures might reduce to measuring the resources required to break them. Or does the clause really mean No person shall circumvent a technological measure that *purports to control* access to a work protected under this title? --apb (Alan Barrett) Take a look at Sklyarov's presentation: http://www.treachery.net/~jdyson/ebooks/ and especially http://www.treachery.net/~jdyson/ebooks/slide11.html The listed company allegedly puts ROT13 in a dongle, and then encrypts documents for $3000 a pop. [In fairness, I can't confirm this from their own website, and I suspect that they are just 'protecting' their own investor reports]. but read the whole Sklyarov presentation - this is not the most fraudulent form of 'protection' being foisted on naive e-publishers. Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RC5-64 attack reaches 50% mark.
The only RSA Secret Key Challenge known to be under active attack at this time is RC5-64, by distributed.net. Last night this reached the 50% mark, having tested 9,225,283,403,065,065,472 keys at the time I write this, over 1331 days. The current rate is over 210 Gkeys/sec - they should complete the keyspace in the next 18 months. See: http://stats.distributed.net/rc5-64/ Way back in the previous millenium, RSA (then Security Dynamics) issued a series of 'secret key challenges', in which prizes were offered for decrypting messages encrypted wish RC5 and DES. http://www.rsasecurity.com/rsalabs/challenges/ brag-mode:on I was responsible for getting SDTI to create the challenges, proposing them to Jim Bidzos to complement the long standing RSA factoring contests back in 1996. I was mainly interested in demonstrating that 56 bit DES (then the strongest exportable algorithm) was inadequate, and had created a proof-of-principle DES key-cracker to demonstrate that the goal was achievable. Jim thought this was a good idea, and I was soon collaborating with RSA Labs in the design of the challenges - long before I came to work at SDTI/RSA. The first challenge (40 bit RC5) fell in 3.5 hours, and was soon followed by others, leading up to the 3rd DES challenge in 1999, when distributed.net and the EFF combined to brute force a 56 bit DES key in 23 hours. The success in the attacks on the Secret Key Challenges created facts on the ground exposing the weakness of exportable crypto, and in my opinion were important in causing the relaxation of US export regulations in early 2000 brag-mode:off. Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
