[PLUG] what is the point of PGP-signed emails?

Zot O'Connor zot at whiteknighthackers.com
Wed Dec 10 02:01:01 UTC 2003


On Tue, 2003-12-09 at 21:17, Jason Van Cleve wrote:
> Quoth Zot O'Connor, on Tue, 09 Dec 2003 16:41:22 -0800:
> 
> > Does it matter how long?  As long as the time period is less than the
> > point in time when 100% of the mail is read by victims, then it works.
> 
> Er, if a spammer can pump out 100,000 ads in an hour, but it takes days
> to identify it, then "it works" doesn't mean much overall.

You are failing to understand:  "When sent", and even "when delivered"
is not the same as "when read/detected."  Not everyone reads all the
email within minutes of it being sent.  As stated below if the time
period is 2 hours, that may be faster than the email can be delivered.

> 
> > If you want, you can hold all unknown mail for a period of time (2
> > hours as a guess) until the peak time (when the spammer key is mostly
> > likely identified and has been reported to the razor-PGP servers).
> 
> Two hours for a process which may take two days?  Sounds like a lot of
> inconvenience just to break off a little corner of spam traffic, doesn't
> it?

Um, are you purposely taking things out of context, or am I not clear.

The above "days" was a maximum.  The 2 hours listed here is my guess as
to as to what the average peak time was (in other words, the best time
to hold email from a signed unknown, so that it is most likely that the
unknown spam account has been detected).

If I am not clear, I am sorry,  otherwise please stop juxtaposing unlike
values.


> > 1)  It forces them to send 1 mail per user.  This greatly increases
> > overheard *per* mail.  Most spammers still bulk send their mail.
> 
> > 2)  It makes them calculate keys per mail, and sigs per mail. Even
> > milliseconds adds up when we are talking millions of mails.
> 
> Why is that?  I thought only the body of the message is signed.
> 

Um, I am confused.  Yes, only the body of the email is signed, but it is
still a real value to run the key creation, signature calculation, and
signature attachment.

If you do not think so please test this.

Send 5 million emails on a LAN (a virtual catch all account should do
it).  It is all the same exact note, just the TO: field changes.

Now run the process that creates unique senders, keys, and signatures
for each of the mails.  See if it is negligible.



> > 3)  It may even make them have to keep those keys around.  If the
> > return contact is not via web/phone, they have a logistics issue.
> 
> Not sure what this means, sorry.  They'll be creating arbitrary keys
> just to get through filters.  The contact method won't change.
> 

Many of the Nigerian scams use the email for the return address.  Access
to those emails can be monitored but traces are easier to cleanse.  If a
key in involved, that key must be kept around at the scammers end (or
access to it).

> > 4)  All of these processes leave huge forensics trails.
> 
> How?  A single virus can be written to gen' keys and send spam from a
> compromised host.

And that process leaves a ton of information.  In this case it would
merely prove that the virus used that machine to generate the keys. 
While that makes for a great story, lots of spam is still generated on
within the spammers' machines.


> 
> > One of the main ways to attack spammer is to penny them to death.  The
> 
> Great theory, like charging everyone a fraction of a penny for each
> email sent.  Thing is, spam is sent anonymously from hijacked servers. 
> (RATs are generating a third of it, for example.)  So spammers won't
> really feel it.

Umm, you are taking the line out of context.  The point was to make each
email have a resource use that needs real time (milliseconds).  You and
I will not notice it, but even a virus will be impacted (as per the 5
million email examples above).  A monetary tax makes no sense since it
will not be billed to the right person or entity (though in general it
might make everyone must tighter about security, but that won't happen
for a while).


-- 
Zot O'Connor

http://www.ZotConsulting.com
http://www.WhiteKnightHackers.com





More information about the PLUG mailing list