Re: cellphones as room bugs
On Sun, 3 Dec 2006 20:26:07 -0500 Thor Lancelot Simon <[EMAIL PROTECTED]> wrote: > On Sat, Dec 02, 2006 at 05:15:02PM -0500, John Ioannidis wrote: > > On Sat, Dec 02, 2006 at 10:21:57AM -0500, Perry E. Metzger wrote: > > > > > > Quoting: > > > > > >The FBI appears to have begun using a novel form of electronic > > >surveillance in criminal investigations: remotely activating a > > >mobile phone's microphone and using it to eavesdrop on nearby > > >conversations. > > > > Not very novel; ISDN phones, all sorts of digital-PBX phones, and > > now VoIP phones, have this "feature" (in the sense that, since > > there is no physical on-hook switch (except for the phones in > > Sandia and other such places), it's the PBX that controls whether > > the mike goes on or not). > > 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? > I don't recall if it's Q.931 per se, as much as the CO. Or rather, I know for certain that various government security agencies were quite unhappy about ISDN phones with speakerphone capability being deployed in sensitive sites. The speaker button was not, as I understood it, a hard button; it was a soft button that the switch responded to. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cellphones as room bugs
At 10:21 AM 12/2/2006 -0500, Perry E. Metzger wrote: Quoting: The FBI appears to have begun using a novel form of electronic surveillance in criminal investigations: remotely activating a mobile phone's microphone and using it to eavesdrop on nearby conversations. The technique is called a "roving bug," and was approved by top U.S. Department of Justice officials for use against members of a New York organized crime family who were wary of conventional surveillance techniques such as tailing a suspect or wiretapping him. http://news.com.com/2100-1029_3-6140191.html Cellphones maintain contact with cell towers, so they can be roughly tracked on the ground too, even when you are not talking. With GPS being embedded this may become much more accurate. As an amusing aside, for a while someone was accidently calling my land line with their cell phone. You could hear them driving around, with the usual car noises, and sometimes the radio on too. Occasionally I heard them in conversation with someone else. This went on for months. - Alex -- Alex Alten [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cellphones as room bugs
Thor Lancelot Simon <[EMAIL PROTECTED]> writes: >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? You make use of the undocumented remote management interface [0]. Peter. [0] Buffer overflow bug in the packet header parsing code. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
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]
Re: cellphones as room bugs
On Sun, Dec 03, 2006 at 09:26:15PM -0600, Taral wrote: > That's the same question I have. I don't remember seeing anything in > the GSM standard that would allow this either. > I'll hazard a guess: mobile providers can send a special type of message (not sure if it would be classed as an SMS) with various settings for your phone. They do that, for example, to set the GPRS settings. IN many phones, one of the possible settings is to automatically answer the phone, without ringing (the feature is used in some of the hands-free settings). The user would probably notice that the phone is in use, but there may be some other trick around that. /ji - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Can you keep a secret? This encrypted drive can...
Compared to AES-128, AES-256 is 140% of the rounds to encrypt 200% as much data. So when implemented in hardware, AES-256 is substantially faster. Excuse me, AES-256 has the same block size as AES-128, that is 128 bits. It's in fact slower, not faster, and in hardware it also occupies a substantially larger area. If you are talking about Rijndael with 256-bit blocks, that's not AES and its variant with 256-bit keys would still be slower and would also occupy a substantially larger area in hardware than its counterpart with 128-bit keys. Ruptor - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Can you keep a secret? This encrypted drive can...
On Sun, 3 Dec 2006, David Johnston wrote: > > Moreover, AES-256 is 20-ish percent slower than AES-128. > Compared to AES-128, AES-256 is 140% of the rounds to encrypt 200% as > much data. So when implemented in hardware, AES-256 is substantially faster. AES-256 means AES with 128-bit block and 256-bit key, so AES-256 encrypts the same amount of data as AES-128. As of hardware implementation, one can use several engines in parallel, although even a single one can be faster than needed, for example, with 280 MHz there are 2e7 blocks per second, that is 320 Mbyte per second. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
"Verified by VISA" looks phishy
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]
Re: [-SPAM-] Re: Can you keep a secret? This encrypted drive can...
David Johnston wrote: > Jon Callas wrote: >> >> >> Moreover, AES-256 is 20-ish percent slower than AES-128. > Compared to AES-128, AES-256 is 140% of the rounds to encrypt 200% as > much data. So when implemented in hardware, AES-256 is substantially > faster. AES-256 does not encrypt any more data per round than AES-128. My guess is that you are thinking about Rijndael with a 256 bit block and a 256 bit key. Brian Gladman - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Can you keep a secret? This encrypted drive can...
Leichter, Jerry wrote: | Jon Callas wrote: | > | > | > Moreover, AES-256 is 20-ish percent slower than AES-128. | Compared to AES-128, AES-256 is 140% of the rounds to encrypt 200% as much | data. AES-256 has a 256-bit key but exactly the same 128-bit block as AES-128 (and AES-192, for that matter). | So when implemented in hardware, AES-256 is substantially faster. | | AES-256 - 18.26 bits per round | AES-128 - 12.8 bits per round | | I imagine that this would matter when the implementation is in a hard disk or | disk interface. It would, if it were true. -- Jerry I stand corrected.. The source of my error was reading the rijndael spec, not the nist spec. DJ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
