Re: de-identification
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes : > >Ladies and Gentlemen, > >I'd like to come up to speed on the state of the >art in de-identification (~=anonymization) of data >especially monitoring data (firewall/hids logs, say). >A little googling suggests that this is an academic >subspeciality as well as a word with many interpretations. >If someone here can point me at the mother lode of >insight, I would be most grateful. > What's your threat model? It's proved to be a very hard problem to solve, since there are all sorts of other channels -- application data, timing data (the remote fingerprinting paper mentioned this one), etc. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: AES cache timing attack
Steven M. Bellovin writes: > Dan Bernstein has a new cache timing attack on AES: > http://cr.yp.to/antiforgery/cachetiming-20050414.pdf This is a pretty alarming attack. Bernstein was actually able to recover the AES key using a somewhat artificial server which reported its own timing to do an AES operation. In principle the same attack would be possible on a typical remote server, using a larger number of requests to average out timing variations. He also had some critical things to say about the AES selection process, which apparently dropped the ball on this issue. Other ciphers got dinged for nonconstant execution time, but no one thought that cache misses would be that significant. Dan has more information at http://cr.yp.to/mac.html, including graphs showing the variability in timings for various implementations at http://cr.yp.to/mac/variability1.html and http://cr.yp.to/mac/variability2.html, and his own attempt at a (nearly) constant-time AES implementation as part of his poly1305-aes MAC function. It would be interesting to see how the speed of his AES implementation compares to that of other widely used versions like Brian Gladman's. How much speed penalty do you pay to get the constant speed? As Dan notes, you can easily make a slow AES that runs at constant speed, but a fast one is far more difficult. I also wonder how it would compare to take something like Gladman's (supposing it is faster than Bernstein's), estimate its worst case running time, and then add a delay using a high-res timer from the operating system to make it always take the same time. Hal Finney - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [Clips] Visa Sets Antifraud-System Upgrade
On Jun 14, 2005, at 14:27, R.A. Hettinga wrote: Antifraud systems help distinguish suspicious purchasing behavior, such as one credit card being used in multiple states within minutes. Such a pattern often can't be detected, however, until some purchases have been made. My wife was a victim of this antifraud system last month. She went to a thrice-yearly show where vendors from all over the country sell their wares. She made two purchases at one booth. The goods were from two different vendors -based in different states- so were processed as two transactions. The second one, just a minutes or two after the first, was denied with a "card cancelled" code. Then automated phone calls started coming from Visa to our home number. It was quite annoying. Impressive, but annoying. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
AES cache timing attack
Dan Bernstein has a new cache timing attack on AES: http://cr.yp.to/antiforgery/cachetiming-20050414.pdf (This was mentioned in Bruce Schneier's CRYPTO-GRAM newsletter.) Briefly, the attack relies on the fact that retrieving an S-box entry from the cache is much faster than retrieving it from main memory; this in turn leaks bits of keying material. One of his claims is that the attack is possible because of the characteristics of efficient software implementations of AES, and that NIST should have realized the problem -- there are ciphers that don't have this problem. He also makes some suggestions to CPU designers about steps they can take to let implementors avoid such traps. For years, it was a commonplace that one should not design one's own encryption algorithms. Some people have extended that advice to apply to cryptographic protocols. Dan Boneh now says he's warning people even against doing their own implementations. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
