quantum crypto rears its head again.

2006-12-13 Thread Perry E. Metzger

I saw this link on Slashdot (and it was also on Ekr's blog):

http://hackreport.net/2006/12/13/quantum-cryptography-its-some-kind-of-magiq/

It appears that the quantum crypto meme just won't go away.

Bob Gelfond of MagiQ promises us that for only $100,000, plus monthly
leasing of a dry fiber optic home run between your end systems, you
can have security that isn't even as good as what nearly free software
will give commodity computers over the unsecured public internet.

I wonder if this idea is ever going to die. My guess is it will, but
not until the people who have thrown away their money investing in
this technology go bankrupt.

-- 
Perry E. Metzger[EMAIL PROTECTED]

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


Re: cellphones as room bugs

2006-12-13 Thread John Levine
>8Kbit/second is enough if all you need is to understand what is being
>said, not recognize the speaker.  The processing power to do this is
>pretty small on today's scale of things.)

With decent compression techniques, 8kbps is close to telephone
quality, and 2400bps has artifacts but is still quite clear.  There
are some nice examples at:

http://www.data-compression.com/speech.shtml

1kbps would be adequate for understandable speech, so I would expect
that a modern phone with megabytes for music storage could easily
store several days of voice-activated room bugging.

R's,
John

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


randomness in space..

2006-12-13 Thread dan
http://news.zdnet.com/2100-1009_22-6142935.html?part=rss&tag=feed&subj=zdnn

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


Re: cellphones as room bugs

2006-12-13 Thread Leichter, Jerry
| Ian Farquhar (ifarquha) wrote> The other problem for this technique is
| battery life.
| 
| Suppose this worked by recording from mic to memory and then
| transmitting later. This leads to a bunch of questions:
| 
| By what factor could transmission time/power be reduced sending such a
| recording later? How many minutes could a typical phone buffer? How
| much does a typical conversation compress? Are such algorithms within
| the power of a typical phone's processor? How much power is used in
| recording to memory and compressing? Can transmission power
| requirements be reduced by transmitting when transmission power
| requirements are low? Can they be reduced often enough to make it
| worthwhile optimizing in this way?
It's tough to make any definitive statements, but note that there are
phones that hold a couple of hundred MP3-compressed songs.
Understandable speech takes much less than that.  (As I recall,
8Kbit/second is enough if all you need is to understand what is being
said, not recognize the speaker.  The processing power to do this is
pretty small on today's scale of things.)

If I were doing this, I'd transmit under two conditions:  A really close
cell tower (which allows you to crank the transmit power way down -
something phones do anyway) and, even better, while recharging.  The
latter would be particularly pernicious:  If you wait a couple of minutes
after the phone goes into the charger, it's highly unlikely anyone will
be looking at the phone, you can transmit without draining the battery,
and on most phones you won't even affect the charge time by all that
much - not that the victim is likely to notice, since most people have
no idea how long it actually takes to charge their phone:  They stick
it into the charger at some convenient time, and pull it out at some
later convenient time.

Another advantage the attacker has in this scenario is that he can
transmit when he can get away with it and reassemble the pieces at
leisure.  A normal phone conversation has to be done in one long
stretch, which forces the phone to continue to receive in and transmit
even when conditions are highly unfavorable.  You could combine with
with lower-than-normal transmit power, on the assumption that the
receiver could request a resend to fix up garbled data.

-- Jerry

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