Stories
Slash Boxes
Comments

SoylentNews is people

posted by cmn32480 on Sunday April 24 2016, @11:38PM   Printer-friendly
from the spammers-should-be-{insert-punishment-here} dept.

Peter N. M. Hansteen asks the question, "Does Your Email Provider Know What A "Joejob" Is?" in his blog and provides some data and discussion. He provides anecdotal evidence which seems to indicate that Google and possibly other mail service providers are either quite ignorant of history when it comes to email and spam, or are applying unsavory tactics to capture market dominance.

[Ed Note: I had to look up "joe job" to find out what it is. According to wikipedia:

A joe job is a spamming technique that sends out unsolicited e-mails using spoofed sender data. Early joe jobs aimed at tarnishing the reputation of the apparent sender or inducing the recipients to take action against them (see also e-mail spoofing), but they are now typically used by commercial spammers to conceal the true origin of their messages.

]


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Informative) by Anonymous Coward on Monday April 25 2016, @12:04AM

    by Anonymous Coward on Monday April 25 2016, @12:04AM (#336765)

    It is kind of a PITA to get all 3 set up and working. Their separate but connected status reflects the piecemeal/evolution of email authentication over the years.

    SPF [wikipedia.org]
    DKIM [wikipedia.org]
    DMARC [wikipedia.org]

    Also I've noticed that google "remembers" SMTP relays associated with senders. I switched my outbound SMTP server and email from one of my addresses to one specific gmail address started bouncing - those two addresses talked to each other a lot. Switched back to the original relay and the bounces stopped. No problems with other low volume correspondance to other gmail accounts.

    • (Score: 4, Interesting) by Whoever on Monday April 25 2016, @12:38AM

      by Whoever (4524) on Monday April 25 2016, @12:38AM (#336773) Journal

      Also I've noticed that google "remembers" SMTP relays associated with senders.

      I believe that you are correct. The problem is that Google allows this historic data to override SPF. When I changed my outgoing mail server, my emails sent to gmail started going into spam folders, despite having valid SPF.

      I think that many large email providers just make sure that they accept emails from other large providers and they don't care beyond that. The end goal for Google is to make it impossible to run your own mail server and hence increase the number of domains hosted at Google.

      I have set up SPF, DKIM and DMARC records. I think that they make very little difference. For support of this proposition, look at the scores for DKIM in SpamAssassin.

      • (Score: 3, Interesting) by TheRaven on Monday April 25 2016, @08:37AM

        by TheRaven (270) on Monday April 25 2016, @08:37AM (#336883) Journal

        I have set up SPF, DKIM and DMARC records. I think that they make very little difference. For support of this proposition, look at the scores for DKIM in SpamAssassin.

        I'm not sure about the more recent things, but someone did a study a few years after SPF was introduced and found that over 90% of domains with valid SPF records were owned by spammers. It's easy to register a new domain and add SPF records.

        That's fine, because SPF was never intended to say 'this mail is not spam', it was intended to say 'all emails that come from the wrong server are spam and if messages from this domain are spam then it's safe to bounce them back to this server'. In spite of that, the last time I was on the receiving end of a Joe Job it was from a domain that had SPF records set up correctly and the server responsible for bouncing all of the spam at me as GMail.

        --
        sudo mod me up
        • (Score: 0) by Anonymous Coward on Monday April 25 2016, @11:59AM

          by Anonymous Coward on Monday April 25 2016, @11:59AM (#336912)

          > 'this mail is not spam', it was intended to say 'all emails that come from the wrong server are spam and if messages from this domain are spam then it's safe to bounce them back to this server'.

          No that is not what SPF is intended to do. For one thing, who bounces spam? That goes into spam folders or is null routed. All SPF is intended to do is say whether or not the sending host is authorized to deliver the message or not. Its up to the receiving host to decide what to do with that information.

          > In spite of that, the last time I was on the receiving end of a Joe Job it was from a domain that had SPF records set up correctly and the server responsible for bouncing all of the spam at me as GMail.

          It doesn't matter if the spammer's domain had an SPF record, what matters is if your domain had a restrictive SPF record.

          Even then it is possible to set up SPF in such a way as to permit anyone to impersonate your domain. I've seen lots of SPF guides that recommend ~all or even +all at the end of the SPF record.

      • (Score: 0) by Anonymous Coward on Monday April 25 2016, @10:53AM

        by Anonymous Coward on Monday April 25 2016, @10:53AM (#336903)

        Yep, they don't care. My employer runs their own email server, and we have constant headaches with emailed reports we send out being sent to the spam folder or sometimes just disappeared entirely.

        My standard response has been to forward the copy of the email (report engine saves this) and just say something to the effect of let your IT department or consultant know. If they want an escalation, the server admin will forward info from the mailserver log showing that we did our part and delivered it "to the next relay."

        Of course, nobody ever does anything about it to resolve the problem. I suspect there's a lot of apathy out there among small businesses that use gmail in particular. Everybody knows that if Google doesn't want to do something, Google doesn't want to do something, and they'll tell you "fuck you" for trying to contact them about a problem.

        I forget if we've got DMARC set up, but SPF and DKIM are there. Doesn't make a damn difference.

      • (Score: 0) by Anonymous Coward on Monday April 25 2016, @04:17PM

        by Anonymous Coward on Monday April 25 2016, @04:17PM (#336991)

        > For support of this proposition, look at the scores for DKIM in SpamAssassin.

        So I took you up on that and did go looking.

        The rule that would be most useful is still just a test-mode rule - T_DKIM_INVALID - the message fails DKIM validation.

        Apparently the reason they have not promoted that to a full-blown rule is that too many domains have screwed up their DKIM implementation and it would give too many false positives if they made it an official rule.

        That's not really an indictment against DKIM being effective, but rather a problem of too many sloppy sysadmins.

    • (Score: 0) by Anonymous Coward on Monday April 25 2016, @01:34AM

      by Anonymous Coward on Monday April 25 2016, @01:34AM (#336787)

      You know GPG is effective because nobody looks at the signature just like you know SPF and DKIM and DMARC are totally effective because nobody gives a shit and everyone just sees your name as the sender and fucking shitcans you forever.

      Hint: none of your eggheadery technical "solutions" do jack-shit on the receiving end.

      • (Score: 1, Insightful) by Anonymous Coward on Monday April 25 2016, @01:50AM

        by Anonymous Coward on Monday April 25 2016, @01:50AM (#336789)
        If your recipients actually use an email client that understands GPG, then the email client software LOOKS AT THE SIGNATURE AND DECIDES FROM THERE. And if your recipient's SMTP server understands all about SPF, DKIM, and DMARC, that makes it effective. The "eggheadery technical 'solutions'" do jack shit if the software on the receiving end understands them. For email servers at least, this is becoming more and more true.
        • (Score: -1, Troll) by Anonymous Coward on Monday April 25 2016, @02:06AM

          by Anonymous Coward on Monday April 25 2016, @02:06AM (#336795)

          If your recipients actually use an email client that understands GPG,

          ... and you fail.

          If you can expect your recipients to use special tools to read your email, then you can negotiate to use something other than email instead. Email is the absolute worst form of communication and you should not be using it for anything ever unless you literally have no other option.

          Stop trying to fix email, you moron. Email is broken. Stop using email.

          • (Score: 1, Informative) by Anonymous Coward on Monday April 25 2016, @02:13AM

            by Anonymous Coward on Monday April 25 2016, @02:13AM (#336798)

            Except that every client on the planet, short of webmail, does S/MIME, which is GPG for grownups (the DOD uses it). Your smartphone can do S/MIME. kMail and Thunderbird did S/MIME since forever. Outlook, Apple Mail, hell even Alpine and Mutt do S/MIME. Nothing special about it, nothing needed beyond what you have, unless you're reading your mail on a webmail client, in which case your privacy was fucked from the start. Except for webmail, i.e. the power of Google's Gmail, there's absolutely no excuse for all mail not already being end-to-end clientside encrypted: the tech is already in place. Google is what's standing in the way.

            • (Score: 3, Interesting) by TheRaven on Monday April 25 2016, @08:35AM

              by TheRaven (270) on Monday April 25 2016, @08:35AM (#336882) Journal

              The problem with S/MIME is similar to that of GPG. If you're using it for signing, it's trivial to strip the signature and then modify the message. How many users will notice that the signature is not there? Most mail clients have a UI that prominently displays when a signature is present (though I notice Apple Mail has made that less visible in recent versions), but when it's not present they display nothing. Unless you train users to actively look for the signature, it doesn't help. Ideally, mail clients should recognise senders and warn when you get messages from someone who normally signs mail but hasn't this time.

              If you're using it for encryption, then you are back to the key distribution problem. You need to get the recipient's public key to be able to encrypt the message and that then ensures that no one other than the recipient can read it (so no mailing lists, for example - though it would be nice if the list software could have its own key pair for the list, decrypt and then encrypt with each list member's public key).

              --
              sudo mod me up
              • (Score: 0) by Anonymous Coward on Monday April 25 2016, @06:41PM

                by Anonymous Coward on Monday April 25 2016, @06:41PM (#337039)

                S/MIME already works with mailing lists. See https://www.sympa.org/manual/x509 [sympa.org].

          • (Score: 1, Insightful) by Anonymous Coward on Monday April 25 2016, @02:32AM

            by Anonymous Coward on Monday April 25 2016, @02:32AM (#336806)

            Email is the absolute worst form of communication and you should not be using it for anything ever unless you literally have no other option.

            Indeed. Just wanted to second this. Just like HTML / CSS / JS, it all needs to be refactored. Everycoder knows refactoring is a necessity to stave off codebase entropy after a while, and yet many morons throw their arms up in hopeless stupor and proclaim it's impossible to do with email, or other web technologies. Yes, yes, "migration resistant", blah blah blah. Telegraphs were migration resistant too...

        • (Score: 2) by butthurt on Monday April 25 2016, @02:12AM

          by butthurt (6141) on Monday April 25 2016, @02:12AM (#336797) Journal

          A joe-jobber is free to send messages to anyone, not only the highly computer-literate correspondents you've cultivated.

          • (Score: -1, Troll) by Anonymous Coward on Monday April 25 2016, @02:22AM

            by Anonymous Coward on Monday April 25 2016, @02:22AM (#336804)

            Elitist fools still think they can fix email. Everyone else uses Facebook instead.

            • (Score: 0) by Anonymous Coward on Monday April 25 2016, @03:55AM

              by Anonymous Coward on Monday April 25 2016, @03:55AM (#336827)
              Last I checked you still need a working email address to even get a Facebook account.
            • (Score: 0) by Anonymous Coward on Monday April 25 2016, @04:00AM

              by Anonymous Coward on Monday April 25 2016, @04:00AM (#336829)
              And you get spam straight to your eyeballs every time you log in. No thanks.
          • (Score: 0) by Anonymous Coward on Monday April 25 2016, @02:54AM

            by Anonymous Coward on Monday April 25 2016, @02:54AM (#336811)

            Wow.
            I never expected to hear hotmail [office.com], gmail, [threatpost.com] yahoo mail [yahoo.com] and aol [aol.com] users referred to as "highly computer-literate," least of all here on soylent.

            This place is really slipping. Eternal september!

            • (Score: 2) by butthurt on Monday April 25 2016, @04:13AM

              by butthurt (6141) on Monday April 25 2016, @04:13AM (#336833) Journal

              While I'm certain that some users of all those services are also users of PGP/GPG, I'm not aware of anything those services do to facilitate or encourage the use of PGP or GPG. None of the pages you've linked contain the terms "PGP" nor "GPG." I don't think I'm mistaken in assuming that the users of that software are, globally, a small minority of the people who use e-mail.

              The grandparent post asserted:

              If your recipients actually use an email client that understands GPG, then the email client software LOOKS AT THE SIGNATURE AND DECIDES FROM THERE.

              I thought it obvious that my response alluded to that bit. Sorry for the misunderstanding.

              • (Score: 0) by Anonymous Coward on Monday April 25 2016, @05:25AM

                by Anonymous Coward on Monday April 25 2016, @05:25AM (#336844)

                Even if you were not being disingenuous about PGP, the fact remains that a joe-jobber is NOT free to send messages to any of those email services because his messages will be tagged as spam or even routed straight to /dev/null before any PGP signatures are even parsed.

                • (Score: 2) by butthurt on Monday April 25 2016, @08:02AM

                  by butthurt (6141) on Monday April 25 2016, @08:02AM (#336875) Journal

                  LOL, in what way might I be "disingenuous about PGP," pray tell?

                  a joe-jobber is NOT free to send messages to any of those email services because his messages will be tagged as spam or even routed straight to /dev/null before any PGP signatures are even parsed.

                  "Attempt to send," then, if you prefer. A spammer can attempt to send messages to any e-mail address in the world, as well as nonexistent ones. Spammers exchange lists comprising millions of addresses. There are plenty of mail servers in the world that, when they identify a message as spam or malware, or as having an invalid recipient, will send a DSN (often including the original message) to the address on its "To:" line. Get joe-jobbed, and your mailbox will be deluged with crap. You got all your correspondents to use Google Mail, Yahoo Mail, Hotmail and AOL? Great, and do those services keep you from seeing DSNs from other e-mail providers?

                  • (Score: 0) by Anonymous Coward on Monday April 25 2016, @11:45AM

                    by Anonymous Coward on Monday April 25 2016, @11:45AM (#336910)

                    > LOL, in what way might I be "disingenuous about PGP," pray tell?
                    >
                    > "Attempt to send," then, if you prefer. A spammer can attempt to send messages to any e-mail address in the world,

                    Same way you are being disingenuous now. What an utterly meaningless, goal-post moving restatement.

                    But whatever it takes to make you feel like you weren't just being a snarky idiot, right?

                    Did you know how apropos your username was when you picked it?

                    • (Score: 2) by butthurt on Monday April 25 2016, @03:43PM

                      by butthurt (6141) on Monday April 25 2016, @03:43PM (#336980) Journal

                      Not at all. I was simply offering a clarification. You prefer to misunderstand, fine.

          • (Score: -1, Redundant) by Anonymous Coward on Monday April 25 2016, @03:58AM

            by Anonymous Coward on Monday April 25 2016, @03:58AM (#336828)
            Yahoo Mail, Hotmail, and Gmail all understand SPF, DKIM, and DMARC and use them as part of their anti-spam strategy. So now all the people who use these services for email are considered "highly computer-literate"?
      • (Score: 0) by Anonymous Coward on Monday April 25 2016, @01:57AM

        by Anonymous Coward on Monday April 25 2016, @01:57AM (#336791)

        Hey jack-off!

        All the major email services now verify spf/dkim/dmarc. They don't necessarily process that information identically, but they all use it as part of their anti-spam process. So climb under whatever rock you live under and keep your trap shut in front of your betters.

        • (Score: 0) by Anonymous Coward on Monday April 25 2016, @02:18AM

          by Anonymous Coward on Monday April 25 2016, @02:18AM (#336803)

          You must love spam since you feel the need to process the hell out of your messages to keep that Spam Message Transport Protocol alive.

          • (Score: 2) by maxwell demon on Monday April 25 2016, @10:13AM

            by maxwell demon (1608) on Monday April 25 2016, @10:13AM (#336901) Journal

            So what do you propose a replacement should look like?

            --
            The Tao of math: The numbers you can count are not the real numbers.
    • (Score: 2) by zocalo on Monday April 25 2016, @06:36AM

      by zocalo (302) on Monday April 25 2016, @06:36AM (#336860)
      SPF gets a bad rep because it was touted as a "solution" to spam by people who ought to have known better - it's not a solution to spam, but it is a *very* effective deterrant against people using your domain for a joe-job, or even collateral damage from trojans that use random senders from an address book when spamming their way through the rest. Whenever I've setup SPF (ideally with the "-all" option) the amount of email backscatter from spam has dropped to near zero almost as fast as the DNS records could propogate, making me think that spammers actively check for the presense of SPF, DKIM, etc. and if found actively avoid the domain as a faked sender, so definitely worth doing.
      --
      UNIX? They're not even circumcised! Savages!
  • (Score: 1) by FrankL on Monday April 25 2016, @01:58AM

    by FrankL (6216) on Monday April 25 2016, @01:58AM (#336792)

    Lots of DNS services allow only enough characters in the TXT record for a 1024-bit RSA keypair.

    That should be crackable these days with some scalable resources (e.g. AWS).

    Are there known up-to-date cost estimates for using public cloud to factor 1024-bit RSA?

    • (Score: 0) by Anonymous Coward on Monday April 25 2016, @02:04AM

      by Anonymous Coward on Monday April 25 2016, @02:04AM (#336793)

      That's not very plausible.

      Whatever it costs to factor his DKIM key, the return on using it to spam is orders of magnitude less.
      And if they had some other use for it, some double-top-secret-industrial-espionage kinda thing, then they would never have used it in a way that would have triggered google to classify his domain as a spam haven.

      • (Score: 1) by FrankL on Monday April 25 2016, @02:15AM

        by FrankL (6216) on Monday April 25 2016, @02:15AM (#336799)

        Your logic assumes it is very hard/expensive to factor 1024-bit.
        Do you have any numbers to back this up?

        A far better reason for this being unlikely, is that a spammer probably would go after 512-bit DKIM or 768-bit DKIM keys before factoring 1024.
        Unless big mail services now ignore 1024-bit DKIM key length in their spam detection...

        • (Score: 1) by FrankL on Monday April 25 2016, @02:17AM

          by FrankL (6216) on Monday April 25 2016, @02:17AM (#336802)

          'ignore 1024-bit' should read as: 'ignore key lengths shorter than 1024-bit, e.g. due to susceptibility to being factored'

        • (Score: 0) by Anonymous Coward on Monday April 25 2016, @03:10AM

          by Anonymous Coward on Monday April 25 2016, @03:10AM (#336813)

          > Your logic assumes it is very hard/expensive to factor 1024-bit.
          > Do you have any numbers to back this up?

          Your logic assumes it is feasible to factor a 1024-bit key.
          Do you have any numbers to back this up?

          I, in fact, do have numbers to back up my claim. But your response was so snotty and disingenuous that I will let you use google to figure out how absurdly expensive it would be.

          • (Score: 1) by FrankL on Monday April 25 2016, @06:12AM

            by FrankL (6216) on Monday April 25 2016, @06:12AM (#336858)

            so you respond to my sollicitation for a cost estimate, with that it would be 'a lot more expensive than the payoff from the spam' without providing any numbers or references, then do it again with a statement that it is 'absurdly expensive' and put the burden on backing up your claim on me?

            Very chique!

            You might very well be right, but pulling numbers from thin air is not advancing this discussion.
            The best I could find without spending too much time on searching is the "Factoring as a Service" paper by Valenta et al. that concludes that it takes 75 USD to factor 512-bit RSA. Would love to find estimates on 768 and 1024 bit RSA...

            • (Score: 4, Interesting) by stormwyrm on Monday April 25 2016, @08:24AM

              by stormwyrm (717) on Monday April 25 2016, @08:24AM (#336881) Journal

              1024-bit factoring is, as far as we know, still way out of reach. See here:

              http://security.stackexchange.com/questions/4518/how-to-estimate-the-time-needed-to-crack-rsa-encryption [stackexchange.com]
              http://web2.0calc.com/questions/how-long-would-it-take-to-break-a-rsa2048-key-on-one-computer-that-handles-2-4-billion-instructions-per-second#r4 [0calc.com]

              Judging from the RSA Factorization challenge, given that only the 768-bit challenges have been successful so far, I think factoring a 1024-bit key is probably still impossible within the next five to ten years or so, barring an unexpected development either in mathematical discoveries or quantum computing. The fastest known factoring algorithm for integers not in some special form is the General Number Field Sieve (GNFS), which was used in 2009 to factor RSA-768. The thing is, it seems that the GNFS isn't the sort of algorithm you can just compile the code for and feed a number into. There are three parts to it: the first is polynomial parameter selection, which is generally done these days by some smart number theorists with the aid of powerful computers. This part could conceivably be fully automated but it's obviously not that easy. Work is being done these days on parameter selection for 1024-bit numbers. There's also parts called sieving and linear reduction. The sieving portion is the easiest to parallelise, though it will also need plenty of memory. The linear reduction portion is infeasible today for anything above 768 bits though, because parallelising it isn't practical and it involves the manipulation of a massive matrix that requires terabytes of fast memory. The kind of hardware needed to that kind of computation just plain doesn't exist today, at least not as an off-the shelf commodity. The RSA-768 linear reduction matrix was 192 million rows x 192 million columns, just within reach of the technology of the time. The corresponding matrix for a 1024-bit integer factorisation would be perhaps some 4 billion x 4 billion. It will probably take something like five to ten years of advances in computing power before this part becomes practical.

              Doesn't mean that the NSA or some other intelligence agency couldn't do it though. They could conceivably spend several billion dollars on some crazy powerful supercomputer with the incredible quantities of memory needed that can do the linear reduction for a 1024-bit factorisation, but this estimate is just as much pulled out of thin air as the GP's numbers are.

              TL;DR: At this time, factoring a 1024-bit number is not doable on the hardware that is easily available today, so giving a price estimate as you ask is meaningless.

              --
              Numquam ponenda est pluralitas sine necessitate.
              • (Score: 1) by FrankL on Tuesday April 26 2016, @03:12AM

                by FrankL (6216) on Tuesday April 26 2016, @03:12AM (#337274)

                Thanks, I wasn't aware that RSA-768 was first known to be factored back in 2009;

                just found the paper by Kleinjung et al. ; very interesting!

                Are you active in the cryptography field?
                Is there a consensus among academics on the expected level of cryptography research by nation-state agencies, compared to the academic world?
                ...Are they expected to be somewhat ahead? (how many years?)

                The only example that I can remember on this is the 1973-1975 work done by the NSA to strengthen the S-box in DES.
                Of course, that's 40 years out of date today, so we'd need more recent examples to make inferences...

                • (Score: 2) by stormwyrm on Tuesday April 26 2016, @08:28AM

                  by stormwyrm (717) on Tuesday April 26 2016, @08:28AM (#337383) Journal

                  How far ahead intelligence agencies are beyond the open academic cryptographic community is difficult to estimate. We do know for instance that the NSA and IBM were already aware of differential cryptanalysis at least a decade or so before Eli Biham and Adi Shamir independently discovered it in the late 1980s: Don Coppersmith later revealed that the changes to the DES S-boxes were made to strengthen it against differential cryptanalysis when Biham and Shamir noticed that DES seemed to be so carefully tweaked to make their "new" technique all but useless against it. So in the eighties, they were at least twenty years ahead of the academic cryptographic community.

                  We haven't seen too many examples of the algorithms designed by the NSA. There are only a few such block ciphers known: Skipjack [wikipedia.org] and a pair of ciphers known as Simon and Speck [schneier.com]. The former was originally part of the controversial Clipper chip proposal and was declassified in 1998 [schneier.com] after they were forced to have to implement the Clipper chip algorithms in software. The latter two were published in 2013 and no one is sure why they did so. Skipjack is an interesting design, as it is an unbalanced Feistel network, similar to a design independently proposed by Bruce Schneier and Matt Blaze in 1994. The immediate heritage of Skipjack's design is said to date back to around 1980, so that would make the NSA about 14-15 years ahead of the academic cryptographic community back then.

                  For public key algorithms things are less certain. It's known that someone in GCHQ seems to have invented an algorithm that amounted to RSA in 1973, 4-5 years before Rivest, Shamir, and Adleman did so. The algorithm used for key exchange with the Clipper chip, known as KEA, was declassified along with Skipjack in 1998, and it is nothing weird, merely a variant of traditional Diffie-Hellman key exchange. No one knows if any of the still-classified public key and key exchange algorithms are anything really special.

                  I'm not really active in the cryptography field, just a programmer who has an abiding interest in cryptography and cryptanalysis. The most I've done professionally is implement a few algorithms for embedded systems, e.g. just before the AES contest ended I wound up coding Rijndael, which eventually won, for a small 8-bit microcontroller. I read Schneier's blog and follow developments in the field when I have the time.

                  --
                  Numquam ponenda est pluralitas sine necessitate.
            • (Score: 0) by Anonymous Coward on Monday April 25 2016, @12:05PM

              by Anonymous Coward on Monday April 25 2016, @12:05PM (#336914)

              > The best I could find without spending too much time on searching is the "Factoring as a Service" paper by Valenta et al. that concludes that it takes 75 USD to factor 512-bit RSA. Would love to find estimates on 768 and 1024 bit RSA...

              Gee, smug and stupid.

              Let me spell it out for you:

              If it costs $75 to factor 512-bit RSA then it costs $75 x 2^256 to factor 768 bits and $75 x 2^512 to factor 1024 bits.

              • (Score: 1) by FrankL on Tuesday April 26 2016, @03:21AM

                by FrankL (6216) on Tuesday April 26 2016, @03:21AM (#337278)

                another user (stormwyrm) just showed that 768-bit RSA was factored in 2009.

                You are implying that that would have cost more than $ 75 x 2^256 = 8.6 * 10^78 USD, disregarding the higher cost of computing resources in 2009.

                So the conclusion would then be that either 512-bit RSA can be factored much cheaper than 75 USD (maybe a few dollar cents)....

                OR.... that factorization does NOT scale the way you propose!

              • (Score: 0) by Anonymous Coward on Tuesday April 26 2016, @07:57AM

                by Anonymous Coward on Tuesday April 26 2016, @07:57AM (#337370)

                Your calculation is utterly bogus. You've presumed the cost to factor is exponential - to be precise, O(N) or O(2^D) where D=lg(N) is the size of the number N to be factored.

                That hasn't been the case *ever*. Even trial factoring is quicker than that, as you only need to trial divide by primes up to sqrt(N), so the cost of that is o(sqrt(N)/ln(N)). GNFS, like QS before it, is subexponential, and by the time you're at numbers of this size, the difference is immense.

                Here's a little bit of verification that your calculation is bogus - if 512 bit cost $75, then factoring 500 bits should cost 2c. Does it?

                FatPhil

        • (Score: 4, Interesting) by TheRaven on Monday April 25 2016, @08:48AM

          by TheRaven (270) on Monday April 25 2016, @08:48AM (#336886) Journal
          Think about the economics. What's the return on investment from sending spam? Let's say that you make £1000 in profit before the victim of the joe job notices and changes the key, above the profit that you would have made from using a brand-new domain that you just registered. That buys you about 1500 GPU hours from Amazon, but for it to be worthwhile you'd probably want to keep about half of that profit, so that gives you 750 hours of GPU time. Now the question becomes 'what is the biggest product of two primes that you can factor in 750 hours on a modern GPU?' From a quick search, it doesn't look as if even 768-bit keys are feasible within that budget.
          --
          sudo mod me up
  • (Score: 0) by Anonymous Coward on Monday April 25 2016, @02:36AM

    by Anonymous Coward on Monday April 25 2016, @02:36AM (#336807)

    if email were pull instaed of push technology then spam would clog the senders outbox harddisk until the email would be fetch.
    email innits present form needs to die a technological death but wont because it would mean financial death for some ...

    • (Score: 1, Interesting) by Anonymous Coward on Monday April 25 2016, @05:23AM

      by Anonymous Coward on Monday April 25 2016, @05:23AM (#336843)

      How would that work?

      Go online, ask the server for all your mail...

      Then it asks the servers up stream for all your mail, the spammer's server would contain one message that is destined for everyone, and the intermediary servers get clogged up with spam, just as they are today.

      The only way pull would fix spam is if it was also whitelist only, and whitelists are already an effective solution to spam, except you can't receive mail from unsolicited parties -- meaning that when you go register for an account somewhere, you first need to go and whitelist them in your email system before you sign up to receive the verification email. With push instead, at least you can add your whitelist entry later, and then recover the verification mail from your spam box.

    • (Score: 2) by maxwell demon on Monday April 25 2016, @06:41AM

      by maxwell demon (1608) on Monday April 25 2016, @06:41AM (#336861) Journal

      Sure … and when you write an email from your laptop you better make sure your laptop remains running and connected to the net until the mail is actually fetched. Because if you don't, the receiver might fail to get your mail.

      --
      The Tao of math: The numbers you can count are not the real numbers.
    • (Score: 0) by Anonymous Coward on Monday April 25 2016, @11:03AM

      by Anonymous Coward on Monday April 25 2016, @11:03AM (#336905)

      In a sense greylisting does this. It delays the email in a SMTP compliant way (forcing the mail to be stored at the sender for some time, before retried). A spammer wants to send out as much mail as possible, so keeping track of time is an extra burden for the spammer to take into account (which they often don't do). The catch... valid emails will be received with a small delay.

      • (Score: 0) by Anonymous Coward on Monday April 25 2016, @12:44PM

        by Anonymous Coward on Monday April 25 2016, @12:44PM (#336921)

        Greylisting doesn't work fantastically in my experience because a lot of the spam I get comes through either real SMTP relays that are fine with retrying, or the spam-generating botnet is content with opening so many connections, the server slows down anyway.

        Other people's misconfigured systems that don't retry mails and cause delivery failures are also an issue if your company is large enough and your partners are small/tech-illiterate enough...

    • (Score: 0) by Anonymous Coward on Monday April 25 2016, @07:15PM

      by Anonymous Coward on Monday April 25 2016, @07:15PM (#337046)

      Well thx for all the reply.
      it is assumed that the person wanting to use emails has his/her own internet connection on which the server would sit (st0p complaing about 3rd party snooping already).

      REAL! that internet connection connects you to each and every other internet connection!

      the two things that are absolutely required (and then some) is a internet connection (dynamic or static, whatever) and a "identity" or "name".

      thus one sends a text and the receiver only gets a notification.
      the content is still on the senders server and HDD.
      it is then up to intended recipient to go fetch (pull) the email .. or not.

      of course one could add some form of identity verification (of sender server) to disallow sender-spoofing -ala- self-signed certs with https.

      there's obviously not much knowledge about email "in the wild" as compared to say ... uhm ... setting up a lamp stack.

      also the hops-and-loops needed to jump through to get a simple system to send text from one ip to another is comparable to the obstacle course in boot camp.
      one must assume that a whole business system thrives around email which feeds quiet a few families through winters and life in general thus leading to the assumption that it is kept artificially difficult to setup ...

  • (Score: 0) by Anonymous Coward on Monday April 25 2016, @12:33PM

    by Anonymous Coward on Monday April 25 2016, @12:33PM (#336917)

    Google's filtering is almost entirely content-scanning based. This works great when you have lots of identical or similar emails to scan, but when each one is heavily customized and comes from a different source at a different time, the pattern is varied enough it doesn't work great.

    Google can and will remove these emails from your mail box if they figure it out later, though. I don't know if that's good or not...