Re: Looking back ten years: Another Cypherpunks failure (fwd)
there is another issue here in the corporate world. The issue is availability of corporate assets. One particular study that showed it up had to do with budiness that had no backup of critical disk and that disk had a failure 50 percent of such occurances resulted in the company declaring bankruptcy within 30 days. The whole migration of critical business assets out of the enterprise glasshouse environment to various corporate desktops has highlighted the fact that more or more critical corporate assets are represented by that data (simple example can be customer invoices billing data). Enterprises that are doing backup of critical data that is shipped off-site as part of disaster/recovery scenarios are starting to find that such backups require encryption (if not the original data stored on disk). The quandrary then is the possible loss of the capability of decrypting the data when necessary (aka replicated keying material stored in multiple safe locations). random ref: http://www.securefs.com/ Secure File System The Secure File System (SFS) is a joint project between the University of Minnesota and StorageTek which aims to provide an easy to use cryptographic file system. It allows you to store your files securely on remote sites using normal networking protocols (FTP, HTTP, NFS, etc.). You can store your files anywhere without worry of unauthorized access. SFS allows distributed control of protected information through the use of a group server which is responsible for all file access controls. SFS currently uses smartcards, through MUSCLE software, for authentication and signature purposes. We are currently using Linux with a patched version of UFO, a user-space program that allows us to treat FTP, HTTP, etc. sites as local filesystems. This patched version allows us to catch any file requests and send them to another program to determine if they need to be de/ encrypted. A diagram of the overall operation is available as a PDF file or GIF. Note: Entire project source code will be available including cryptographic routines. Our revised paper which was submitted to the USENIX Security Symposium is also available in ps and pdf formats. jei [EMAIL PROTECTED] on 1/27/2002 6:27 am wrote: GET #2 is disk encryption. Yes, it sounds so simple, but it is a Great Tabboo, and this time there are no excuses. None. You don't need any network effects. Regulators in the US have little they can do about it. There are about half a dozen great Open Source OSes to work on. And yet there is nothing. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd)
Eugene Leitl [EMAIL PROTECTED] writes: -- Forwarded message -- Date: Sun, 27 Jan 2002 21:10:09 +0100 (CET) From: Robert Harley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Cringely Gives KnowNow Some Unbelievable Free Press... Adam Beberg wrote: I'm preaty sure the reason we're all using RSA _now_ is the same reason we were using DH a couple years ago - the patents are all expired. ECC has a bunch of patents still living, and the word among the crypto crowd I know is still avoid like the plague. I usually have no particular desire to respond to Beberg's negativism, but I suppose that I should do so this time. [Discussion of patents deleted] I see this sort of point-by-point discussion of EC patents a lot. I think it misses the point. If you want to see EC used you need to describe a specific algorithm which has the following three properties: (1) widely agreed to be unencumbered, particularly by the big players. [extra points if you're willing to indemnify] (2) significantly better than RSA (this generally means faster) (3) has seen a significant amount of analysis so that we can have some reasonable confidence it's secure. Until someone does that, the cost of information in choosing an EC algorithm is simply too high to justify replacing RSA in most applications. Mr. Beberg's comment about avoiding ECC like the plague matches my impression of the COMSEC community pretty well. I'm not really part of the crypto community so I can't speak for that. -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypto Winter (Re: Looking back ten years: Another Cypherpunks failure)
the straight-forward mapping of credit card payment to the internet used MOTO business process (mail order/telephone order, aka existing non-face-to-face operation) to handle poorly authenticated transactions. http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 the financial industries standard work on that was basically to provide authenticated transaction using digital signatures to all electronic payment transactions with the requirement given the standards group to preserve the integrity of the financial infrastructure ... aka the x9.59 work applies to credit transactions, debit transactions, ach transactions, gift card transactions, etc. and applicable to all environments (internet, non-internet, point-of-sale, etc) An x9.59 issue is that it removes the requirement for name associated with the transaction. This meets an EU requirement that at the point-of-sale, an electronic transactions should be as anonymous as cash. The claim then is the x9.59 work is privacy neutral aka identification is removed from the transaction. To the extent there is any identification involved it is in mapping individuals to accounts. Gift cards don't have mapping of individuals to accounts ... and x9.59 would neither increase nor decrease the annonymity of gift cards. Gift cards are typically procssed with the some point-of-sale terminal as existing debit/credit cards and at least initially typically flow thru the same network. That means that the current webserver based use of credit cards flows into the same network that debit and gift cards flows into. The issue isn't the mechanics of enabling debit and gift cards for internet webserver use the issue is providing authentication in an open insecure network (the internet) compared to closed/secure network that the point-of-sale terminals directly connect into. X9.59 is defined to provide such authentication in a secure manner across all payment transactions. With respect to credit /or debit accounts, again X9.59 neither increases nor decreases the annonymity of those accounts; to the degree that particular institutions allow annonymity associated with such accounts ... x9.59 then is privacy neutral in the protocol. so the issue here is that the bits and pieces of privacy-enhanced payment transactions already exists and has for some time. a new one doesn't really need to be invented; the basic issue is really the technology needed to transission some of these existing privacy-enhanced payment transactions from closed network to an open network environment. misc. refs: http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/subtopic.html#privacy [EMAIL PROTECTED] on 1/27/2002 12:08 pm forwarded: On Saturday, January 26, 2002, at 09:55 PM, Dr. Evil wrote: We know that some kind of privacy-enhanced payment system has been one of the long-time c'punk goals, probably for at least ten years. We know that we are probably further away from having that be a reality than we were ten years ago. This is excusable; the obstacles are enormous. You need a lot of people to use it before it's useful, and there are all kinds of regulatory problems. And there are a whole list of other problems, too. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: biometrics
On Sat, 26 Jan 2002, [EMAIL PROTECTED] wrote: At 05:46 PM 1/26/02 -0500, P.J. Ponder wrote: . . . . Without think about it some more, I don't know whether to place the entire notion of security controls based on biometric telemetry in with _pure_ bullshit like copy protection, watermarking, non-repudiation, tamper proofing, or trusted third parties. Admittedly, there is a lot of bullshit in the idea, I'm just not sure it is pure. If you think about it, it's actually a succinct way of categorizing different ways that someone can authenticate themselves. You seem to imply that the only nonbullshit way to do that is a) something you know. I'd say that's been shown to be a pretty weak authentication method when relied on solely. There isn't anything generally wrong with hardware devices or something that 'one has'. Tokens and the like can be cost effective in many applications. I'm working with some folks right now that are looking at hardware dongle-type things for a particular security application. Little hardware gizmos will probably turn out to be a good fit for what they are doing. Nothing wrong with that. People often use password systems poorly, and many password systems permit poor and sloppy use. Still passwords and passphrases can be used effectively. I think the need for maintaining control over the biometric telemetry equipment makes it suitable for a rather narrow range of applications. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Shares of RSA Security Plunge On News of SEC Investigation
http://online.wsj.com/article_print/0,4287,SB10119952661000,00.html January 25, 2002 Shares of RSA Security Plunge On News of SEC Investigation CEO Says He Doesn't Expect Any Restatement of Financials By WILLIAM M. BULKELEY Staff Reporter of THE WALL STREET JOURNAL COMPANIES Dow Jones, Reuters RSA Security Inc. (RSAS) PRICE CHANGE U.S. dollars11.86 -4.78 1/25 * At Market Close RSA Security Inc. shares plunged Friday, after the provider of network-security products and data-encryption software disclosed it is the target of a Securities and Exchange Commission investigation. Shares of RSA fell $4.78, or 29%, to $11.86 in 4 p.m. trading on the Nasdaq Stock Market. Arthur Coviello, chief executive officer of RSA, said in an interview that the company doesn't anticipate any requirement to restate financials as a result of the Securities and Exchange Commission inquiry. Mr. Coviello said that the SEC investigation involves a question of whether it should have disclosed in a press release certain information about changes in estimates for shipment to distributors. RSA limited the disclosure to a regulatory filing last spring after the first quarter. Mr. Coviello said the SEC is also looking at certain issues about trading in RSA's stock. He said he doesn't know the details of the investigation, but We don't believe the company has anything to do with these other trading issues. He cautioned that I don't really have all the facts at my disposal, but he said, We absolutely believe there's no wrongdoing. He added, that RSA management is cooperating fully with the SEC. Later Friday, the company issued a statement (see statement0) saying that the investigation wouldn't require any change to RSA's financial statements. Mr. Coviello said that the amount involved in the accounting treatment was about $3 million, which is less than 2% of RSA's 2001 revenue of $283 million. A spokeswoman said that RSA hadn't mentioned the SEC investigation in the press release about earnings Thursday on advice of counsel. Mr. Coviello added that he hadn't seen any SEC notification but had heard about it from counsel. Write to William M. Bulkeley at [EMAIL PROTECTED] RSA Statement RSA Security Issues Clarification on SEC Investigation BEDFORD, Mass., Jan. 25 -- RSA Security Inc. today reported that the Securities and Exchange Commission has commenced a formal investigation into certain matters relating to the company. The SEC's investigative order relates to whether a change in RSA Security's method for estimating distributor revenue disclosed in its Quarterly Report on Form 10-Q for the first quarter of 2001 should have been disclosed in its earnings press release a few weeks earlier, as well as to certain trading in the company's securities. The investigation will not require any change to RSA Security's financial statements. The SEC has not concluded that there has been any wrongdoing, and we don't believe that there has been any, said Art Coviello, CEO and president at RSA Security. We are cooperating fully with the SEC on this matter. URL for this article: http://online.wsj.com/article/0,,SB10119952661000.djm,00.html Hyperlinks in this Article: (1) mailto:[EMAIL PROTECTED] Updated January 25, 2002 5:47 p.m. EST Copyright 2002 Dow Jones Company, Inc. All Rights Reserved Printing, distribution, and use of this material is governed by your Subscription agreement and Copyright laws. For information about subscribing go to http://www.wsj.com -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Attacks using Pure Text (Was: Re: Results, not Resolutions)
At 10:17 PM 01/26/2002 -0800, Bill Frantz wrote: At 7:42 PM -0800 1/25/02, R. A. Hettinga quoted Schneier and Shostack: Here's one example: Originally, e-mail was text only, and e-mail viruses were impossible. ... Well, the line between code and data is fuzzier than that. That 7 bit ASCII email is properly thought of as a series of instructions for a text rendering engine which is implemented in software on modern machines. If there is a bug in that rendering software, then it may be possible to design a sequence of text which executes arbitrary code on the receiving machine. Email viruses were not impossible with text-only email. ASCII text is probably much safer today than it was 20 years ago, because there are far more systems that try to render it, and almost all of them do less interpretation than they did back then, when we usually read email on dumb terminals, preferably the smartest dumb terminals we could find. Before everything standardized on ANSI, lots of terminals, particularly the HP 262x series and the DEC VT100s, had features that would let you hand escape sequences to the terminal that would not only change fonts, move the cursor, clear the screen, etc., but could also program function keys and execute function keys. So it was possible to send somebody email that would cause their terminal to transmit a limited number of characters to the computer as if the user had typed them, which opened a variety of security holes. Also, one of the talk programs would write directly to another user's terminal if the permissions were set to the default world-writable. There was an article in the SF Chron or Oakland Trib in spring 1979 saying that hackers at Berkeley had broken the security of the Unix, a computer made by DEC, which was really about one of these escape-sequence exploits, probably for VT100s. It was tough to do much, but if you guessed what mail reader the person was using, you could fake keystrokes for exit mail, run something dangerous, especially if you first sent the victim a file using UUCP. I don't think anybody built a virus this way, since we weren't really virus-aware at the time, but some people probably sent password-stealers this way. And it was easy to do a shut down or hose up the victim's terminal attack. Unfortunately, the escape sequence for bold-face on one popular terminal would hose up another popular terminal, so it wasn't always deliberate - there were often flames on Usenet about people posting formatted articles (commonly recipes on rec.cooking) with dangerous escape sequences in them. A much cruder denial-of-service attack was to send +++ or other modem-control characters, which could disconnect a Hayes-style modem. These days, almost all of the terminal emulation programs either just run totally dumb text, or run some subset implementation of ANSI or the very similar DEC VT100, and most of those emulators haven't bothered implementing the fancier features. Another text-only attack was magic sequences for text editors like vi (and perhaps emacs?) which would look for option-setting commands in the beginning or end lines of files. The purpose was to allow comments in C code that would turn on C-related editor options, comments in Lisp code that would turn on lisp-related options, etc. This was eventually realized to be a security risk, so nomodelines became the default in vi. Of course, the most successful text-only attack was the Good Times virus, which worked by infecting the wetware of the operator :-) There is really no substitute for limiting the authority of code which processes potentially hostile input, such as email and web pages, so that the consequences of flaws are limited. One way to limit authority in current systems is to use an operating system that provides a measure of real security between users, and then have an account which is only used for email, web surfing etc. Yup. Designing code for hostile and bogus input was about the third lesson in CS100, after Comment everything and The One True Indent Style, and well before anything fancier than arrays and loops. But enough code doesn't do that that it's important to use operating system protections as well. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A risk with using MD5 for software package fingerprinting
A small PS to my last message. In 1978 I was lent an Apple II running the ABBS software (Apple Bulletin Board System), and it ran in a corner of my bedroom for some years as the PCnet ABBS in San Francisco. This was a machine with an 8-bit 1 MHz processor, 48K of RAM, and a custom floppy that held maybe 100 or 200K bytes; no hard drive. It did email for a regular community of dozens of users, and hundreds of assorted visitors, on a single 300-baud phone line. While getting the PCnet (uucp-like packet-switching and email transfer) software running on this beast, I also improved the ABBS software, which was written in Applesoft (Microsoft) BASIC and thus came with its own source code. One day I found a very interesting line in that code. It went something like this: 18520 if (%K.eq.%U5) goto 3700 You needed a lot of context to understand that this was a backdoor in the ABBS software. It compared K, the message number that the caller had just asked the BBS to delete, with the machine address of an I/O port U5 that the BBS used to talk to the modem or something. If the message number and the I/O address matched, it would jump into another bit of BASIC code at line 3700, which was where it handled commands for the local Apple operator of the BBS, including what is now called shell access. So asking the ABBS to delete message number 32547 or so would give you operator privileges. This obscure line among thousands, placed just so, could do that. This is why only someone who actually understands the code at a deep level is likely to find back doors like this. I deleted that line, and put out an alert to other ABBS users that the author of the ABBS software had inserted a back-door in it. I think that was the only deliberately build backdoor I've ever found in a piece of software or hardware. (Well, not counting NSA's designs for cellular phone encryption algorithms, key exchange protocols, and the Clipper chip. Or the weakening of DES in the first place.) (All the variable names and line numbers in this story have been changed to protect the innocent -- and to avoid me having to try to dig out probably nonexistent printouts of that software. But if you have the ABBS BASIC source, look in the 'K' (kill message) command section.) John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RSA Security shares take a hit on SEC probe
http://news.ft.com/ft/gx.cgi/ftc?pagename=Viewc=Articlecid=FT3ISGYEZWClive=truetagid=IXLI0L9Z1BC RSA Security shares take a hit on SEC probe By Paul Abrahams in San Francisco Published: January 27 2002 22:05 | Last Updated: January 27 2002 23:59 Shares in RSA Security tumbled 28 per cent on Friday after the company revealed that the Securities and Exchange Commission had launched an investigation into the group's apparent failure to disclose changes in the e-security company's accounting practices, as well as certain trades in the company's securities. Art Coviello, chief executive and president said he did not believe there had been any wrong-doing at the group and that the Massachusetts-based company was cooperating fully with the investigation. Shares closed at $11.86. However, after the market closed, the group put out a statement saying the investigation would not require any change to its financial statements. That helped the shares climb 5.4 per cent in after-hours trading to $12.50. The collapse of Enron, the power trading group which is the subject of federal investigation, has made investors hyper-sensitive to accounting issues. The SEC is looking into whether a change in RSA's method of estimating distributor revenue should have been disclosed earlier in a press release rather than being buried in a footnote in its first-quarter results last year. At that time, the company said it had begun recognising revenues when they shipped products to customers rather than when it received evidence of sales to end-users. On Thursday, the company announced its fourth-quarter results, and in a conference call, it told analysts that the change in accounting procedures had added $3m in revenues. In 2001, the group generated sales of $282.6m, an increase of 0.9 per cent. Without the change, revenues would have fallen, year on year. Links referenced within this article Find this article at: http://news.ft.com/ft/gx.cgi/ftc?pagename=Viewc=Articlecid=FT3ISGYEZWClive=truetagid=IXLI0L9Z1BC -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A risk with using MD5 for software package fingerprinting
At 02:27 AM 1/28/02 -0800, John Gilmore wrote: I have done enough years of chip testing AND architectural validation to know how few of the infinitely many combinations of instructions or bus cycles are actually tested to make sure that somebody didn't intentionally make *one* combination do something interesting. Even if you trust your processor, didn't the NSA pay the Taiwanese designer of your RAM chips to replace particular stored code sequences with other interesting ones, one time out of a hundred, when fetched? Nice piece. When I was writing Verilog for Blowfish and IDEA, we got interested in how to verify that the chip did what the code described. Esp. because you hand over your output to other internal groups who transform it into other forms (e.g., standard cell netlist, then GDSII masks, etc.) We were thinking about using reverse-engineering services who could strip, image, and reconstruct a netlist, to confirm that the logic did what it was supposed to (and in our case, nothing else). The equivalent of reverse-compiling from assembler --or microcode! We never got that far, though. dh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: biometrics
P.J. Ponder wrote: Without think about it some more, I don't know whether to place the entire notion of security controls based on biometric telemetry in with _pure_ bullshit like copy protection, watermarking, non-repudiation, tamper proofing, or trusted third parties. Admittedly, there is a lot of bullshit in the idea, I'm just not sure it is pure. Why are trusted third parties pure bullshit? Surely there are circumstances where a third party really can be trusted? Or are you talking about the tainted meaning of TTPs (i.e. spooks that hold your private keys)? 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]
Re: A risk with using MD5 for software package fingerprinting
David Honig wrote: At 12:07 PM 1/27/02 -0500, Arnold G. Reinhold wrote: if an attacker had an agent working inside the organization that produced the package, the agent could simply insert the Trojan software patch in the original package. However such an insertion is very risky. A sophisticated software company would likely have code reviews that would make introduction of the Trojan code difficult. Um, right. A good company would have *design* reviews, but would it really spend time having skilled engineers review *all* the actual codelines One of the duties of a person with commit access to an Apache Software Foundation project is, indeed, to review _all_ commits to that package. Admittedly any particular individual will sometimes only glance at the commit, but bugs are picked up at this stage with such regularity that I am confident that the vast majority of commits are, in fact, reviewed. I believe this practice is pretty common in free software. Oh, I should note that commits are emailed to all committers, so it does not require the committers to actively seek out commits to review. 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]
Re: biometrics
And what happens when I am unable to press my thumb against the reader because it is bandaged; or when my thumb ID fails because it was sliced with a knife. lets say you are replacing pin'ed magstripe card with a chip card needing biometric ... say fingerprint (in place of a PIN) along with chip (in place of magstripe). there are two issues 1) effort to compromise the biometric is still significantly more difficult that a normal 4-digit pin and 2) there seems to be a large population that writes their 4-digit pin number on their card (as well as numerous tricks of capturing the PIN). Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and [EMAIL PROTECTED]OpenSSL. Interfaces with OpenSSH - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [linux-elitists] Re: Looking back ten years: Another Cypherpunksfailure (fwd)
There are other problems with using IPsec for VoIP.. In many cases you are sending a large number of rather small packets of data. In this case, the extra overhead of ESP can potentially double the size of your data. In certain cases (such as cablemodem networks) this implies that using IPsec effectively halves the number of active VoIP sessions that a carrier can handle. Enzo Michelangeli [EMAIL PROTECTED] writes: If everything is tunnelled inside SSH, its ultimate transport is TCP, which is bad for data types like voice where reliability is less important than low delay. The right thing to do is to build decent security into the RTP layer (the standard transport for voice applications, RFC1889): the SRTP draft (http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-02.txt) goes in this direction. Authentication and key exchange are supposed to be handled in the session initiation phase (e.g., through SIP or H.323). Alternatively, one could rely on IPSEC, but its support on the target machine cannot (yet?) be taken for granted; the RTP stack, on the opposite, is usually built into the application rather than the kernel. Enzo -- Derek Atkins, Computer and Internet Security Consultant IHTFP Consulting (www.ihtfp.com) [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: biometrics
On Sun, 2002-01-27 at 14:07, [EMAIL PROTECTED] wrote: The issue then is that biometric represents a particularly difficult shared-secret that doesn't have to be memorized Shared secret? People don't leave a copy of their PIN on every water glass they use. -- sidney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: biometrics
X9.84 biometric standard some other work means that you could actually record all ten fingers in the card and any one would be acceptable. I believe just plain dirty fingers are much more of a problem than a cut. Simple cut can be read-around ... massive cut affecting the whole finger is problem. unless you are talking about blood contamination if band-aid is involved which would have to be removed. What happens when a person forgets their pin (password) (one of the most common customer call center calls ... and represents a significant percentage of total customer call center costs when pin/password support is involved)? One of the reasons that suprising percentage of cards have PINs written on them (and postits with passwords are found near PCs). What happens when person doesn't have any fingers? You can still support pin-pad in parallel ... assuming that pin-pad is acceptable to people w/o any fingers. Next level gets somewhat more expensive ... having pin-pad, finger reader, and say iris scan (recording all ten fingers and both iris (lots of work that not only are all iris unique, even identical twins ... but left right in same person are unique, iris is also possible in most blind people), plus finger-length scan. And what happens when I am unable to press my thumb against the reader because it is bandaged; or when my thumb ID fails because it was sliced with a knife. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Fingerprints (was: Re: biometrics)
Last week I had to go to my local INS office to get fingerprinted (part of the green card process is getting your fingerprints OK'ed by the FBI (and also presumably stored for future reference)). The process is computerised, with a low-res scan of all the fingers taken once, and then each finger is individually rolled and scanned on a much higher resolution scanner. The process took about 20-30 minutes; each finger had to be wiped with some cleaning fluid, the glass on top of the scanner also had to be wiped between scans, and a fingerprinting technician had to roll each of my fingers with the right amount of pressure to get a clear image of the fingerprint. Even with immediate feedback on a large screen showing the fingerprint and how good the scan was, some fingers took as many as five tries to get an acceptable fingerprint. Now, this was a special-built device whose only purpose is to scan fingerprints, operated under ideal conditions by a trained technician. Draw your own conclusions about the effectiveness of mass-produced fingerprint scanners that would be integrated in other devices. /ji -- /\ ASCII ribbon | John JI Ioannidis * Secure Systems Research Department \/campaign| ATT Labs - Research * Florham Park, NJ 07932 * USA /\against | Intellectuals trying to out-intellectual / \ HTML email. | other intellectuals (Fritz the Cat) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: biometrics
again, the issue is cost/benefit trade-off. The current implementation of pin/magstripe allows evesdropping other techniques to efficiently electronically collect everything need across a potentially extremely large number of different accounts sufficient to perform multiple fraudulent transactions against each one of them. In the card/biometric example sited the water glass example is a total red herring. the card has to be first stolen in order to perform a fraudulent transaction. The claim is that it is more difficult expensive to fake a biometric lifted off the card than it is to fake a pin written on the card (aka it is much more likely a fingerprint of interest can be lifted from the stolen card). This is much more of a exploit than the water glass red herring so the counter is how to make it more difficult that a fingerprint lifted from the card could result in a fraudulent transaction. Sidney Markowitz [EMAIL PROTECTED] To: Cryptography Mailing List Sent by:[EMAIL PROTECTED] owner-cryptography@wasabis cc: ystems.com Subject: Re: biometrics 01/28/2002 10:47 AM On Sun, 2002-01-27 at 14:07, [EMAIL PROTECTED] wrote: The issue then is that biometric represents a particularly difficult shared-secret that doesn't have to be memorized Shared secret? People don't leave a copy of their PIN on every water glass they use. -- sidney - 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: Fingerprints (was: Re: biometrics)
I believe NIST published something about FBI needing 40 minutia standard for registration in their database. On tv you see these things about lifting partial prints and then sending them off to FBI to try and find who the partial print matches with, aka the FBI better have rather detailed recording of whatever part of the print that happened to be lifted. That is significantly different than trying to repeat scans in the same way, on nearly identical surface, from the same angle, of a full print etc. and approx. match at least a minimum number of points. By comparison, the fbi might need to have higher number of point match based on only a very specific subarea. That would imply that the needed resolution of valid points on the minimum acceptable sized subarea equivalent to typical matching of a full fingerprint. lets say that FBI wants to do acceptable minutia match on a 15 percent finger subarea (pure conjecture on my part, i've never even read anything about minimum resolution needed in partial print search) ... then presumably the (fbi's) total finger resolution (recording) might need to be six times higher than a straight-foward comparison involving always matching a full-finger to the same full-finger recording using essentially the same methodology each time. Even at that, the straight-forward fingerprint match (as opposed to the partial print search problem) is frequently subject to greasy dirty finger problems. [EMAIL PROTECTED] at 1/28/2002 1:46 pm wrote: Last week I had to go to my local INS office to get fingerprinted (part of the green card process is getting your fingerprints OK'ed by the FBI (and also presumably stored for future reference)). The process is computerised, with a low-res scan of all the fingers taken once, and then each finger is individually rolled and scanned on a much higher resolution scanner. The process took about 20-30 minutes; each finger had to be wiped with some cleaning fluid, the glass on top of the scanner also had to be wiped between scans, and a fingerprinting technician had to roll each of my fingers with the right amount of pressure to get a clear image of the fingerprint. Even with immediate feedback on a large screen showing the fingerprint and how good the scan was, some fingers took as many as five tries to get an acceptable fingerprint. Now, this was a special-built device whose only purpose is to scan fingerprints, operated under ideal conditions by a trained technician. Draw your own conclusions about the effectiveness of mass-produced fingerprint scanners that would be integrated in other devices. /ji -- /\ ASCII ribbon | John JI Ioannidis * Secure Systems Research Department \/campaign| ATT Labs - Research * Florham Park, NJ 07932 * USA /\against | Intellectuals trying to out-intellectual / \ HTML email. | other intellectuals (Fritz the Cat) - 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: Fingerprints (was: Re: biometrics)
JI, Keep in mind that this is the _creation_ of the database entry. Yes, you want the data in the database to be as completely accurate as possible. Later, when they only have partial prints, they can perform a lookups of partial data using the complete database. I think the same would be true of mass-produced fingerprint scanners. So long as the backend-database has a full, complete data set, a partial read on the verification step can still match. The question is: what would be the rate of false-positive (or false-negative) readings? -derek [EMAIL PROTECTED] writes: Last week I had to go to my local INS office to get fingerprinted (part of the green card process is getting your fingerprints OK'ed by the FBI (and also presumably stored for future reference)). The process is computerised, with a low-res scan of all the fingers taken once, and then each finger is individually rolled and scanned on a much higher resolution scanner. The process took about 20-30 minutes; each finger had to be wiped with some cleaning fluid, the glass on top of the scanner also had to be wiped between scans, and a fingerprinting technician had to roll each of my fingers with the right amount of pressure to get a clear image of the fingerprint. Even with immediate feedback on a large screen showing the fingerprint and how good the scan was, some fingers took as many as five tries to get an acceptable fingerprint. Now, this was a special-built device whose only purpose is to scan fingerprints, operated under ideal conditions by a trained technician. Draw your own conclusions about the effectiveness of mass-produced fingerprint scanners that would be integrated in other devices. /ji -- /\ ASCII ribbon | John JI Ioannidis * Secure Systems Research Department \/campaign| ATT Labs - Research * Florham Park, NJ 07932 * USA /\against | Intellectuals trying to out-intellectual / \ HTML email. | other intellectuals (Fritz the Cat) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Derek Atkins, Internet and Computer Security Consultant IHTFP Consulting (www.ihtfp.com) [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [linux-elitists] Re: Looking back ten years: AnotherCypherpunksfailure (fwd)
There are other problems with using IPsec for VoIP.. In many cases you are sending a large number of rather small packets of data. In this case, the extra overhead of ESP can potentially double the size of your data. HOW small? You'd already be adding IP+UDP+RTP headers (20 [or 40] + 8 + 12 = 40 [or 60] bytes). Using ESP with authentication would add another 22, plus possible explicit IV and padding, if needed -- call it 30? 20ms of uncompressed telephone quality data is 160 bytes ... - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [linux-elitists] Re: Looking back ten years: Another Cypherpunksfailure (fwd)
Matt Crawford [EMAIL PROTECTED] writes: There are other problems with using IPsec for VoIP.. In many cases you are sending a large number of rather small packets of data. In this case, the extra overhead of ESP can potentially double the size of your data. HOW small? You'd already be adding IP+UDP+RTP headers (20 [or 40] + 8 + 12 = 40 [or 60] bytes). Using ESP with authentication would add another 22, plus possible explicit IV and padding, if needed -- call it 30? 20ms of uncompressed telephone quality data is 160 bytes ... 8-bit u-law (standard telephone quality) is 56kb/sec. 20ms at that rate is 140 bits (I guess you assumed 64kb/sec to get 160 bits?). However, many audio codecs in common use (e.g. G7.11) output a bit-rate much smaller than 8-bit u-law, to the point were we're really talking about 20-30 bytes of data for that same 20ms of audio. Yes, we're talking 8-12kb/sec codecs. This means that in order to send 20 bytes of data you're already adding 60 bytes (or a factor-of-three increase), not to mention the extra 22 (or more) for ESP. The other thing to keep in mind is that IP+UDP+RTP can be compressed using standard header-compression techniques, which pretty much eliminates most of that extra overhead. So, maybe your factor-of-three increase that we're seeing above is now reduced to a factor-of-one increase. The problem is that if you use ESP then your UDP and RTP headers are now encrypted within the ESP, thereby destroying your chance for any kind of header compression. -derek -- Derek Atkins, Computer and Internet Security Consultant IHTFP Consulting (www.ihtfp.com) [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: biometrics
The essential problem I've always seen with biometrics (and one that Dorothy Denning acknowledged in her recent op ed piece without seriously examining) is the question of whether it's as efficient to deploy and manage biometrics safely as it is to deploy and manage some keyed alternative like smart cards or other tokens. Once you start embedding crypto secrets into your biometric reader, you are no longer managing biometrics. You're now managing BOTH biometrics AND a bunch of crypto keys. Why not just save yourself the administrative headache, deploy tokens, and use that crypto key for authentication? I'm sure there are applications where biometrics make sense (ATMs, door security, and other closed systems like that) but I just don't see them working in an open system where your main problem is to associate the endpoint with a person. If you also need to separately authenticate the endpoint, and that's what everyone recommends, then the system costs go up even more. My favorite biometric implementation is the fingerprint as PIN token, which several vendors make. There's the Sony Puppy, a credit card calculator sized token with a USB cord and an embedded public key pair. There are also various PCMCIA readers that (apparently) you can plug in to your laptop to provide a biometric lock. My impression, however, is that these readers provide a PIN-like resistance to attack. Once you've cranked the false rejections down to the point that it's convenient, the false positives are approaching PIN levels (2^13 guesses on average). A nice feature of the fingerprint as PIN tokens is, of course, that the print never leaves the card. You still have to worry about images of fingerprints or rubber fingers, of course. The print is a back-up for physical possession. Rick. [EMAIL PROTECTED]roseville, minnesota Authentication in bookstores http://www.visi.com/crypto/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fingerprints (was: Re: biometrics)
At 02:46 PM 1/28/2002, [EMAIL PROTECTED] wrote: The process took about 20-30 minutes; Have you been fingerprinted before? Did it take that long in that case? In my own experience, it only takes a few minutes to be fingerprinted on a standard card and, in theory, they should be able to build a database from high-res fingerprint card images. Some small percentage of the population has prints that are unusually hard to read. It might be time consuming to put such a person's prints onto a card. Or perhaps it takes 20 minutes of ablutions and purifications to copy a fingerprint card, so they figure they might as well make the subject wait, too. Rick. [EMAIL PROTECTED]roseville, minnesota Authentication in bookstores http://www.visi.com/crypto/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fingerprints (was: Re: biometrics)
On Mon, Jan 28, 2002 at 02:54:57PM -0700, [EMAIL PROTECTED] wrote: I believe NIST published something about FBI needing 40 minutia standard for registration in their database. [reasons why the FBI wants so many minutae deleted] As an example of the real world, a couple years ago I put together a working demo of a smartcard authenticated by a fingerprint (the card then went on to participate in SET). The pre-release fingerprint chip I used would regularly grab about 20 minutae, more like 10 on a bad scan (dirty finger, poor position, etc). If you set the macthing parameters to require all minutae to match, you'd get a positive (i.e. match all minutae) on about one in ten scans. And of course the other reason for wanting such good prints is simply that the FBI can demand them. Eric - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fingerprints (was: Re: biometrics)
There is some interesting information at http://www.finger-scan.com/ They make the point that finger scanning differs from finger printing in that what is stored is a set of recognition parameters much smaller than a complete fingerprint image. So there is no need for a lengthily process to acquire an initial image. Presumably this also makes finger scan data proprietary, since each vendor will use a different recognition algorithm. Finger Scan also has a page on accuracy where they debunk other vendors' claims of 0.01% false reject/ 0.001% false accept, but tell you to e-mail them for the real numbers. Arnold Reinhold At 5:07 PM -0600 1/28/02, Rick Smith at Secure Computing wrote: At 02:46 PM 1/28/2002, [EMAIL PROTECTED] wrote: The process took about 20-30 minutes; Have you been fingerprinted before? Did it take that long in that case? In my own experience, it only takes a few minutes to be fingerprinted on a standard card and, in theory, they should be able to build a database from high-res fingerprint card images. Some small percentage of the population has prints that are unusually hard to read. It might be time consuming to put such a person's prints onto a card. Or perhaps it takes 20 minutes of ablutions and purifications to copy a fingerprint card, so they figure they might as well make the subject wait, too. Rick. [EMAIL PROTECTED]roseville, minnesota Authentication in bookstores http://www.visi.com/crypto/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd)
- Original Message - From: Eric Rescorla [EMAIL PROTECTED] To: Eugene Leitl [EMAIL PROTECTED] Sent: Monday, 28 January, 2002 6:33 AM [...] If you want to see EC used you need to describe a specific algorithm which has the following three properties: (1) widely agreed to be unencumbered, particularly by the big players. [extra points if you're willing to indemnify] (2) significantly better than RSA (this generally means faster) (3) has seen a significant amount of analysis so that we can have some reasonable confidence it's secure. Until someone does that, the cost of information in choosing an EC algorithm is simply too high to justify replacing RSA in most applications. Well, a nice characteristic that RSA doesn't have is the ability of using as secret key a hash of the passphrase, which avoids the need of a secret keyring and the relative vulnerability to dictionary attacks. See e.g. the Pegwit application, which, in its version 9 (http://groups.yahoo.com/group/pegwit/) does not, AFAIK, infringe on any EC patent. Enzo - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cringely Gives KnowNow Some Unbelievable Free Press... (fwd)
Enzo Michelangeli [EMAIL PROTECTED] writes: - Original Message - From: Eric Rescorla [EMAIL PROTECTED] To: Eugene Leitl [EMAIL PROTECTED] Sent: Monday, 28 January, 2002 6:33 AM [...] If you want to see EC used you need to describe a specific algorithm which has the following three properties: (1) widely agreed to be unencumbered, particularly by the big players. [extra points if you're willing to indemnify] (2) significantly better than RSA (this generally means faster) (3) has seen a significant amount of analysis so that we can have some reasonable confidence it's secure. Until someone does that, the cost of information in choosing an EC algorithm is simply too high to justify replacing RSA in most applications. Well, a nice characteristic that RSA doesn't have is the ability of using as secret key a hash of the passphrase, which avoids the need of a secret keyring and the relative vulnerability to dictionary attacks. See e.g. the Pegwit application, which, in its version 9 I don't know exactly what Pegwit does, but most of these schemes are still vulnerable to dictionary attacks by trying arbitrary passphrases and seeing if they generate the correct public key. It's of course slower since the test operation is slower. And of course you can do the same sort of thing with RSA by using the passphrase as the seed for the PRNG. This is quite practical on modern machines where RSA key generation is extremely fast. (And practical even on slow machines if you use Schiller's trick of remembering a hint). -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
