ADMIN: spamming by "recruiters"
Dear list members; A "recruiter" going by the name of "Doug Kelly" (email address is [EMAIL PROTECTED] but headers indicate the use of what are euphemistically called "mass mailing services") appears to be mining our mailing list archives and systematically sending out unsolicited mass commercial mailings, AKA spam, to the harvested list. My attempts to explain proper behavior to this individual appear to have met with the usual sort of answer one gets in this sort of situation, vis: > What are you talking about with regard to spamdon't you recognize a job > opportunity when you see it I've already reported the problem to a few anti-spam services, but I would suggest that anyone who finds such behavior reprehensible take whatever action they deem appropriate. Sample relevant headers follow: Return-Path: <[EMAIL PROTECTED]> [...] Received: from www.advantagetel.com (mail.advantmail.com [66.70.107.240]) by gertrude.piermont.com (Postfix) with SMTP id EA8E479C12 for <[EMAIL PROTECTED]>; Sun, 12 Nov 2006 14:29:37 -0500 (EST) Received: (qmail 96877 invoked by uid 89); 12 Nov 2006 19:29:36 - Received: from unknown (HELO AST2) (207.150.189.2) by mail.xroadsmgmt.com with SMTP; 12 Nov 2006 19:29:36 - Reply-To: <[EMAIL PROTECTED]> From: "Doug Kelly" <[EMAIL PROTECTED]> [...] Your moderator, Perry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Citibank e-mail looks phishy
Citibank e-mail looks phishy http://www.zdnet.com.au/news/security/print.htm?TYPE=story&AT=339272126- 130061744t-11005c "A seemingly innocent e-mail from Citibank Australia introducing a new online banking process has been mistaken for a phishing attack. The e-mail was sent last month and described a new sign-on procedure that promised to be "even more secure". As part of a security upgrade, customers were asked to update their log-in credentials. The message also asked recipients to log on to the bank's Web site and authenticate themselves by entering their Citicard or credit card number, and ATM PIN (!!). The bank has a strict policy to safeguard customers from such scams. Its online security section says: "Customers should understand that Citibank will never send e-mails to customers to verify personal and/or account information... It is important you disregard and report e-mails which... request any customer information - including your ATM PIN or account details." A spokesperson for Citibank was surprised that the e-mail was confused for a possible scam and denied the bank had contradicted its security statements. "These are all online banking customers and are used to receiving e-mails from us. I don't believe we have contradicted ourselves ... there is only a link to the privacy policy and we always tell people to type in the URL". Citibank's technical and fraud departments will investigate the situation." carlos - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Can you keep a secret? This encrypted drive can...
On Mon, 6 Nov 2006, Derek Atkins wrote: >Quoting "Leichter, Jerry" <[EMAIL PROTECTED]>: >> Just wondering about this little piece. How did we get to 256-bit >> AES as a requirement? Just what threat out there justifies it? > It's a management requirement. The manager sees "AES128" and "AES256" > and thinks "256 must be better than 128" and therefore the edict comes > down that AES256 must be used. It's not a technical decision. It's > not a decision made by analyzing the threats. It's made purely > by assertion, but it's a decision that can't easily be refuted. Yep. When costs are equal (and in this case computing power is so cheap as to make that approximately true) any competent manager will always pick the method which is "superior" to the other in any way. The facts are that with AES128 or AES256, the cipher itself will *NOT* be the weakest link in security, so the theoretical superiority of AES256 doesn't matter much. Anybody who is making a serious attack will have to do pretty much exactly the same thing -- social engineering, rubberhose attack, subpoena, password guess, protocol flaw exploit, Van Eck monitor exploit, keyboard monitor, software backdoor exploit, DLL substitution attack, mem device exploit by a trojan running at the same time as the encryption software, audio interferometry to determine keystroke sequences, audio-frequency carrier wave interference from some metal thing in the same office as the transmitter vibrating to the voice that's being encrypted, etc... There's a million different links all weaker than the cipher itself. Conversely, it harms nothing to have them pick the stronger cipher, given that both ciphers are sufficiently strong that their strength has nothing to do with the mimimum effort required to attack their application. Bear - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
