Re: Lack of fraud reporting paths considered harmful.
John Ioannidis wrote: Perry E. Metzger wrote: That's not practical. If you're a large online merchant, and your automated systems are picking up lots of fraud, you want an automated system for reporting it. Having a team of people on the phone 24x7 talking to your acquirer and reading them credit card numbers over the phone, and then expecting the acquirer to do something with them when they don't have an automated system either, is just not reasonable. But how can the issuer know that the merchant's fraud detection systems work, for any value of work? This could just become one more avenue for denial of service, where a hacked online merchant suddenly reports millions of cards as compromised. I'm sure there is some interesting work to be done here. There is an interesting analogue in the area of SAR (suspicious activity report) filings through financial services. This has been in place with various providers for maybe a decade or so. I'm not aware of any serious economic analysis that would suggest copying the lessons, though. There is a philosophical problem with suggesting an automated protocol method for reporting fraud, in that one might be better off ... fixing the underlying fraud. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: German Government Skype interception methods leaked...
At 10:24 -0500 26.01.2008, Perry E. Metzger wrote: Wikileaks has released documents from the German police revealing Skype interception technology. The leaks are currently creating a storm in the German press[...] I've skimmed some of the coverage and I can't help but think that this is being hyped in large part because Skype is mentioned. What's being described seems to require running DigiTask's code on an endpoint. If you're installed on the machine anyway, rather than grabbing packets on the wire, all you'd need to do is get the data -- eg by inserting yourself into standard OS audio and HID APIs -- before Skype's code processes it. Such an approach would never have to deal with encrypted bits, and really has nothing to do with Skype at all. NB also that unless they've implemented specific countermeasures in the mean time, Skype remains vulnerable to traffic analysis, cf. http://arstechnica.com/news.ars/post/20060824-7582.html. s. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Lack of fraud reporting paths considered harmful.
Perry E. Metzger wrote: This evening, a friend of mine who shall remain nameless who works for a large company that regularly processes customer credit card payments informed me of an interesting fact. His firm routinely discovers attempted credit card fraud. However, since there is no way for them to report attempted fraud to the credit card network (the protocol literally does not allow for it), all they can do is refuse the transaction -- they literally have no mechanism to let the issuing bank know that the card number was likely stolen. This seems profoundly bad. I hope that someone on the list has the right contacts to get the right people to do something about this. some chance they are doing this to save money on transactions that aren't likely to be approved ... i.e. rather than be charged for a transaction that they send thru to the issuer that they are sure to be rejected ... they reject it upfront. now the associations have standard procedure to perform stand-in when the network accepts a transaction from an acquirer but isn't able to forward it to the issuer. stand-in allows the network to decide whether to approve or reject the transaction using simplified rules. later, when contact is re-established with the issuer ... the issuer has to be informed of all the stand-in activity. a possible simplified mechanism is to be able to generate a simulated stand-in report of rejected transactions. the issue then in such a simulated stand-in role ... for all the reasons that they chose to reject a transaction ... do they map into the standard iso 8583 codes for reasons that the issuer would reject the transaction. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
malware in digital photo frames infects users computers
Great. What next? I guess air-gap transfer of flash memory might be the best solution. Malware's new infection route: photo frames http://www.sfgate.com/cgi-bin/article.cgi?file=/c/a/2008/01/26/MNE7UHOOQ.DTL - Alex -- Alex Alten [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [tahoe-dev] Surely M$ can patent this process?
[adding Cc: p2p-hackers and cryptography mailing lists as explained below; Please trim your follow-ups as appropriate.] Dear Gary Sumner: On Jan 26, 2008, at 9:44 PM, Gary Sumner wrote: I was researching on the weekend and came across Tahoe…very exciting and can’t wait to delve in and understand more in detail. I was reading over Plank’s work around erasure encoding and that lead me to Tahoe. One thing that I was really looking for was to be able to encrypt the data before storing it and so was very excited when I read your architecture doc and it says “When a file is to be added to the grid, it is first encrypted using a key that is derived from the hash of the file itself.” This seems perfectly logical and natural way to apply this technique. However, researching also lead me to a patent M$ has been granted on this exact process: Encryption Systems and Methods for Identifying and Coalescing Identical Objects Encrypted with Different Keys - http:// patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2Sect2=HITOFFp=1u=% 2Fnetahtml%2FPTO%2Fsearch- bool.htmlr=1f=Gl=50co1=ANDd=PTXTs1=6983365.PN.OS=PN/ 6983365RS=PN/6983365 I haven't read that patent, so I can't say whether it applies to what allmydata.org Tahoe does or not. By default, for immutable files (but not for mutable files or directories), Tahoe sets the encryption key equal to the tagged hash of the file contents. (A tagged hash is simply a hash of the data prefixed by a tag to distinguish it from other uses of hash functions). You don't have to use Tahoe this way, however: The encryption before storing is critical for my application. If, for any reason, you don't want to let your encryption key be produced from the secure hash of the file contents, then Tahoe can instead use a randomly-generated encryption key. The drawback of doing it this way -- with a random encryption key -- is that you lose the deduplication feature: two people who independently store the same file contents will use twice as much space, instead of each of them having a pointer to a single stored copy. The advantages of doing it with a random encryption key are that you get a stronger guarantee about the confidentiality of the contents of your files, and it is faster as you don't need to process the whole file (in order to generate the encryption key) before beginning to upload the file. Surely there must be prior art on this technique to refute this patent? That's an interesting question, and I'm carbon-copying the p2p- hackers and cryptography mailing lists to ask if anyone knows. I learned about this technique from Jim McCoy and Doug Barnes in their design of Mojo Nation. I don't remember whether this technique was mentioned in Jim McCoy's personal communication of Mojo Nation to me in the summer of 1998, but it was definitely present in the design when I started working for Jim and Doug on Mojo Nation in 1999, and when Mojo Nation was first announced to the world at DefCon in July 2000 [1, 2]. I don't know if Jim came up with the idea ex nihilo or was exposed to it in the swirling soup of ideas that we lived in at the time: cypherpunks / Electric Communities (which had many ideas gleaned from Xanadu) / Financial Cryptography / etc.. I remember reading about the newly announced Freenet project in 2000 and being surprised at how many similarities its design had to our unannounced Mojo Nation project. The influential Freenet paper [3] was published in July, 2000 -- one month too late to count as prior art for that patent, which was filed May 2000. However, that paper was based on Ian Clarke's master's thesis, which was published in 1999. Let's see... A there it is: [4]. Hm, no it does not seem to contain the notion that the 2000 Freenet paper would popularize as Content Hash Keys. I've also just now re-read The Eternity Service (Anderson, 1996) [5], and it, like Clarke 1999, omits details of encryption. It's an interesting puzzle of intellectual history. The idea certainly seems to have been in the air, as both Mojo Nation and Freenet were working on it before the May 2000 patent submission by Doceur et al., but Mojo Nation and Freenet each published the idea shortly after May 2000. According to my limited understanding of patent law, this means that they don't count as prior art on that patent. Regards, Zooko [1] http://www.mccullagh.org/image/950-12/jim-mccoy-mojonation.html [2] http://web.archive.org/web/20001118214000/http:// www.mojonation.net/docs/technical_overview.shtml [3] http://citeseer.ist.psu.edu/420356.html [4] http://citeseer.ist.psu.edu/380453.html [5] http://citeseer.ist.psu.edu/anderson96eternity.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Lack of fraud reporting paths considered harmful.
Ian G [EMAIL PROTECTED] writes: There is a philosophical problem with suggesting an automated protocol method for reporting fraud, in that one might be better off ... fixing the underlying fraud. Lets say you're a big company like Amazon or someone similar. You're pretty sure someone is trying to use a stolen credit card. How do you fix the underlying fraud? Last I checked, Amazon had no police force. Lets say that the miscreants are in any one of several Eastern European countries. Even reporting the fraud to the police in the originating country won't fix it because the foreign police will do absolutely nothing. Perhaps you argue that the credit card system itself is flawed. I agree, but as a company like Amazon you're not in a position to fix that, either. The point of providing a feedback channel is so the issuing bank can be alerted to an attempted fraud, call the customer, say hi, did you try to buy a container consumer electronics and have it shipped to Belarus, hear back no, and issue a new credit card. This is done right now when the issuing bank notices suspicious activity, but there is a hole in the system in which a merchant might refuse a suspicious charge and yet have no way of telling the issuing bank about it. The call-the-customer-and-reissue mechanism is a mediocre solution to the fraud problem, but it is the one we have these days. As it stands, a merchant can't easily tell the issuing bank that it should have a look to see if a card is being used fraudulently, so the merchant can know that something weird is happening but the issuing bank can remain ignorant. This is not a good situation. That is why a feedback path would be of use. I had long assumed such a feedback path already existed, and I was rather shocked to discover it did not. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
