Re: cryptograph(y|er) jokes?
At 11:56 PM +0200 6/19/04, Hadmut Danisch wrote: Hi, does anyone know good jokes about cryptography, cryptographers, or security? Q: How many cryptographers does it take to change a light bulb? A: XIGHCBS --- There was a story in the NY Times many years ago about an apartment dweller who was frequently burgled. Every time that happened she had a new lock added to her front door. While installing her eighth lock, the locksmith suggested she only lock half of the locks. Her place was never robbed again, but sometime she came home to find the locks she had locked open and the ones she hadn't locked were locked. --- Also see numbers 2.3 and 2.4 in the humorous list of proof techniques at http://www.maths.uwa.edu.au/~berwin/humour/invalid.proofs.html Arnold Reinhold - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is finding security holes a good idea?
The Mythical Man-Month is a great book, but it's almost 30 years old. Brooks considered OS/360 to be hopelessly bloated. My favorite quote (from Chapter 5, The Second System Effect, p. 56): For example, OS/360 devotes 26 bytes of the permanently resident date-turnover routine to the proper handling of December 31 on leap years (when it is Day 366). That might have been left to the operator. Modern operating system are 2 to 3 orders of magnitude larger than OS/360.. They are far more reliable than OS/360 was in its early days and do not presume the availability of an on-site team of operators and system programmers. For the most part they are still maintained one bug at a time The bug fixing process has not reached Brook's predicted crisis. My other concern with the thesis that finding security holes is a bad idea is that it treats the Black Hats as a monolithic group. I would divide them into three categories: ego hackers, petty criminals, and high-threat attackers (terrorists, organized criminals and evil governments). The high-threat attackers are likely accumulating vulnerabilities for later use. With the spread of programming knowledge to places where labor is cheap, one can imagine very dangerous systematic efforts to find security holes. In this context the mere ego hackers might be thought of as beta testers for IT security. We'd better keep fixing the bugs. Arnold Reinhold At 5:10 PM -0400 6/14/04, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Ben Laurie writes: What you _may_ have shown is that there's an infinite number of bugs in any particularly piece of s/w. I find that hard to believe, too :-) Or rather, that the patch process introduces new bugs. Let me quote from Fred Brooks' Mythical Man-Month, Chapter 11: The fundamental problem with program administration is that fixing a defect has a substantial (20-50 percent) chance of introducing another. So the whole process is two steps forward and one step back. Why arene't defects fixed more cleanly? First, even a subtle defect shows itself as a local failure of some kind. In fact it often has system-wide ramifications, usually nonobvious. Any attempt to fix it with minimum effort will repair the local and obvious, but unless the structure is pure or the documentation very fine, the far-reaching effects of the repair will be overlooked. Second, the repairer is usually not the man who wrote the code, and often he is a junior programmer or trainee. As a consequence of the introduction of new bugs, program maintenance requires far more system testing per statement written than any other programming. ... Lehman and Belady have studied the history of successive release in a large operating system. They find that the total number of modules increases linearly with release number, but that the number of modules affected increases exponentially with release number. All repairs tend to destroy the structure, to increase the entropy and disorder of the system. Less and less effort is spent on fixing original design flaws; more and more is spent on fixing flaws introduced by earlier fixes. As time passes, the system becomes less and less well-ordered. Sooner or later the fixing ceases to gain any ground. Each forward step is matched by a backward one. Etc. In other words, though the original code may not have had an infinite number of bugs, the code over time will produce an infinite series - 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: Satellite eavesdropping of 802.11b traffic
At 9:19 PM -0400 5/27/04, Perry E. Metzger wrote: R. A. Hettinga [EMAIL PROTECTED] writes: At 12:35 PM -0400 5/27/04, John Kelsey wrote: Does anyone know whether the low-power nature of wireless LANs protects them from eavesdropping by satellite? It seems to me that you'd need a pretty big dish in orbit to get that kind of resolution. The Keyholes(?) are for microwaves, right? Dunno if it would work in orbit,, but you can get surprising results right here on earth using phased arrays. Vivato is selling very long range phased array equipment as long range/high quality 802.11 basestations, but you could do precisely the same trick to eavesdrop instead of to communicate. With enough computing power, one device could listen in on every 802.11 communication in a very large radius. I don't know how practical it would be to set up some sort of large scale phased array in orbit -- I suspect the answer is not practical at all -- but the principle could apply there, too. I would say quite practical. A huge advantage for the attacker is that 802.11b/g is in a fixed frequency band. A half-wave dipole is 6.25 cm long. A large phased array could be assembled out of printed circuit board tiles, each with many antennas. The outdoor range for 802.11 is up to 100 m. Low earth orbit is about 150 km. That is a factor of 1500. Power attenuation is the square of that, which works out to a 64 db loss. Throw in another 10 db for slant range, building attenuation, etc. The loss has to be made up by a combination of antenna gain, improved receiver performance and better signal processing. That doesn't sound undoable. A single LEO satellite would only have a few minutes of visibility per day over any one location on Earth. That suggests an active attack, where the satellite looks for files or even changes data. The satellite's ability to transmit at much higher power levels is an advantage. A third option is spot jamming. Here high power means one can get away with a smaller antenna, perhaps wrapped around a cheaper spin stabilized satellite. Such a system could be used to briefly disable 802.11-based security systems, perhaps allowing a spy to gain access to a building. Other interesting possibilities include long endurance remotely-piloted aircraft, balloons and small receiving stations that could be planted by spies or even parachuted into position. I'm sure 802.11 has given the SIGINT community much joy. Arnold Reinhold - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The future of security
At 8:21 PM +0100 4/26/04, Graeme Burnett wrote: Hello folks, I am doing a presentation on the future of security, which of course includes a component on cryptography. That will be given at this conference on payments systems and security: http://www.enhyper.com/paysec/ Would anyone there have any good predictions on how cryptography is going to unfold in the next few years or so? I have my own ideas, but I would love to see what others see in the crystal ball. Here are my thoughts on the future of cryptography: A major use of crypto will be in efforts to restrict the dissemination of information to the public (corporate security, digital rights management, state censorship) Human factors will be regarded as equal in importance with algorithms and protocols. Servers and workstations will incorporate video and other sensors to provide self protection against physical intrusions. As cellphones and PDAs merge there will be a new generation of privacy applications for text messaging and/or voice that use light weight protocols and, perhaps symmetric keys. Cellphone cameras will be used for stenographic communication. Cellphones and PDAs will be used as security tokens for desktop/laptop access, perhaps using Bluetoth Self-booting, open source CDs will become available that turn any PC into a secure messaging system with private keys and messages stored on an encrypted disk image on a memory stick. 4096-bit RSA keys will become the standard (RSA is already recommending 1024-bit keys be phased out by 2010.) Key stretching techniques will be enhanced and standardized to allow password-based security to remain viable. Password entry will be done using mouse and display screen, rather than keyboards because of all the risks keyboards represent (software and hardware loggers, video cameras, acoustic analysis, etc.) Desktop systems with no hard drive and no I/O ports will become required for processing confidential information. One or more secure networks will emerge that parallel the existing Internet. They will use IPv6 and have mandatory encryption and authentication. Cameras and audio recorders will be equipped with GPS, digital signing and secure time stamping technologies to restore confidence in recorded evidence. Stored value smart-cards will finally become popular in the U.S. through use in public transportation systems. Hashcash will be used to bring spam under control and to protect networks against zombie attacks. Anti-spam white listing will be the killer app that finally creates a universal public key infrastructure. Patent concerns will be a major barrier to progress. Arnold Reinhold - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Definitions of Security?
At 4:01 PM +0200 4/14/04, [EMAIL PROTECTED] wrote: Hi, I'm looking for interesting and unusal defitions of the term Security (or secure). I'm fully aware that it is difficult or impossible to give a precise, compact, and universal definitions, and some book authors explicitely say so. However, there are definitions (or attempts to give those), and I'd be interested to compare them. If you know of any definition that might be interesting for any reason, please send me a link or citation. thanx Here is one of mine that is biology inspired: A division of a set of actors into 'self' and 'other' with a mechanism that allows self actors to perform certain activities that are effectively denied to others. Arnold Reinhold - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AES suitable for protecting Top Secret information
I was the one who updated the Wikipedia entry . It was shortly before the cryptography list came back up. I found the June 2003 CNSS fact sheet while looking for other information on NIST's standards program. The first reference that I found that suggested AES could be used for classified was in a slide presentation at a Dec. 4, 2002 NIST Wireless Security workshop http://csrc.nist.gov/wireless by Timothy Havighurst of NSA on DOD Wireless Policy http://csrc.nist.gov/wireless/S04_DOD%20Wireless%20Requirements-th.pdf One slide reads: SECRET and TOP SECRET data must be approved with a Type I algorithm - BATON - AES (sufficient key length) - SKIPJACK (I believe the BATON algorithm itself is still classified.) This is a major milestone in cryptography. I believe it is the first time in modern history that the public knowingly has access to a cipher that the U.S. Government currently considers strong enough for Top Secret information. Note that the CNSS fact sheet goes on to say: The implementation of AES in products intended to protect national security systems and/or information must be reviewed and certified by NSA prior to their acquisition and use. Another interesting presentation at the same NIST workshop was by Bill Burr on NIST's Cryptographic Standards Program. http://csrc.nist.gov/wireless/S04_NIST_crypto_program_final-bb.pdf It has a nice chart comparing the strengths of various crypto primitives based on their key length (page 7). Anther slide (page 13) contains the following interesting statement: Proposed 80-bit crypto end of use date: 2015 Based on the page 7 chart, this presumably includes SHA1, Skipjack, 1024-bit RSA/DSA and 160-bit ECC. Arnold Reinhold At 12:34 PM -0400 4/14/04, Vin McLellan wrote: I missed that announcement too -- but Wikipedia, the web-based Free Encyclopedia, caught it! See Wikipedia on AES at: http://en.wikipedia.org/wiki/AES The Wikipedia module on AES Security has a link to the same NSA fact sheet Steve mentioned. I was surprised. I thought, as in so many other things, the NSA was going to say one thing and do another. Suerte, _Vin At 4/14/2004, Steve Bellovin wrote: I haven't seen this mentioned on the list, so I thought I'd toss it out. According to http://www.nstissc.gov/Assets/pdf/fact%20sheet.pdf , AES is acceptable for protecting Top Secret data. Here's the crucial sentence: The design and strength of all key lengths of the AES algorithm (i.e., 128, 192 and 256) are sufficient to protect classified information up to the SECRET level. TOP SECRET information will require use of either the 192 or 256 key lengths. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: voting
At 8:24 AM -0400 4/8/04, Perry E. Metzger wrote: Trei, Peter [EMAIL PROTECTED] writes: I think Perry has hit it on the head, with the one exception that the voter should never have the receipt in his hand - that opens the way for serial voting fraud. The receipt should be exposed to the voter behind glass, and when he/she presses the 'accept' button, it visibly drops into the sealed, opaque ballot box. Seems fine by me, except I'd make the ballot box only lightly frosted -- enough that you can't read the contents, but light enough that poll inspectors can visually assure themselves that the contents aren't mysteriously altered during the course of the day. I can see one potential problem with having the machine produce the receipts. Let's say the system is well designed and completely fair. There will be a certain percentage of voters who will complain that the receipt recorded the wrong vote because they in fact inadvertently pressed the wrong button. Over time, that percentage and its variance will become well known. Call that rate r.' A party with the ability to make surreptitious changes to the voting software can then have it occasionally record a vote and print a receipt contrary to what the voter chose as long as the number of such bogus votes is small enough relative r and its variance to escape notice. They can then determine what fraction, f, of voters who get wrong receipts report them. They can then increase the fraction of bogus votes by 1/f. Over the course of several elections they can slowly grow the fraction of bogus votes, claiming that voters are getting sloppy. Since major elections are often decided by less than one percent of the vote, this attack can be significant. We have a system now in Cambridge, Massachusetts where we are given a paper mark sense ballot and fill in little ovals, like those on standardized tests. We then carry our ballot to a machine that sucks it in and reads it. The totals are reported after the polls close, but the mark sense ballots are saved inside the machine (which I assume is inspected before the voting starts and then locked) can easily be recounted at any time. This system seems ideal to me. By the way, I should mention that an important part of such a system is the principle that representatives from the candidates on each side get to oversee the entire process, assuring that the ballot boxes start empty and stay untampered with all day, and that no one tampers with the ballots as they're read. The inspectors also serve to assure that the clerks are properly checking who can and can't vote, and can do things like hand-recording the final counts from the readers, providing a check against the totals reported centrally. The adversarial method does wonders for assuring that tampering is difficult at all stages of a voting system. A important thing to remember is that these poll watchers, along with the workers running the voting for the election authorities are often retired people who have very little computer skills. It is much easier for them to understand and safeguard systems based on paper and mechanical locks. Arnold Reinhold - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Mac_crypto] Apple should use SHA! (or stronger) to authenticate software releases
Dobbertin's 1996 collision demonstration is another good reason not to use md5, but is obviously hasn't gotten the open source community or Apple to stop. Whether my attack will be any more successful in effecting change remains to be seen. Publishing SHA1 hashes in parallel with md5 seems like such an inexpensive thing to do, but one should never underestimate cryptographic inertia. For the record, I first published my attack on Perry Metzger's cryptography list in February, 2002. Arnold Reinhold At 5:56 PM -0400 4/4/04, Don Davis wrote: hi, mr. reinhold -- there's stronger reason than the ones you cite, to distrust md5 as a message-digest. see these old sci.crypt threads, and the google-search below, for discussions of hans dobbertin's 1996 crack of md5: http://tinyurl.com/2ox7g http://tinyurl.com/3x446 http://google.com/search?q=dobbertin+md5num=30 btw, in a phone conversation, dobbertin emphasized to me that his attack only works when md5 is used as a message-digest; it doesn't work when md5 is used with a key to prepare a MAC. he also mentioned that while sha-1 may be vulnerable to an attack of a similar style (because sha-1 is similar in struc- ture to md5), he himself was forbiddden by german law to work to cryptanalyze sha-1, because he worked at that time for the german federal security service, and so wasn't allowed to attack the USG's standard ciphers. now he's at ruhr university (in bochum), but i don't know whether he's more of a free agent. - don davis, boston To: [EMAIL PROTECTED] From: Arnold G. Reinhold [EMAIL PROTECTED] Subject: [Mac_crypto] Apple should use SHA! (or stronger) to authenticate software releases Sender: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] List-Id: Macintosh Cryptography mac_crypto.vmeng.com List-Archive: http://www.vmeng.com/pipermail/mac_crypto/ Date: Sun, 4 Apr 2004 06:17:55 -0500 The cryptographic hash function MD5 has long been used to authenticate software packages, particularly in the Linux/Unix/open source community. This has carried over to Apple's OS-X. The MD5 hash of an entire package is calculated and its value is transmitted separately from the package. Users who download the package compute the hash of the copy they received and match that value against the original. ... - 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: [Mac_crypto] Apple should use SHA! (or stronger) to authenticate software releases
At 4:51 PM +0100 4/5/04, Nicko van Someren wrote: ... While I agree that it is somewhat lax of Apple to be using MD5 for checking its updates it's far from clear to me that an attack of the sort described above would ever be practical. The problem is that the while there are methods for finding has collisions by brute force, not only do they require a work factor around the size of the square root of the output space, and a large amount of storage, but the work factor is multiplied by a factor linear in the size of the data that follows the part of the message that you can manipulate. When all you are doing is trying to find a single collision on the hash function (or perhaps trying to forge a matching pair of small key exchange messages) this can be made quite small but when it comes to breaking a package distribution system it is much harder. Consider that the real package is represented by M, the subtly modified version is M1 and the bogus package is represented by M2. Each of these has some high resolution TIFF image T that we can get away with tweaking into T1 and T2. We probably don't have control where this image comes out in the package because the file ordering is deterministic. The file ordering may be deterministic, but someone who is well versed in the configuration control and release engineering process might well be able to have a chosen file placed at the end of of the package. The method for getting stuff at the end needn't be perfect. The attacker can keep trying until he succeeds. The package can be broken down into three parts: the bit before the tweakable part, the tweakable image and the bit after that: M = M1a | T | M1b M1 = M1a | T1 | M1b M2 = M2a | T2 | M2b For the purposes of finding a collision we can pre-compute the hash blocks of M1a and M2a but we can't do the same for M1b and M2b. This means if L(x) is the function for the number of hash blocks in message x then the cost of finding a hash collision in our packages is L(T1|M1b) + L(T2|M2b) times harder than just finding a simple collision by brute force. In MD5 the blocks are 64 bytes, so for every 1K in M1b the process of finding a collision gets 16 times harder. Finding a collision in SHA1 is about 2^16 times harder than finding a collision in MD5, so unless you find something that you can alter without it being noticed in the last 2MB of the package then this sort of forgery is actually going to be harder than finding a simple hash collision in SHA1! In practice you'll probably find something that you can alter in the last few hundred KB but still the raw processing cost will be a few orders of magnitude harder than a simple hash collision problem. Furthermore, since you have to process the tail of the message any specialised hardware for doing this will have a hard time doing it's processing in a usefully pipelined fashion and will need access to large amounts of very fast RAM to store the tail of the message, and this will also cost you another order of magnitude or so. Having a tail 2 MB or longer may make the processing time comparable to finding an SHA1 collision, but it is still a 64-bit problem and thus requires far less memory than finding an SHA1 collision. I am not saying that my attack is easy, but that it is feasible for a large organization and very dangerous and stealthy if it succeeds. History has shown, over and over and over again, the folly of ignoring cryptographic attacks that are theoretically possible but seem too hard to implement. On the other hand, defending against my attack certainly is easy, just publish an SHA1 (or stronger) hash alongside the MD5 hash. Arnold Reinhold - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
I did a Google search on irrebuttable presumption and found a lot of interesting material. One research report on the State of Connecticut web site http://www.cga.state.ct.us/2003/olrdata/ph/rpt/2003-R-0422.htm says: The Connecticut Supreme Court and the U. S. Supreme Court have held that irrebuttable presumptions are unconstitutional when they are not necessarily or universally true and the state has reasonable alternative means of making the determination. The comment appears to apply to statutes and regulations (as opposed to contracts). Still the two tests mentioned seem very appropriate to a discussion of non-repudiation as used in cryptography. In deciding whether the existence of a verified signature should automatically lead to some real world action, we should consider both the adequacy of the technology and the nature of the application. So, for example, the military might adopt an irrebuttable presumption that a cryptographically signed order comes from the registered owner of a cryptographic key, because it has vetted all the technology employed, it can't tolerate delay, and is willing to impose a duty on a key holders to protect their key or suffer the consequences. On the other end of the scale, anti-spam software might accept a signature validated by a public key that is included in a user's white list as conclusive proof that the message should be transmitted to that user because the consequences of doing so with a forged message are so minute. In the case of ordinary consumer transactions, an irrebuttable presumption for public key signatures would not seem to pass muster. There are too many problems with the technology (its not just a question of protecting the private key, but also of insuring the the document actually signed is the one the user thought he was signing) and there are usually other forms of evidence (e.g. delivery records) to substantiate the transaction. This is apparently a very complex area of law. Another paper http://www.law.nyu.edu/clppt/program2003/readings/Franck.doc includes these quotes: Every writer of sufficient intelligence to appreciate the difficulties of the subject matter has approached the topic of presumptions with a sense of hopelessness and left it with a feeling of despair.5 Commenting on the law of presumptions, Judge Learned Hand has commented: Judges have mixed it up until nobody can tell what on earth it means.6 It sounds like the legal profession long ago recognized the difficulties the cryptographic community is now grappling with regard to non-repudiation. We should be very wary of assuming mathematical constructs naturally transform into the legal arena. Arnold Reinhold (who is not a lawyer) 5 Edmund M. Morgan, Presumptions, 12 Wash. L. Rev. 255, 255 (1937). 6 L. Hand, 18 ALI Proceedings 217-18 (1941). At 5:32 PM -0800 1/5/04, Ed Gerck wrote: In business, when repudiation of an act is anticipated we're reminded by Nicholas Bohm (whose clear thinking I know and appreciate for 6 years) that some lawyers find it useful to define irrebuttable presumptions -- a technique known to the law and capable of being instantiated in statute or contract. For example, a legal irrebuttable presumption can take the form of a bank check contract stating that a check (even though it can be *proven* a posteriori to be a forgery) is payable by the bank if the account holder did not notify the bank to repudiate the check *before* the check was presented to the bank for payment. The requirement can be seen an out-of-band signal from the account holder to the bank, which absence makes the check's payability an irrebuttable presumption by the bank. In this case, as long as the check's signature does not look like a (obvious) forgery and there is enough balance in the account, the bank has no liability to that customer in paying the check. Note also that the effectiveness of this method relies on an indirect proof -- the absence of a previous communication makes the check payable. Likewise, in a communication process, when repudiation of an act by a party is anticipated, some system security designers find it useful to define non-repudiation as a service that prevents the effective denial of an act. Thus, lawyers should not squirm when we feel the same need they feel -- to provide for processes that *can be* conclusive. - 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: why penny black etc. are not very useful
At 11:12 AM + 12/31/03, Ben Laurie wrote: Perry E. Metzger wrote: In my opinion, the various hashcash-to-stop-spam style schemes are not very useful, because spammers now routinely use automation to break into vast numbers of home computers and use them to send their spam. They're not paying for CPU time or other resources, so they won't care if it takes more effort to send. No amount of research into interesting methods to force people to spend CPU time to send mail will injure the spammers. If you set the price to 1 minute of CPU, and spammers own 10% of all machines on the 'net, then the average machine can only receive 144 spams per day. That's a significant improvement on my situation. Plus I'd've thought that having 100% CPU utilisation all the time might attract attention. But maybe not. Cheers, Ben. There is something else one can do that might help. The hashcash stamp algorithm can be designed to provide a strong, constant signature to virus detectors. For example, in my HEKS-1 algorithm, I populate a large array with pseudo random words. It would be easy enough to have some fraction (say 1/8th or 1/16th) of those words be a special constant (or one of a few special constants). There would be no way for the spammer to avoid exhibiting the same constants while generating stamps without incurring a severe computational penalty. So any stamp generation activity would be easy to detect. Since the signature would never change, the detection software could be built into the operating system (or even the CPU itself). Legitimate stamp generation would have to be distinguished, perhaps by code signing or some Touring test. A sufficiently clever virus writer with root access might be able commandeer the legitimate stamp generator. If this happens, periodic required updates of the hashcash software can be issued that thwart viruses in the field. Also a large number of countermeasure variants can be generated, making it hard for the virus to recognize them all. This reverses the tactical advantage normally enjoyed by virus writers. Illegitimate stamp generators are forced to present a fixed target while legitimate programs and counter measures can continuously morpf. Arnold Reinhold - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Protection against offline dictionary attack on static files
Jill's approach to key stretching is not quite the same as the
traditional iterated hash. It imposes no cost at encryption time,
you only have to work at decryption. This might be valuable when you
want to save your files as the Gestapo is breaking down your door.
I've been working on a similar method for use as an anti-censorship
tool. Files would be encrypted with a random key and posted on the
Internet. The key size would be selected to require a long time to
crack: hours, days or even weeks. People in countries behind national
Internet filtering could download these files and crack them,
possibly telling friends the recovered key. Censors would have to
expend a lot of effort trying to learn the files that contained
forbidden ideas. It would be inexpensive to create many different
encryptions of the same file and mirror them in multiple locations or
to flood them on Usenet. The URLs of good stuff could be spread by
word of mouth.
Arnold Reinhold
At 2:26 PM -0500 11/12/03, Steve Wang wrote:
Check PKCS #5: http://www.rsasecurity.com/rsalabs/pkcs/pkcs-5/index.html
Steve
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Arcane Jill
Sent: Thursday, October 23, 2003 3:21 AM
To: [EMAIL PROTECTED]
Subject: Protection against offline dictionary attack on static files
Hi,
It's possible I may be reinventing the wheel here, so my apologies if
that's so, but it occurs to me that there's a defence against an offline
dictionary attack on an encrypted file. Here's what I mean: Say you have
a file, and you want to keep it secret. What do you do? Obviously you
either encrypt it directly, or you store it in an encrytped volume
(thereby encrypting it indirectly). Problem? Maybe an attacker can
somehow get hold of the encrypted file or volume ... maybe your laptop
gets stolen maybe other people have access to your machine. In
principle, you're protected by your passphrase, but if an attacker can
get hold of the file, they can try an offline dictionary attack to guess
your passphrase, so unless you're very good at inventing high entropy
passphrases /and remembering them without writing them down/, there may
still be a risk.
Here's the defence:
To encrypt a file:
Generate a random number R between 0 and M-1 (for some fixed M, a
power of 256)
Type in your passphrase P
Let S = R || P (where || stands for concatenation)
Let K = hash(S)
K is now your encryption key. R is to be thrown away.
To decrypt the same file:
Generate a random number r between 0 and M-1
Type in your passphrase P
for (int i=r; ; i=(i+1)%M)
{
Let S = I || P
Let K = hash(S)
Try to decrypt using key K
}
This places a computational burden on your PC at decrypt-time. The
larger you choose M, the more CPU time it will take to figure out K. So,
you choose M such that it takes your PC about one second to find K, then
your attacker will experience the same burden - but multiplied a
squillionfold (a squillion being the entropy of your passphrase). This
means that even if your passphrase consists of just two words from a
dictionary, /and/ your attacker suspects this, it will still take him or
her over a hundred and fifty years to decrypt (assuming your attacker
has a PC of equivalent power). Even if your attacker has a faster PC
than you, it will still be relatively easy to pick a
strong-yet-memorable passphrase, since better tech can only ease the
attacker's problem, not remove it. All of a sudden, weak passphrases
turn into strong ones, and strong passphrases turn into computationally
infeasible ones.
Is this useful?
Has anyone come up with it before? (Someone must have ... but I don't
recall seeing the technique used in applications)
Jill
-
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: quantum hype
At 6:38 PM -0400 9/18/03, John S. Denker wrote: Yes, Mallory can DoS the setup by reading (and thereby trashing) every bit. But Mallory can DoS the setup by chopping out a piece of the cable. The two are equally effective and equally detectable. Chopping is cheaper and easier. Other key-exchange methods such as DH are comparably incapable of solving the DoS problem. So why bring up the issue? It seems to me that because key-exchange methods such as DH only depend on exchanging bits (as opposed to specifying a physical layer), they can rely on a wide variety of techniques to combat DoS. If Bob and Alice can safeguard their local connections to the Internet, its multi-routing properties provide significant DoS protection. Other options available to them include the switched telephone network, wireless, LEO satellites, cybercafes, steganography, HF radio, and even postal mail. In addition, DH users have no need to call attention to themselves by leasing a fiber-optic line. Arnold Reinhold - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PGP Encryption Proves Powerful
At 1:22 PM -0400 5/29/03, Ian Grigg wrote: The following appears to be a bone fide case of a threat model in action against the PGP program. Leaving aside commentary on the pros and cons within this example, there is a desparate lack of real experience in how crypto systems are attacked. IMHO, this leads to some rather poorly chosen engineering decisions that have shown themselves to stymie or halt the success of otherwise good crypto systems. Does anyone know of a repository for real life attacks on crypto systems? Or are we stuck with theoretical and academic threats when building new systems? iang There is a lot of material from the World War II era (e.g Silk and Cyanide by Leo Marks) and the early cold war (e.g. http://www.nsa.gov/docs/venona/). Government cryptographic successes are usually highly classified and kept that way for decades. There was one recent story about the FBI's apparent use of a keyboard logger to get a accused organized criminal's password. The latest U.S. Government wiretap report http://www.uscourts.gov/wiretap02/contents.html (they are now required to report on encryption incidents) says: Encryption was reported to have been encountered in 16 wiretaps terminated in 2002 and in 18 wiretaps terminated in calendar year 2001 or earlier but reported for the first time in 2002; however in none of these case was encryption reported to have prevented law enforcement officials from obtaining the plain text of the communications intercepted. By comparison they reported 1358 intercepts authorized in 2002. Arnold Reinhold - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
