Yes, the idea is the person at the other end has the list of serial numbers. In all these examples the purpose of encrypting it is to send it to another person, not to store the info so you can decode it yourself later. Sorry about any confusion.
That's called a book code and it's still breakable,
because different letters in the words in a book
aren't randomly distributed. See Kahn's "The Codebreakers" for more info on how to break these systems. Ken Follett's spy novel "The Key To Rebecca" is also about breaking such a code.
In WW2 and the 60's, breaking book codes was difficult but not impossible. Today, if the attacker has the text of your book in a computer (he doesn't have to know which book it is, he just needs a big library of online books that includes yours), book codes are probably quite weak.
Stage 5 of Simon Singh's
cipher challenge was also a book code. It turned out
to be possibly the hardest of all 10 stages.
But even though
the message was just a few dozen characters long
(and turned out to be written in Spanish),
several people managed to solve it.
If you want to purchase a Zaurus unit, you're stuck at the $499 pricepoint and cannot get any more or less advanced units, no matter what.
Actually there's the developer version with 32MB instead of 64MB of ram. I just got one for $199 at the Java One conference where they were selling them. I think they're more over the web, but still less than $499.
You listed the iPAQ as having 64 MBs of memory. You neglected to mention that it also has a 32 MB flash rom.
The Zaurus also has flash rom, I'm not sure how much but probably a comparable amount.
With the Zaurus, you are locked into CompactFlash and the comparitively useless SD card. Sure, it's a little bit extra, but I'll stick with my PC card expandibility.The SD card isn't useless. It lets you put expansion flash (128 MB SD cards are available) in the SD slot and have the CF slot free for a modem or network card, without needing any bulky sleeves. The iPaq sleeve system is kind of cool but if you use the full sized PCMCIA version (especially the two slot one) and the external keyboard, you're heading toward the bulk of a small laptop. I just don't see much point to that.
You are also correct in mentioning that the Zaurus does not come with a microphone or speaker, and the iPAQ comes equipped with both.
I think it's unfortunate that the Zaurus has no mic or speaker, however it has a mic input port which the iPaq lacks. The iPaq's internal mic is not very good and it's a real deficiency that you can't use an external mic with the iPaq. The Zaurus lets you use an external mic including a cellular phone headset mic. If you want to do speech processing applications (that's why I bought the Z and the iPaq) then a headset mic is a better input method than having to hold the PDA up to your face to talk into it. So I'd have to say the Z's approach is (for my purposes) preferable to the iPaq's. Of course I'd prefer to have a built-in mic and speaker and external jacks, but if I have to choose one or the other, there's a fairly good argument for external-only.
It has a fairly loud buzzer/beeper for alarms and stuff. I agree that a speaker would have been better, and I'd have also liked a built-in mic, but for the purposes you mention the beeper works ok.
I don't think a Palm Pilot has a speaker (as opposed to a beeper) either, FWIW.
Are there detailed instructions anywhere on how
to do this? Last I checked, the standard Familiar
distribution didn't work on the 3150 and you need
to build a custom kernel. I have a 3150 that I
bought with the intention of installing Linux but
never got around to it because it was such a pain
in the neck. I just got a Zaurus SL5000D (the
developer version of the 5500D) for $199 at Java
One so the Ipaq is less interesting now, but it would still be good to get rid of that damn WinCE.
Get a big compilation source code CD like the Yggdrasil Internet archives, or even a regular Red Hat source cd. Then run a script which unpacks the zip files as needed, and greps for some sample strings from the code.
Also, you might paste a few lines into a comment on this thread and see if anyone recognizes it.
Check the RC4 algorithm, which normally is done on a 256-element vector so we'll call it RC4-256.
It's pretty obvious that you can use vector sizes different from 256. For example, you can do RC4-52 with a deck of cards face up on a table (4 rows of 13 so you have to do arithmetic in your head mod 13 and 4 on the cards and suits--you figure out the details). Or you can do RC4-99 (9x11 grid) or maybe RC4-100 (10x10 grid) with pencil, paper, and eraser.
Then as several people mentioned, there's always the one-time pad. If you want to encrypt just one or two very short messages (total a few dozen characters or less), one innocuous way to carry the pad is as a wad of cash (I mean just a normal quantity of $1 and $5 bills in your wallet, not a suspicious roll of $50's and $100's). Use the serial numbers as the pad and spend the bills when you're done with them.
Forget public key. Public key cryptography in any known form is impossible without a programmable device. The calculations are just too cumbersome to do by hand. Anyway, public key probably isn't too useful in this situation. Public key solves the "n**2 problem" when a bunch of independent mutually distrustful peers are all trying to talk to each other--you only need one secret per person, instead of n**2 different secrets. For pencil and paper ciphers you're probably only communicating with trusted peers, so a shared secret is ok.
Of course if you have even a crude programmable device like a pocket organizer (even some of the ones much less fancy than a Palm Pilot) or a Java-enabled cellular phone, you can run all the usual computer cryptography algorithms on it.
Do you have to plug in the mic, record, then unplug
the mic and plug in a headphone in order to listen
to what you recorded? What a pain, if true. I wonder if you can use a Y adapter to plug in the headphone and mic simultaneously (even if you can't use them full duplex--I don't see how you could).
I begin to wish they'd left out the slide-out keyboard and put in normal audio hardware (built in mic and speaker plus the jacks). The keyboard is a little faster to enter text with than the on-screen keyboard, but the keys are stiff enough that it's more effort, so I use the on-screen one.
The 802.11 card was $100 extra, not such a great deal. I bought mine for $199 without the card.
Note that it's the
developer version (SL-5000D) not the retail SL-5500D.
The main difference I can notice is the dev. version has 32M of RAM and the retail version has 64M.
I got the developer version of this machine for $199 at Java One last week. Specs and info are at
developer.sharpsec.com.
The thing is nice, though not the hacker's dream that I hoped for. For example, the apps are rough around the edges and source code for them doesn't seem to be available.
My biggest gripe about the hardware is the stylus is too small. I'm using an iPaq stylus with it which is a lot better.
Also, it's not clear whether there's audio input. There's a voice recorder program that says plug in a mono mic with 3.5mm plug, but there's only one jack that size and it's intended for stereo headphones. I've never heard of multiplexing a jack between headphones and a mic. I'll try it with a mic but I think the software and docs were written for some different piece of hardware.
They spun rats at 3g for quite a long time (weeks or months, maybe even from birth--I don't remember). The rats came out as super-rats, with much stronger muscles than normal rats. Meanwhile, astronauts who spent long periods weightless lost muscle mass. It was sort of embarassing for space buffs who thought zero g would be good for you--it's sort of the opposite.
So this experiment sounds cool. I'd look into signing up except I'm over the height limit.
Just some specific problems like factoring.
For GENERAL brute force search type problems
the speedup is as I described. See the articles
at qubit.org for more info.
Quantum computing could conceivably obsolete public key (asymmetric) cryptography. However it doesn't break conventional cryptography. A sufficiently strong quantum computer can turn an O(f(n)) computation into O(f(sqrt(n)) but that's all. For example, it could break a 56-bit key in 2**28 steps instead of 2**56 steps. That means 128-bit keys could conceivably be broken by quantum computers (in 2**64 steps). However, by doubling the key length (say to 256 bits) you get the security against quantum computers that you now get against conventional computers.
I think/.'s criticism misses the point of what a corporate security officer does. This guy's job had nothing to do with bugs in Windows. Security officiers are generally not programmers or techies. They don't know anything about elliptic curve encryption or SYN cookies.
Most large companies have security officers. They usually come from a law enforcement or military background. When you see the title "security officer", think Lieutenant Worf, not Wesley Crusher. The security officer is usually in charge of physical plant security, of running background checks on incoming employees, making sure the guards at the parking lot entrance check the right ID's, etc. Their involvement with computers may reach as far as directing that the company firewall filter out incoming.exe email attachments, and that everyone's PC runs a daily virus scan.
As far as I know, Microsoft didn't have serious problems of that nature, and that guy did perfectly well at his job. The pinhead marketroids who put all the vulnerabilities into Outlook were in a completely different jurisdiction, so to speak. So I don't have a problem with his going to work for the white house.
I don't think jpeg 2000 is going to replace jpeg on a wide scale. I don't know about the lossless mode but j2k's lossy compression advantage over jpg isn't as big as many people think. A lot of it comes from using arithmetic coding by default. jpg supports arithmetic coding as an option, but it's normally not used, because of the IBM patents on arithmetic coding. If you enable arithmetic coding with regular jpg, it compresses almost as much as j2k for the same image quality. Yes, j2k is an improvement, but not enough of one to switch away from a totally pervasive, royalty-free standard.
The principle of the "full disclosure" movement is that once a bug is known to attackers (black hats), it's best to publish it, so users can take countermeasures; and since black hats find out about things quickly no matter what you do, it's best to publish immediately or almost immediately. The more traditional (and basically failed) view is to keep things secret from regular users in order to prevent black hats from finding out. Optimally, black hats never learn the bug, but that's extremely risky to rely on in practice.
Full disclosure instead avoids the pessimal
situation, where regular users don't know they're
vulnerable, but black hats do know.
Mozilla's policy tries to strike a balance by keeping the bug temporarily under wraps, and disclosing it once there's a way to deal with it. This is a reasonable idea. How will it be implemented?
1. There will be this big mailing list (the security group) notified of all security bugs.
It will have dozens or hundreds of people, and it sounds like it will be sent by unencrypted email. Of course that's inherently insecure. It's implausible to me that this mailing list won't quickly find itself gatewayed to a black hat list, either by being intercepted somehow or by a black hat managing to get on it. Even if the mail
isn't systematically forwarded, there's a saying
that once 3 people know something, it's not a
secret. So if dozens or hundreds know about a bug, the black hats know it.
2. The idea of mozilla.org staff serving as a court of last resort for disputes about whether to disclose a bug sounds hopelessly naive for anyone used to the dynamics of large mailing lists. If there's a dispute about whether to disclose a bug and an argument breaks out, someone will press the button to disclose the bug before it ever reaches any kind of "court". That will end the disclosure question, though recriminations may begin at that point.
3. Sooner or later someone is likely to push a button to disclose all the outstanding bugs. There will be a big ruckus, the discloser will get booted from the list, hell may break loose with exploits, but eventually things will get back to normal. Sooner or later, the process
will repeat.
Maybe I'm being cynical and the security group
will be more mature than I've described, but
I'll believe it when I see it.
The development cert never lets you download
code with no dialog. Under IE, you get a scary
dialog with no verifiable cert. With a verifiable
cert you get a non-scary dialog with a check box
saying to not ask again next time code comes
from this developer. Under Netscape, there
are also two dialogs that function the same
way, but both use scary wording.
To say the wording should always be scary (i.e.
that Netscape did the right thing) is right from
a security standpoint, wrong from a user
acceptance standpoint. We know perfectly well
by now which side Microsoft is on. From a
developer's point of view the Netscape approach
is a pain in the neck because you have to put
in an extra screen telling the user to click
"yes" to permit the download (but if you tell
them to click yes, then they do so, which means
the scary words don't really add security).
I notice that someone from the American
Committee for Interoperable Systems is
listed as a "Counsel for Amicus Curiae on
behalf of Plaintiffs-Respondents".
That seems to say that the interoperable systems
committee is on the side wanting to stop
DeCSS. I thought the whole point of DeCSS
was to promote interoperability.
I guess it must be one of those "1984" things.
War is peace, freedom is slavery, interoperability
is DVDCCA restrictions. And the American
Committee for Interoperable Systems must be
something like the Ministry of Love.
Developer certs are for signing code, not web
sites. If you download (e.g.) a service pack
from Microsoft and click "Properties" on the
file, you'll see a tab that says "Digital
Certificates". The cert that signs those things
is a developer cert. The tools used for
creating and signing the files are totally
different from what's used for SSL certs.
You could in principle generate the certs
with OpenSSL, but the method you proposed
won't work (you need special identifiers in
the certs).
What developer certs let you down is put ActiveX
controls on your web pages that the user can
download without going through a scary dialog
saying "the browser can't tell who created this
file". You do get a dialog saying "This file
was created by so-and-so, click 'yes' if you
trust them" but that dialog is designed to not
be scary, and encourage the user to download
whatever crap is about to take over his computer.
There are also developer certs for signed objects
in Netscape browsers, but not too many people
care about those any more.:(
in languages like Java. (Don't say do it with
threads. Performance will be abysmal. Remember
that it's supposed to be legitimate Scheme style
to use continuations anywhere other languages
would use gotos, loops, or even ordinary function
calls, not just fancy constructs like coroutines.
Slashdot Mirror
Yes, the idea is the person at the other end has the list of serial numbers. In all these examples the purpose of encrypting it is to send it to another person, not to store the info so you can decode it yourself later. Sorry about any confusion.
In WW2 and the 60's, breaking book codes was difficult but not impossible. Today, if the attacker has the text of your book in a computer (he doesn't have to know which book it is, he just needs a big library of online books that includes yours), book codes are probably quite weak.
Stage 5 of Simon Singh's cipher challenge was also a book code. It turned out to be possibly the hardest of all 10 stages. But even though the message was just a few dozen characters long (and turned out to be written in Spanish), several people managed to solve it.
Actually there's the developer version with 32MB instead of 64MB of ram. I just got one for $199 at the Java One conference where they were selling them. I think they're more over the web, but still less than $499.
You listed the iPAQ as having 64 MBs of memory. You neglected to mention that it also has a 32 MB flash rom.
The Zaurus also has flash rom, I'm not sure how much but probably a comparable amount.
With the Zaurus, you are locked into CompactFlash and the comparitively useless SD card. Sure, it's a little bit extra, but I'll stick with my PC card expandibility.The SD card isn't useless. It lets you put expansion flash (128 MB SD cards are available) in the SD slot and have the CF slot free for a modem or network card, without needing any bulky sleeves. The iPaq sleeve system is kind of cool but if you use the full sized PCMCIA version (especially the two slot one) and the external keyboard, you're heading toward the bulk of a small laptop. I just don't see much point to that.
You are also correct in mentioning that the Zaurus does not come with a microphone or speaker, and the iPAQ comes equipped with both.
I think it's unfortunate that the Zaurus has no mic or speaker, however it has a mic input port which the iPaq lacks. The iPaq's internal mic is not very good and it's a real deficiency that you can't use an external mic with the iPaq. The Zaurus lets you use an external mic including a cellular phone headset mic. If you want to do speech processing applications (that's why I bought the Z and the iPaq) then a headset mic is a better input method than having to hold the PDA up to your face to talk into it. So I'd have to say the Z's approach is (for my purposes) preferable to the iPaq's. Of course I'd prefer to have a built-in mic and speaker and external jacks, but if I have to choose one or the other, there's a fairly good argument for external-only.
I don't think a Palm Pilot has a speaker (as opposed to a beeper) either, FWIW.
Thanks.
Also, you might paste a few lines into a comment on this thread and see if anyone recognizes it.
It's pretty obvious that you can use vector sizes different from 256. For example, you can do RC4-52 with a deck of cards face up on a table (4 rows of 13 so you have to do arithmetic in your head mod 13 and 4 on the cards and suits--you figure out the details). Or you can do RC4-99 (9x11 grid) or maybe RC4-100 (10x10 grid) with pencil, paper, and eraser.
Then as several people mentioned, there's always the one-time pad. If you want to encrypt just one or two very short messages (total a few dozen characters or less), one innocuous way to carry the pad is as a wad of cash (I mean just a normal quantity of $1 and $5 bills in your wallet, not a suspicious roll of $50's and $100's). Use the serial numbers as the pad and spend the bills when you're done with them.
Forget public key. Public key cryptography in any known form is impossible without a programmable device. The calculations are just too cumbersome to do by hand. Anyway, public key probably isn't too useful in this situation. Public key solves the "n**2 problem" when a bunch of independent mutually distrustful peers are all trying to talk to each other--you only need one secret per person, instead of n**2 different secrets. For pencil and paper ciphers you're probably only communicating with trusted peers, so a shared secret is ok.
Of course if you have even a crude programmable device like a pocket organizer (even some of the ones much less fancy than a Palm Pilot) or a Java-enabled cellular phone, you can run all the usual computer cryptography algorithms on it.
and I don't think you can plug a headphone into a cell phone. The plug is the wrong size. Interesting thought though.
Do you have to plug in the mic, record, then unplug the mic and plug in a headphone in order to listen to what you recorded? What a pain, if true. I wonder if you can use a Y adapter to plug in the headphone and mic simultaneously (even if you can't use them full duplex--I don't see how you could).
I begin to wish they'd left out the slide-out keyboard and put in normal audio hardware (built in mic and speaker plus the jacks). The keyboard is a little faster to enter text with than the on-screen keyboard, but the keys are stiff enough that it's more effort, so I use the on-screen one.
Note that it's the developer version (SL-5000D) not the retail SL-5500D. The main difference I can notice is the dev. version has 32M of RAM and the retail version has 64M.
The thing is nice, though not the hacker's dream that I hoped for. For example, the apps are rough around the edges and source code for them doesn't seem to be available.
My biggest gripe about the hardware is the stylus is too small. I'm using an iPaq stylus with it which is a lot better.
Also, it's not clear whether there's audio input. There's a voice recorder program that says plug in a mono mic with 3.5mm plug, but there's only one jack that size and it's intended for stereo headphones. I've never heard of multiplexing a jack between headphones and a mic. I'll try it with a mic but I think the software and docs were written for some different piece of hardware.
So this experiment sounds cool. I'd look into signing up except I'm over the height limit.
Just some specific problems like factoring.
For GENERAL brute force search type problems
the speedup is as I described. See the articles
at qubit.org for more info.
Quantum computing could conceivably obsolete public key (asymmetric) cryptography. However it doesn't break conventional cryptography. A sufficiently strong quantum computer can turn an O(f(n)) computation into O(f(sqrt(n)) but that's all. For example, it could break a 56-bit key in 2**28 steps instead of 2**56 steps. That means 128-bit keys could conceivably be broken by quantum computers (in 2**64 steps). However, by doubling the key length (say to 256 bits) you get the security against quantum computers that you now get against conventional computers.
DVD media is about $6 per 4.7GB disk now, but do you really want to use 20 pieces of media to back up a 100 GB disk?
One thing some people do is back up their HD to a second HD.
Zip disks seem practically useless these days--recordable CD is just too cheap and universal by comparison.
Tape drives are the high-end solution, but expensive.
use something called "adult check" that works like that. I guess it's successful. I haven't tried it, thank you.
I think /.'s criticism misses the point of what a corporate security officer does. This guy's job had nothing to do with bugs in Windows. Security officiers are generally not programmers or techies. They don't know anything about elliptic curve encryption or SYN cookies.
.exe email attachments, and that everyone's PC runs a daily virus scan.
Most large companies have security officers. They usually come from a law enforcement or military background. When you see the title "security officer", think Lieutenant Worf, not Wesley Crusher. The security officer is usually in charge of physical plant security, of running background checks on incoming employees, making sure the guards at the parking lot entrance check the right ID's, etc. Their involvement with computers may reach as far as directing that the company firewall filter out incoming
As far as I know, Microsoft didn't have serious problems of that nature, and that guy did perfectly well at his job. The pinhead marketroids who put all the vulnerabilities into Outlook were in a completely different jurisdiction, so to speak. So I don't have a problem with his going to work for the white house.
Chroma key has been used for compositing video images for decades. This alpha transparency thing sounds similar.
I don't think jpeg 2000 is going to replace jpeg on a wide scale. I don't know about the lossless mode but j2k's lossy compression advantage over jpg isn't as big as many people think. A lot of it comes from using arithmetic coding by default. jpg supports arithmetic coding as an option, but it's normally not used, because of the IBM patents on arithmetic coding. If you enable arithmetic coding with regular jpg, it compresses almost as much as j2k for the same image quality. Yes, j2k is an improvement, but not enough of one to switch away from a totally pervasive, royalty-free standard.
1.A robot may not injure a human being, or, through inaction, allow a human being to come to harm.
2.A robot must obey the orders given it by human beings except where such orders would conflict with the First Law.
3.A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.
I'm not sure if that makes me feel any better.
Mozilla's policy tries to strike a balance by keeping the bug temporarily under wraps, and disclosing it once there's a way to deal with it. This is a reasonable idea. How will it be implemented?
1. There will be this big mailing list (the security group) notified of all security bugs. It will have dozens or hundreds of people, and it sounds like it will be sent by unencrypted email. Of course that's inherently insecure. It's implausible to me that this mailing list won't quickly find itself gatewayed to a black hat list, either by being intercepted somehow or by a black hat managing to get on it. Even if the mail isn't systematically forwarded, there's a saying that once 3 people know something, it's not a secret. So if dozens or hundreds know about a bug, the black hats know it.
2. The idea of mozilla.org staff serving as a court of last resort for disputes about whether to disclose a bug sounds hopelessly naive for anyone used to the dynamics of large mailing lists. If there's a dispute about whether to disclose a bug and an argument breaks out, someone will press the button to disclose the bug before it ever reaches any kind of "court". That will end the disclosure question, though recriminations may begin at that point.
3. Sooner or later someone is likely to push a button to disclose all the outstanding bugs. There will be a big ruckus, the discloser will get booted from the list, hell may break loose with exploits, but eventually things will get back to normal. Sooner or later, the process will repeat.
Maybe I'm being cynical and the security group will be more mature than I've described, but I'll believe it when I see it.
To say the wording should always be scary (i.e. that Netscape did the right thing) is right from a security standpoint, wrong from a user acceptance standpoint. We know perfectly well by now which side Microsoft is on. From a developer's point of view the Netscape approach is a pain in the neck because you have to put in an extra screen telling the user to click "yes" to permit the download (but if you tell them to click yes, then they do so, which means the scary words don't really add security).
That seems to say that the interoperable systems committee is on the side wanting to stop DeCSS. I thought the whole point of DeCSS was to promote interoperability.
I guess it must be one of those "1984" things. War is peace, freedom is slavery, interoperability is DVDCCA restrictions. And the American Committee for Interoperable Systems must be something like the Ministry of Love.
What developer certs let you down is put ActiveX controls on your web pages that the user can download without going through a scary dialog saying "the browser can't tell who created this file". You do get a dialog saying "This file was created by so-and-so, click 'yes' if you trust them" but that dialog is designed to not be scary, and encourage the user to download whatever crap is about to take over his computer.
There are also developer certs for signed objects in Netscape browsers, but not too many people care about those any more. :(
in languages like Java. (Don't say do it with
threads. Performance will be abysmal. Remember
that it's supposed to be legitimate Scheme style
to use continuations anywhere other languages
would use gotos, loops, or even ordinary function
calls, not just fancy constructs like coroutines.