Re: yahoo to use public key technology for anti-spam
In message <[EMAIL PROTECTED]>, bear writes: > >>But you should be sending mails via *your* SMTP server, and should be >>connecting to that SMTP server using SSL and authentication. Open relays >>encourage spam. People shouldn't be relaying mail via just any SMTP server. > >This is generally how I work it. I sit down at any hotspot and I >get network connectivity. But all the hotspot is ever going to see >of my browsing, email, and anything else I like to keep private is >SSH packets to my home machine, or encrypted X packets running >between the X server on my laptop and X clients on my home machine. > >A bit of lag is acceptable. Sending private mail via untrusted >SMTP servers is not. That isn't Carl's point. He may very well be using a trustworthy SMTP server, via a secure tunnel. The issue is whether he has to use a server owned by the owner of his return address. I use a variety of email addresses, for various reasons. I have my usual work account, some university accounts, a few personal accounts, one I reserve for EBay use, etc. I also use several different SMTP servers to send my email. I *always* have a secure tunnel set up; in fact, Postfix on my laptop is hard-wired to send to port 20025 on 127.0.0.1. Of course, where that ends up will vary, but it's not in a one-to-one correspondence with the sending address I use. The Yahoo scheme would apparently require that each email I send be routed via the domain owner's SMTP server. --Steve Bellovin, http://www.research.att.com/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: yahoo to use public key technology for anti-spam
[EMAIL PROTECTED] wrote: To avoid replay attacks one needs to sign a string that is tied to a specific message or time period I agree. Even time period and message content aren't good enough: Let's say that the outgoing SMTP mailer at example.com is trusted. Spammer gets an account at example.com, sends themselves one message, then immediately copies the signature into forged headers for their spam that is sent out through whatever open relays or compromised machines they are using. The only way that the mail can be trusted is if it is being received directly from the example.com SMTP server. If there is any relaying, there is nothing that remains true and constant to sign. But that is the situation we have today: My ISP's server can choose to refuse to accept connections from servers that are on a blacklist of open relays and spammers, and can, in theory, have a list of known good servers who authenticate their clients. If all the new header does is verify the sending mail server, that is done just as well by verifying the ip address at the time of connection. -- sidney - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: yahoo to use public key technology for anti-spam
Through the biting wind of a Cleveland Winter, I saw Anton Stiglic write: But you should be sending mails via *your* SMTP server, and should be connecting to that SMTP server using SSL and authentication. Open relays encourage spam. People shouldn't be relaying mail via just any SMTP server. Yes, that's true for home or personal use, but in a large organization, mail is likely to go through multiple SMTP servers before it reaches the server which hosts the user's mailbox. At my previous company, a piece of mail destined for a foreign address saw at least two and sometimes three SMTP servers on the way out; an inbound message from the outside saw at least three. Each of these servers will need to write to the message headers. Then there are the situations where you are at a company or university or something and they have locked down the outbound policies and it is impossible to initiate an outbound SMTP connection on port 25 or 465. In those situations, one *must* use the local SMTP server, even if it's not the ideal one. K -- In Vino Veritas ICQ: 14047557 http://userguide.mozdev.org http://kevin.astroturfgarden.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: yahoo to use public key technology for anti-spam
> So, in capsule: this proposal assumes that you use the same machine for > outgoing and incoming e-mail. I'm actually experimenting with sending mail directly, per this little hack[1], which does have separate paths for incoming and outgoing, but does not rely on the local hotspot/whatever. --dan [1] http://www.reitter-it-media.de/software/osxpostfix.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: yahoo to use public key technology for anti-spam
Carl Ellison wrote: So, in capsule: this proposal assumes that you use the same machine for outgoing and incoming e-mail. No, it implies a service that your outgoing mail server makes available that has you authenticate to it in some way and then signs your mail in some way. The article doesn't make clear exactly how it would work. The signature might just certify that the mail really was sent through the mail server that the headers claim was used. That would allow you to use any email address that you want, such as your acm.org address, and the signature certifies that you authenticated yourself with the SMTP server. My ISP recently switched to using TLS SMTP/Auth for access to their SMTP server from outside their network for their customers. It would be easy and useful for them to stamp mail that I send to show that it really was sent through their SMTP server and that they know who I am. This might not be exactly the same as what Yahoo! is talking about: They might be thinking only about mail with a yahoo.com From address being sent through a yahoo.com server and being signed with a key associated with the yahoo.com domain. But if the signature is taken to authenticate the domain of the SMTP server in the initial Received header, then it is possible to maintain lists of servers of ISPs who are trusted to authenticate users of their SMTP servers and to have anti-spam policies, and blacklists of servers that are spam sources. The From address would be irrelevant. -- sidney - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: yahoo to use public key technology for anti-spam
On Sun, 7 Dec 2003, Anton Stiglic wrote: > >- Original Message - >From: "Carl Ellison" <[EMAIL PROTECTED]> >To: "'Will Rodger'" <[EMAIL PROTECTED]>; "'Steve Bellovin'" ><[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> >Sent: Sunday, December 07, 2003 8:44 AM >Subject: RE: yahoo to use public key technology for anti-spam > > >> I, for one, hate the idea. My From address should be [EMAIL PROTECTED] That's >> my remailer where I receive all my incoming e-mail. However, my outgoing >> SMTP server depends on which cable modem provider or hot spot I happen to >be >> at the moment. It would be that SMTP machine that signs my outgoing mail, >> not acm.org who never sees my outgoing mail. > >But you should be sending mails via *your* SMTP server, and should be >connecting to that SMTP server using SSL and authentication. Open relays >encourage spam. People shouldn't be relaying mail via just any SMTP server. This is generally how I work it. I sit down at any hotspot and I get network connectivity. But all the hotspot is ever going to see of my browsing, email, and anything else I like to keep private is SSH packets to my home machine, or encrypted X packets running between the X server on my laptop and X clients on my home machine. A bit of lag is acceptable. Sending private mail via untrusted SMTP servers is not. Bear - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: yahoo to use public key technology for anti-spam
On Sun, 7 Dec 2003, Anton Stiglic wrote: > But you should be sending mails via *your* SMTP server, and should be > connecting to that SMTP server using SSL and authentication. Open relays > encourage spam. People shouldn't be relaying mail via just any SMTP server. > This is misguided, but we should not start that flame-war here. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: yahoo to use public key technology for anti-spam
- Original Message - From: "Carl Ellison" <[EMAIL PROTECTED]> To: "'Will Rodger'" <[EMAIL PROTECTED]>; "'Steve Bellovin'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, December 07, 2003 8:44 AM Subject: RE: yahoo to use public key technology for anti-spam > I, for one, hate the idea. My From address should be [EMAIL PROTECTED] That's > my remailer where I receive all my incoming e-mail. However, my outgoing > SMTP server depends on which cable modem provider or hot spot I happen to be > at the moment. It would be that SMTP machine that signs my outgoing mail, > not acm.org who never sees my outgoing mail. But you should be sending mails via *your* SMTP server, and should be connecting to that SMTP server using SSL and authentication. Open relays encourage spam. People shouldn't be relaying mail via just any SMTP server. --Anton - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: yahoo to use public key technology for anti-spam
On Sat, 6 Dec 2003, Will Rodger wrote: > Steve Bellovin wrote: > >http://edition.cnn.com/2003/TECH/internet/12/05/spam.yahoo.reut/ > > > Does anyone have details? How much overhead would this entail? > To avoid replay attacks one needs to sign a string that is tied to a specific message or time period and is invariant under forwarding through various relays and gateways. The header and envelope sender and recipients are often subject to rewriting, the Message-Id can be cloned. What exactly would they have the sender domain sign. I am skeptical that such a proposal can acquire any traction. Also curious to see the details... -- Viktor. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: safety of Pohlig-Hellman with a common modulus?
David Wagner wrote: > Peter Fairbrother wrote: >> Not usually. In general index calculus attacks don't work on P-H, [...] > > Sure they do. If I have a known plaintext pair (M,C), where > C = M^k (mod p), then with two discrete log computations I can > compute k, since k = dlog_g(C)/dlog_g(M) (mod p-1). This works for > any generator g, so I can do the precomputation for any g I like. Duuuh. I _knew_ that. I've even proposed changing p from time to time to limit the take from an IC attack. Dumb of me. Too much beer, no coffee, got a brainstorm and couldn't see the wood for the trees... Sorry. -- Peter Fairbrother - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: yahoo to use public key technology for anti-spam
I, for one, hate the idea. My From address should be [EMAIL PROTECTED] That's my remailer where I receive all my incoming e-mail. However, my outgoing SMTP server depends on which cable modem provider or hot spot I happen to be at the moment. It would be that SMTP machine that signs my outgoing mail, not acm.org who never sees my outgoing mail. So, in capsule: this proposal assumes that you use the same machine for outgoing and incoming e-mail. +--+ |Carl M. Ellison [EMAIL PROTECTED] http://theworld.com/~cme | |PGP: 75C5 1814 C3E3 AAA7 3F31 47B9 73F1 7E3C 96E7 2B71 | +---Officer, arrest that man. He's whistling a copyrighted song.---+ > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Will Rodger > Sent: Saturday, December 06, 2003 7:01 PM > To: Steve Bellovin; [EMAIL PROTECTED] > Subject: Re: yahoo to use public key technology for anti-spam > > Steve Bellovin wrote: > >http://edition.cnn.com/2003/TECH/internet/12/05/spam.yahoo.reut/ > > > Does anyone have details? How much overhead would this entail? > > And how, btw, should we feel about having to sign every > message from our > very own vanity domains? > > Will Rodger > > - > 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: origin of SHA 224 initial hash values
| I don't know about 224 and there isn't any 128 but for SHA-1 (160) the | initial values seem to be just an obvious pattern... BTW, it hadn;t occured to me until now, but the 160-bit SHA-1 was presumably designed to go with the 80-bit Clipper encryption! -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Additional Proposed Hash Function (Forwarded)
| > | > NIST is proposing a change notice for FIPS 180-2, the Secure Hash Standard | > | > that will specify an additional hash function, SHA-224, that is based on | > | > SHA-256. The change notice is available at | > | > http://csrc.nist.gov/publications/drafts.html. NIST requests comments for | > | > the change notice by January 16, 2004. Comments should be addressed to | > | > [EMAIL PROTECTED] | > | | > | Does anyone know what the story is behind this? It seems to be the | > | same sort of relationship that SHA-384 has to SHA-512 - that is, the | > | same basic algorithm, the same amount of work to calculate it, but | > | with different initial values, and some bits chopped off at the end. | > | It all seems a lot of effort just to save 4 bytes in the final hash. | | > I'd guess that this is part of an effort to define hashes "equivalent in | > strength" to various standardized ciphers. Because of birthday attacks, in | > some sense the security of an n-bit hash is comparable to that of an n/2-bit | > cipher. So SHA-256, -384, and -512 are intended to match the three supported | > AES key sizes of 128, 196, and 256 bits. SHA-224 then comes out to match | > 2-key 3-DES. | | | That is the guess we came up with too. But, why does | NIST bother to standardise this? | | Granted 2-key 3-DES is in widespread use, but it should | gradually switch across to other ciphers. Standards bodies are supposed to deal with existing practice. If you accept the need for hash functions with sizes "matched" to standardized encryption techniques, then it's appropriate for them to do this. (Of course, it raises the question of why there isn't an SHA-112 to go with DES - but I guess that's officially deprecated now.) |And, for a | stop-gap measure, if a protocol implementor finds a need | to match a hash size, why not just truncate a SHA-256? NIST isn't an implementor, its a standards body. It can't say "just truncate SHA-256" - it has to say *how*. In fact, the real question here is why they bothered to change the initial values. It does make the SHA-256 and SHA-224 values independent in some sense, but but I'm not sure exactly *how* independent. That is: If I give you the SHA-256 and SHA-224 hashes on some piece of data, have I given you something that's effectively a 480-bit hash? Changing the initial value is equivalent to prepending some initial fixed block. The fixed block is unknown, unless the initial value was *calculated* as the result of one iteration of SHA over some value. That's why it's important to know just where the intial value came from. | Or, to take the alternate position, if there is a case | for "wierd lengths," then maybe this is a case that | SHA could be reworked to be of flexible length, at the | algorithm level? Well, this is one place that secure hash function theory is rather weak. All the hash functions in use have an iterative structure, which implies a prepend property (i.e., if I know the hash of X, where X is an even multiple of the block size in length) I can calculate the hash X || Y for any Y, without knowing X.) Also, the constructions are size-specific - there's no obvious way to change the block size or output size - except by keeping a fixed block size and discarding some part of the final block to produce a smaller output size. I think there are some constructions out there without these problems, but none seem to be practical. This remains an area waiting for a clever design. | Defining a new SHA seems to be a lot of detailed work, | albeit hardly challenging, for everyone involved in | producing standard crypto, and there doesn't seem to be | much of a payoff for all those people. The goal of "a hash to match each encryption", in the abstract, sounds great. Whether it actually makes practical sense is debatable. However, once a standards process gets rolling, the original purposes can fade from view. -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: safety of Pohlig-Hellman with a common modulus?
- Original Message - From: "Peter Fairbrother" <[EMAIL PROTECTED]> To: "David Wagner" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Saturday, December 06, 2003 7:58 PM Subject: Re: safety of Pohlig-Hellman with a common modulus? > David Wagner wrote: > > > Steve Bellovin wrote: > >> Is it safe to use Pohlig-Hellman encryption with a common modulus? > >> That is, I want various parties to have their own exponents, but share > >> the same prime modulus. In my application, a chosen plaintext attack > >> will be possible. (I know that RSA with common modulus is not safe.) > > > > Yes, I believe so. The security of Pohlig-Hellman rests on the difficulty > > of the discrete log problem. > > Nope. In P-H there is no g. A ciphertext is M^k mod p. An attacker won't > know k, and usually won't know M, but see below. I don't know what the > problem is called, but it isn't DLP. Anyone? If you don`t know M and k, there are several values M', k' such that M'^k' mod p == M^k mod p. For example, if M is a generator of the group mod p, than all other generators M' will have a corresponding k' that will give you this value. Think about known plaintext attack or chosen plaintext attack. A symmetric cipher should be secure against these attacks and much more... In these attacks you know the bases of several values... --Anton - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: safety of Pohlig-Hellman with a common modulus?
Peter Fairbrother wrote: >Nope. In P-H there is no g. A ciphertext is M^k mod p. An attacker won't >know k, and usually won't know M, but see below. I don't know what the >problem is called, but it isn't DLP. Anyone? Ok, I was being slightly loose. To be more precise, the security of Pohlig-Hellman is based on the Decision Diffie-Hellman (DDH) problem, I believe. But the best known attack on DDH (when you're working in a prime-order subgroup) is to compute discrete logs. >Not usually. In general index calculus attacks don't work on P-H, [...] Sure they do. If I have a known plaintext pair (M,C), where C = M^k (mod p), then with two discrete log computations I can compute k, since k = dlog_g(C)/dlog_g(M) (mod p-1). This works for any generator g, so I can do the precomputation for any g I like. >When using P-H I usually pre-encrypt data in any old symmetric cipher with a >random IV and any old key, to avoid known plaintext attacks. Ok, that sounds like it should work. To break the composed scheme, one would need to break both P-H and the other symmetric cipher. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Additional Proposed Hash Function (Forwarded)
Ian Grigg <[EMAIL PROTECTED]> writes: >That is the guess we came up with too. But, why does NIST bother to >standardise this? There'd already been a similar discussion on this topic on another list, every security standard and protocol already provides for generating 3DES keys via its PRF of choice, so why create yet another new hash variant for it? All it does is create extra complexity for implementors (let's see, was that SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA224, SSL_RSA_WITH_3DES_EDE_CBC_SHA512_TRUNCATED_TO_112, SSL_RSA_WITH_3DES_EDE_CBC_SHA256_WITH_BITS_MISSING, or SSL_RSA_WITH_3DES_EDE_CBC_SHA384_FOLDED_IN_HALF?). As a result, it's in danger of ending up with a de facto profile of "ignore it". In terms of implementations of standard protocols (TLS, SSH, S/MIME, PGP, IPsec), I can't see any use for it that'd justify the complexity and overhead of adding it to an implementation. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
