Re: Piercing network anonymity in real time
[EMAIL PROTECTED] wrote: The Locate appliance sits passively on the network and analyzes packets in real time to garner ID info from sources like Active Directory, IM and e-mail traffic, then associates this data with network information. This is really nothing new -- I've been seeing systems like these, though home brewed, in use for years. The availability of good tools as a foundation (things like Snort, the layer7 iptables patch, and so on) makes building decent layer 8 inference not far from trivial. Calling this piercing network anonymity in real time is highly misleading; in reality, it's more like making it bloody obvious that there's no such thing as network anonymity. The best one can hope for today is a bit of anonymous browsing and IM with Tor, and that only insofar as you can trust a system whose single point of failure -- the directory service -- was, at least until recently, Roger's personal machine sitting in an MIT dorm room. -- Ivan Krstic [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
picking a hash function to be encrypted
So... Suppose I want a function to provide integrity and authentication, and that is to be combined with a stream cipher (as is the plaintext). I believe that authentication is free once I have integrity given the fact that the hash value is superencrypted using the stream cipher, whose key is shared by only the sender and recipient. I believe what I'm looking for is a strongly universal hash. I don't need much; everything I've seen is simultaneously too much and too little, often calling upon a block cipher, which seems redundant. What I was thinking of doing was using Poly1305, and using the stream cipher instead of AES. I think in this case that I can leave the MAC exposed, since it's a MAC and not a hash. Is there an analogous, hash function that does not use encryption internally? Backing up a bit, are there simpler hash functions (or families of functions) that could scale and, given the stream cipher, do the job? For example, the wikipedia entry for UMAC* shows a very simple hash family, which is trivial to scale to give a desired security level |D|. So I have a couple of questions about it; first, is it appropriate to use in this circumstance? Second, how would I authenticate variable-length messages; do I merely break them up into sequential pieces and authenticate each piece seperately, or is there a way to authenticate the whole thing without using some other hash function? [*] http://en.wikipedia.org/wiki/UMAC I'd really like to read the fine literature, but most of the papers I've found appear to predate the web. Any URLs would be much appreciated. And for reading this whole email, you get a present: http://dsns.csie.nctu.edu.tw/research/crypto/ -- Curiousity killed the cat, but for a while I was a suspect -- Steven Wright Security Guru for Hire http://www.lightconsulting.com/~travis/ -- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: picking a hash function to be encrypted
On Sun, May 14, 2006 at 03:04:41AM -0500, Travis H. wrote: Suppose I want a function to provide integrity and authentication, and that is to be combined with a stream cipher (as is the plaintext). I believe that authentication is free once I have integrity given the fact that the hash value is superencrypted using the stream cipher, whose key is shared by only the sender and recipient. I believe what I'm looking for is a strongly universal hash. I don't need much; everything I've seen is simultaneously too much and too little, often calling upon a block cipher, which seems redundant. What I was thinking of doing was using Poly1305, and using the stream cipher instead of AES. I think in this case that I can leave the MAC exposed, since it's a MAC and not a hash. Is there an analogous, hash function that does not use encryption internally? Security is fragile. Deviating from well understood primitives may be good research, but is not good engineering. Especially fragile are: - Non-mainstream ciphers (often broken once someone good bothers to try) - Stream ciphers (additive) - RC4 (poor key schedule) - RSA (multiplicative) The first is to be avoided entirely, the second and third should be used only under duress, when block ciphers are a very poor fit for the application. RSA needs to be used only in very specific ways (PKCS 2.1, for example) that avoid the common pitfalls. TLS (available via OpenSSL) provides integrity and authentication, any reason to re-invent the wheel? It took multiple iterations of design improvements to get TLS right, even though it was designed by experts. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Piercing network anonymity in real time
Ivan Krstic [EMAIL PROTECTED] writes: Calling this piercing network anonymity in real time is highly misleading; in reality, it's more like making it bloody obvious that there's no such thing as network anonymity. No. Ever hear of Chaum's Dining Cryptographers [1]? Anonymity right there at the table. Been around for almost twenty years. Strong anonymity is available today using chains of random-latency, mixing, anonymizing remailers based on mixmaster [2], of which there is a thriving worldwide network [3]. The best one can hope for today is a bit of anonymous browsing and IM with Tor ... Tor is indicted by its own documentation: ... for low-latency systems like Tor, end-to-end traffic correlation attacks [8, 21, 31] allow an attacker who can observe both ends of a communication to correlate packet timing and volume, quickly linking the initiator to her destination. [4] [1] The Dining Cryptographers Problem: Unconditional Sender Untraceability, D. Chaum, (invited) Journal of Cryptology, vol. 1 no. 1, 1988, pp. 65-75. ftp://ftp.csua.berkeley.edu/pub/cypherpunks/papers/chaum.dining.cryptographers.gz http://www.e-ztown.com/cryptopapers.htm http://citeseer.nj.nec.com/context/143887/0 [2] http://sourceforge.net/projects/mixmaster/. [3] See usenet newsgroup alt.privacy.anon-server. [4] http://tor.eff.org/cvs/tor/doc/design-paper/challenges.pdf - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: picking a hash function to be encrypted
On 5/14/06, Eric Rescorla [EMAIL PROTECTED] wrote: Consider the case where you're transmitting message M. The hash is H(M). You then encrypt (M || H(M)), generating K XOR (M || H(M)). If the attacker knows M and H, he can compute (M || H(M)) and compute K. Then he can re-encrypt a message M' of his choice. Excellent point. When I wrote that I had strongly universal hashes in mind, like UMAC, where the hash is chosen from a family of functions based on some secret data shared by sender and recipient. I mistakenly conflated them with ordinary hashes (which they are, once you pick one). Thanks for catching that. IMHO encrypting MACs is a good defensive measure, because you can then use a smaller hash value, so you end up encrypting as little as 4 bytes instead of transmitting 20 en clair, and now you also know the opponent hasn't learned anything. Does anyone know if MAC-then-encrypt(plaintext) versus encrypt(plaintext)-then-MAC makes a difference if the MAC itself is to be encrypted? I can't think of why it would. -- Curiousity killed the cat, but for a while I was a suspect -- Steven Wright Security Guru for Hire http://www.lightconsulting.com/~travis/ -- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: picking a hash function to be encrypted
On 5/14/06, Victor Duchovni [EMAIL PROTECTED] wrote: Security is fragile. Deviating from well understood primitives may be good research, but is not good engineering. Especially fragile are: Point taken. This is not for a production system, it's a research thing. TLS (available via OpenSSL) provides integrity and authentication, any reason to re-invent the wheel? It took multiple iterations of design improvements to get TLS right, even though it was designed by experts. IIUC, protocol design _should_ be easy, you just perform some finite-state analysis and verify that, assuming your primitives are ideal, no protocol-level operations break it. The 7th Usenix Security Symposium has a paper where the authors built up SSL 3.0 to find out what attack each datum was meant to prevent. They used mur-phi, which has been used for VLSI verification (i.e. large numbers of states). ATT published some code to do it too (called SPIN). It's effective if the set of attacks you're protecting against is finite and enumerable (for protocol design, I think it should be; reflection, replay, reorder, suppress, inject, etc.). I wouldn't consider fielding a protocol design without sanity-checking it using such a tool. Was there an attack against TLS which got past FSA, or did the experts not know about FSA? -- Curiousity killed the cat, but for a while I was a suspect -- Steven Wright Security Guru for Hire http://www.lightconsulting.com/~travis/ -- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
the meaning of linearity, was Re: picking a hash function to be encrypted
- Stream ciphers (additive) This reminds me, when people talk about linearity with regard to a function, for example CRCs, exactly what sense of the word do they mean? I can understand f(x) = ax + b being linear, but how exactly does XOR get involved, and are there +-linear functions and xor-linear functions? Are they disjoint? etc. -- Curiousity killed the cat, but for a while I was a suspect -- Steven Wright Security Guru for Hire http://www.lightconsulting.com/~travis/ -- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: picking a hash function to be encrypted
On Sun, May 14, 2006 at 07:56:17PM -0500, Travis H. wrote: On 5/14/06, Victor Duchovni [EMAIL PROTECTED] wrote: Security is fragile. Deviating from well understood primitives may be good research, but is not good engineering. Especially fragile are: Point taken. This is not for a production system, it's a research thing. TLS (available via OpenSSL) provides integrity and authentication, any reason to re-invent the wheel? It took multiple iterations of design improvements to get TLS right, even though it was designed by experts. IIUC, protocol design _should_ be easy Once upon a time, everyone agreed that cipher design was hard. Later people discovered that protocol design is hard too. More recently people are discovering that given solid ciphers and protocols, secure implementations are still hard... I could be wrong, but it does not seem that the trend is towards increasingly easy security, in the sense that anyone who learns a programming language reasonably well can develop security toolkits. :-( -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
