RE: [EMAIL PROTECTED]: Skype security evaluation]
> Do you have some articles about these protocols? The authoritative reference for TLS is the TLS RFC (http://www.ietf.org/rfc/rfc2246.txt). The authoritative reference for IPsec is of course the IPsec RFC (http://www.ietf.org/rfc/rfc2401.txt). As to why they wouldn't use these as they stand, synchronized protocols often require finer control over the data block size than these offer, but modification is easy enough, and would certainly have caused fewer concerns than a roll your own. [Marcel] Thanks, and appreciated, but I haven't made myself clear. I meant: is there a page by one of the known names in the field saying something like: "if you want to do this, then you should use these protocols"? Like Peter said: they should have used TLS or YASSL for the handshake and IPSEC + ESP for the transport. Is there a place where one trying to implement a secure system could go and find out the basic components he needs? With pros and cons, preferably? [Marcel] Maybe this is too much to ask, I don't know. That's pretty much the point :) Thanks, Marcel - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: [EMAIL PROTECTED]: Skype security evaluation]
> From: [EMAIL PROTECTED] [mailto:owner- > [EMAIL PROTECTED] On Behalf Of Peter Gutmann > I can't understand why they didn't just use TLS for the handshake (maybe > YASSL) and IPsec sliding-window + ESP for the transport (there's a free > minimal implementation of this whose name escapes me for use by people who > want to avoid the IKE nightmare). Established, proven protocols and > implementations are there for the taking, but instead they had to go out > and try and assemble something with their own three hands (sigh). Do you have some articles about these protocols? I can't find anything on your webpage, and a newbie (like myself) can't distinguish between well designed and badly designed protocols. Can you recommend such a collection of well designed protocols for various purposes? With implementation caveats if possible? (I haven't looked at it in a long time - is Handbook of Applied Cryptography a good reference for this?) Thanks, Marcel -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.7/155 - Release Date: 11/1/2005 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: That's gratitude for ya...
> From: [EMAIL PROTECTED] [mailto:owner- > [EMAIL PROTECTED] On Behalf Of Rich Salz > The other day I sent Amir Herzberg a private note saying I thought his > new tool was pretty neat, and though I'm sure he's heard it a lot, > thanks. He said nope, nobody else has said it, and I was stunned. My apologies. I've been using Amir's tool since he posted the link, but I haven't thought of sending a "thank you" note :( Amir, I also think it's neat. :) Marcel -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.8 - Release Date: 2/14/2005 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Cryptography Research wants piracy speed bump on HD DVDs
> From: [EMAIL PROTECTED] [mailto:owner- > [EMAIL PROTECTED] On Behalf Of Adam Back > Sent: Wednesday, December 22, 2004 11:48 PM > I would think the simplest canonical counter-attack would be to make a > p2p app that compares diffs in the binary output (efficiently rsync > style) accumulates enough bits to strip the disk watermark, p2p rips > and publishes. QED. Why not the way it happens right now - re-encoding? Few people post DVD images of movies on p2p networks, and even when they do, I prefer a DivX or XviD variant. (Much better given my 'net bandwidth.) I strongly doubt there's any chance of a watermark surviving an unknown re-encoding process (DivX has dozens of parameters you can change). Marcel - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: "Approximate" hashes
From: ""Hal Finney"" <[EMAIL PROTECTED]> > As you are probably aware, existing hashcash implementations do not base > the stamp on the message content. Instead they only lock the stamp to > the receiver's email address. Then the receiver keeps a list of the > hashcash stamps he has seen recently, to prevent reuse. I'm not sure > what you hope to gain by locking the stamp to the message content. Me dumb, sorry. I was actually thinking of some other thing I wanted to do about spam (which involved the whole content), and haven't re-read the hashcash site in about a week. You are perfectly right, of course. Windows spam victims, here I come! Thanks, Marcel - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: "Approximate" hashes
From: "Marcel Popescu" <[EMAIL PROTECTED]> > Hence my question: is there some "approximate" hash function (which I could > use instead of SHA-1) which can verify that a text hashes "very close" to a > value? So that if I change, say, tabs into spaces, I won't get exactly the > same value, but I would get a "good enough"? I just had an idea. Would this work? - let S be the input string, whose hash I want to verify - make S uppercase - remove everything but A-Z, 0-9, and common punctuation (!;:'",.?) - calculate the SHA1 hash of the result This should keep any insignificant changes out of the final result. Does anyone know of a mail transformation which could upset it? Can anyone see a way to "attack" this by letting a significantly different message collide on the same hash? (I'm ignoring the recent discoveries - they're not that practical, I'm only trying to fight spam, not the government.) Thanks, Marcel - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
"Approximate" hashes
I am trying to build a Windows anti-spam thingy; it's supposed to "sit" in between the mail client and the outer world, and indicate through mail headers whether the incoming mail has a valid hashcash http://www.hashcash.org/ "coin" (and, of course, to automatically add hashcash to outgoing emails). My problem is that I don't know what happens with the email in transit (this, I believe, is an observation in the hashcash FAQ). I am worried that some mail server might dislike ASCII characters with the high bit set, or that a client uses some encoding which for some reason doesn't make it to the destination unchanged. Hence my question: is there some "approximate" hash function (which I could use instead of SHA-1) which can verify that a text hashes "very close" to a value? So that if I change, say, tabs into spaces, I won't get exactly the same value, but I would get a "good enough"? I don't know if this is possible. But if it is, I though this would be a good place to find out about it. Thanks, Marcel - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Looking for mirror (or: better) sites to host my crypto/security lectures
From: "Amir Herzberg" <[EMAIL PROTECTED]> > So, if anyone has a reliable ftp server where I could post the lectures > (and update them via ftp), please let me know. You might also want to look into installing a tracker and sharing them with BitTorrent http://bitconjurer.org/BitTorrent/ - it should help with the bandwidth requirements for anyone making them available. Mark - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]