RE: cellphones as room bugs

2006-12-05 Thread Ian Farquhar (ifarquha)
The other problem for this technique is battery life.

Let's assume we can shove a firmware update/hack/whatever into the phone to 
enable snooping, it's still transmitting when acting
as a bug.  Even if this feature is only enabled when the phone is geolocated 
somewhere interesting, the reduction in battery
life is going to be significant.  If your phone has a standby time of days, and 
you're used to shoving it on the charger rarely,
then suddenly you're doing it several times a day, you're going to notice.  
Even if you are the dumb, stupid criminal the
government likes to tell us that surveillance always catches.

I suppose that it could be argued that you could use silence detection etc. to 
reduce power used, but most phones are pretty
aggressive at power saving already.  I doubt there are huge savings to be made 
which haven't been implemented already.

Ian.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Taral
Sent: Monday, 4 December 2006 2:26 PM
To: [EMAIL PROTECTED]
Cc: John Ioannidis; cryptography@metzdowd.com
Subject: Re: cellphones as room bugs

On 12/3/06, Thor Lancelot Simon [EMAIL PROTECTED] wrote:
 It's been a while since I built ISDN equipment but I do not think this 
 is correct: can you show me how, exactly, one uses Q.931 to instruct 
 the other endpoint to go off-hook?

That's the same question I have. I don't remember seeing anything in the GSM 
standard that would allow this either.

--
Taral [EMAIL PROTECTED]
You can't prove anything.
-- Gödel's Incompetence Theorem

-
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: Can you keep a secret? This encrypted drive can...

2006-12-05 Thread Jon Callas

I just ran a speed test on my laptop. Here are some relevant excerpts:

CipherKey Size  Block Size  Enc KB/sec  Dec KB/sec
    --  --  --
IDEA  128 bits   8 bytes  24032.0924030.66
3DES  192 bits   8 bytes  10387.6710399.30
CAST5 128 bits   8 bytes  29331.1729459.49
Twofish   256 bits  16 bytes  20233.6319185.82
AES-128   128 bits  16 bytes  44100.2346266.98
AES-192   192 bits  16 bytes  39731.3341228.87
AES-256   256 bits  16 bytes  36017.9537302.43
Blowfish  128 bits   8 bytes  35347.3438311.22

Comparing AES-128 and AES-256, encrypt speed is 1.2243959x and  
decrypt is 1.2403208x. So that makes my lick-your-finger-and-stick-it- 
in-the-wind rule of thumb of 20% slower okay. I'll try to say 20-25%  
in the future.


Of course, though, implementation matters a lot. I'm running a PPC-32  
machine. You'll get different answers on an ia32, and different ones  
an AMD64.


Jon

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Verified by VISA looks phishy

2006-12-05 Thread Jon Barber

Yes, the whole Verified By Visa / Mastercard SecureCode initiative has
been handled very badly by the banks. I work at a very large travel
dotcom based in the UK, in the team that looks after the shopping basket
and payments. We were one of the first sites to add support for 3D
secure (the umbrella term for this) and we have quite a bit of customer
feedback pretty much along the lines of what you say. 

The banks response is, more or less, tough. Furthermore when asked about
promotional campaigns to educate the customers as to what this all means
and not to get spooked the response was again, e, why don't you do
it. 

For vendors the stick that the banks wield is fraud  chargebacks - if a
vendor site does not support 3D secure then the vendor is penalised when
credit card fraud occurs. If the vendor does support 3D secure then the
bank will stand the cost of fraud. With current trends for card fraud
this is a very large incentive.

Jon.

On Mon, 4 Dec 2006 16:18:35 +0400, Alan Barrett [EMAIL PROTECTED]
said:
 I tried to renew a domain name registration and pay by credit card,
 and encountered a nasty problem with (some implementations of?) a
 service called Verified by VISA, which is nominally intended to secure
 Internet credit card transactions.
 
 The domain name registrar asked what domains I wanted to renew, and
 redirected my browser to a third party credit card payment service.  So
 far so good: the domain name registrar told me you will be redirected
 to ${PAYMENT_SERVICE}.
 
 The payment service confirmed the amount to be paid, asked
 for my credit card number and a few other details, and told
 me that I would be redirected to my bank to confirm my PIN
 number.  But I was not redirected to my bank, I was redirected to
 https://${some_string_resembling_the_name_of_my_bank}.bankserv.co.za.
 The bankserv.co.za web site claimed to be part of a system called
 Verified by VISA, and asked me for the PIN that I use for ATM
 transactions with my credit card.
 
 The problems with this include:
 
   1) Locating the verification web site at a domain name not associated
  with the bank looks phishy.
 
   2) Telling customers not to worry about (1) trains them to be more
  vulnerable to phishing.
 
   3) Providing both the ATM PIN and the card number to the verification
  web site enables fraud by insiders, is possibly a violation of the
  cardholder's contractual requirement to keep the PIN secret, and is
  a violation of the ordinary prudent desire to keep the PIN secret.
 
   4) Telling customers not to worry about (3) trains them to take less
  good care of their PIN.
 
 I phoned my bank, and talked to somebody who could not understand
 the problem: See the lock icon?  That means its secure.  I have
 subsequently tried to explain the problem to the bank via email.  I
 asked them to: use the bank's domain name, not bankserv.co.za; use a
 unique PIN instead of re-using the ATM PIN; use one time passwords
 instead of PINs.  I haven't had a response to my suggestions.
 
 --apb (Alan Barrett)
 
 -
 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: Verified by VISA looks phishy

2006-12-05 Thread Peter Gutmann
Alan Barrett [EMAIL PROTECTED] writes:

The bankserv.co.za web site claimed to be part of a system called Verified
by VISA, and asked me for the PIN that I use for ATM transactions with my
credit card.

Verified by VISA was something that Visa came up with after being burned by
SET.  Instead of Visa having to go through the pain of coming up with and
deploying a secure system, they outsourced it.  The idea is that third-party
payment processors come up with whatever Rube Goldberg security scheme they
like, produce enough paperwork to overwhelm Visa's auditors, and then it gets
the Verified by Visa stamp of approval (and no, I'm not kidding about that
process).

I phoned my bank, and talked to somebody who could not understand the
problem: See the lock icon?  That means its secure.

Yep, that's about the level of some of the Verified by Visa stuff I've seen.

(I'm sure they're not all that bad, but the few I've seen have been security
by handwaving and excessive production of paperwork.  The scary thing is that
there are probably quite good ones that didn't make the cut because they
couldn't produce enough paperwork).

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]