So I was wondering whether or not it stores MP3s on the minidisc (the atrac system has a fixed bitrate of 256 kbs, IIRC). Ifso, that'd be great. At 256, mp3s kick ATRAC's ass! (at 128, mp3s are slightly worse than ATRAC, IMHO). However, I suspect that the software is just a glorified format converter.
I tried to check the website or call sharp, but the site is of course all glitz, and 1800 BE SHARP seems specially designed to keep you from actually speaking to anyone. Why do they have those systems? Do they think that by pissing me off, I'm more likely to buy their products?
Anyway, end of rant. If anyone can answer my question, I'd be grateful.
Ok, this is likely an old point, but since I have a policy against saying anything new here goes:
Summary: I don't believe medium+ companies CARE about performance. They see hardware as a capital investment. It's ok to buy $.5M worth of hardware, if that's what is needed for performance, as long as the software is stable.
So I hear you cry, why are they using NT?I don't know to what extent they are, but if it is, the fact that linux has so many new versions so often might be part of the reason.
Linux moves too damn fast for corporate adoption. I'm not even talking about 2.3, there are too many tweaks going on just in 2.2 for conscientious admins to install it. If I were to install it for my (ficticious) company, I'd like to give it a thorough going over before installing it. And that means that all the arguments of "this problem fixed in newest version" are immaterial. That's not the version I'm reviewing. Since so many changes are included in each version, I'd be very hesitant to just install the new one.
No company in its right mind would install beta software as production software, yet that is exactly what is suggested when people say "just install the newest version".
So I think linux is suffering slightly because of this; it is beta software, but not labeled as such. Perhaps what we need is an even stabler branch of the tree; one that only gets bug fixes, not new features.
Scenario: linux 3 comes out. It incorporates all of the stable and well tested features of 2.2. We get three branches: 3a : corporate. No new features. ever. only well tested bugfixes, backported from 3.0 3.0 : home user. New stable features and bugfixes backported from 3.1 3.1 : bleedin' . Anything goes (down, that is). may reformat your harddrive occasionally.
Or something like that. The idea is to create a stable enough platform for corporate use so that 1) they can have confidence in each new version because there is a longish debugging cycle and 2) we get a good baseline for comparisons to other os's.
The point is to separate out features (bug causes) from bug fixes, so that paranoid coorporations can rely on the software. And make each update small enough to be given an overview before being patched in.
Shouldn't it be CGI? morhping just reshapes one image into another. What they mean is generating a realistic image, or video, impersonating a real person doing or saying something they wouldn't. Think Josef Virek generating Tally Isham in count zero overdrive (?).
Morphing is more snoop doggy dog.
Someone should also post a link to voice fonts (or at least that's what they were called at the time) that IBM were playing with. I ran accross the term in an article in wired couple of years ago (back when it was still readable) talking about a guy who was trying to work his way up the VC hill. He was telling wired about a presentation he made where one guy was constantly heckling him -- in Jimmy Stewart's voice. The heckler had distilled down the particulars of that voice to a voice font, and was able to apply it to whatever input he wanted. The interviewee noted that IBM bought the rights. This is of course useful, as you want your leader to speak to the troops too.
Thermo-electrics, eh? Never heard of it, so I chased down a website (using the ever-amazing google).
The first match I found seemed to suggest that like brakes on elecric cars, these devices could transform heat to electricity. Conservation of energy means that in a laptop, this would cool while recharging the battery (Didn't look closely enough to see if there was a useful voltage, but still!).
Lovely idea, no? Why spend precious energy on a fan, when you can just pump the heat back into the battery. Smile!
Given the sad state of proprietary ciphers for use with cheap hardware (for example Cell Phones, whose ciphers seem to be broken every other week) if it were possible to use the [presumably] very thoroughly cryptanalysed AES wiiner, then this would be an immediate win.
In fact, if the cipher were key-size independent, then the manufacturers would be able to easily balance cost and security. Perhaps cell-phones only need 64 bit keys? (One popular system nowadays has 40 bit keys, but is severely broken, and can be cracked after 40 packets have been intercepted -- 1 second!) Not a problem. Better yet-- imagine phones with settable security (you want 128 bit security, then accept a lousy job of compression 'cause there's only so much this $2 CPU can do per packet)
So even if twofish isn't selected as AES, the fact that it has been very carefully and publically scrutinized gives Counterpane an excellent leg up on the embedded market. Now all they have to do is figure out how to sell it, as it is free. (perhaps auditing implementations?)
in a recent cryptogram, you write that most symmetric ciphers need more entropy than people can remember and hence supply. Even with bio-metrics adding more bits, it is not really worth the effort to construct ciphers with more than 128 bits of entropy in the key, because people won't give them more than that much entropy in the pass phrase.
However, social and technological pressures make longer and longer keys a necessity. What promising approaches do you see for making remembering and entering -- even though I have long passages of text memorised, I don't want to type them in for each email I want to send -- usefully long passphrases?
Ie, to paraphrase, would you discuss the state of the art of cipher/human interaction, as it pertains to key management.
If you are referring to symmetric ciphers with a shorter key than message, then a provably unbreakable cipher would imply that P != NP.
Symmetric ciphers are in NP, as you can verify the correctness of a guess in P time, once you have guessed it. So by proving it unbreakable (ie not in P), then you prove them different.
Mind you this says nothing about the converse; ie if we hypothesise that indeed P !=NP, this does not imply that your cipher isn't in P.
Hrm. I'd be more interested in what you hope (for the good of all concerned... yadda blah) doesn't happen. For example, if an efficient factoring algorithm were discovered tommorow,this would be a disaster for the RSA folks, and everyone who uses it.
Are there any similar pitfalls that apply to the multi-round Fiestel w/ s-boxes that are the current state of the art for symmetric ciphers?
I seeing something the telly a couple of years ago about this guy (sorry, no URL, not even a hint of an idea for your searching pleasure. Please supply one if you know) who had written a program to distil the main melodies from complicated scored classical music. He could input Mozart's magic flute (my fave) in all of it's multitimbral glory, and then get back the melody you or I would whistle. Pretty neat.
Even neater was that the process could be run in sort of in reverse. Of course, he didn't recreate the complexity of ol' Wolfie, but he was able to expand the melody to a polyphonic piece.
Something like that could be used here; generate a randomish melody from snippets, tell the expander whether to make it happy or sad, snappy or gloomy, and then add heuristic variations to the presumably stilted accompanyment.
Winnowing and Chaffing is pretty damn smart. I must have missed the original article when it first came out. Thanks for pointing it out.
However, it's not quite what I had in mind; It trades availible peak bandwith against easing the restriction against encryption, while I was suggesting trading average bandwidth against traffic analysis. Chaffing solves the problem of exporting crypto; I was pointing out the problem of "why are you communicating _now_?"
Of course, you could do both -- this is probably what you meant no? -- where we send plain multiplexed text most of the time, and then every so often slip in a secret message. Sure, that'd work.
We have to assume that the person isn't using encryption, because wiretapping an encrypted line is rather pointless.
So we are talking about unsophisticated users (and whether or not the would-be targets are sophisticated is another story altogether, which if anyone bothered to listen to me, we'd discuss first). Unsophisticated users will typically have one connection to the internet, and not do any fancy tunneling to a crowd.
So there is one very obvious place to place a tap -- the isp. IMHO, any nation that wants to wiretap its digital populace should just require ISPs to provide law-enforcement the ability to selectively tap users. This would be a much more localised solution than working the requirements into an RFC.
I dunno. For this to work, a) the audio stream would have to be very natural, both in its a1) existence, a2) content, and a3) timing ("hey! why is Jimbob discussing fashion with the prez in the middle of a war?") b) we would have to communicate the details of the stego some how, in some non-suspicious manner. Req A makes this hard to do, and if we had such a channel, we really wouldn't need stego in the first place.
requirement A is so hard to get right, that you might as well just go for an "open" attack against traffic analysis. Send each other random encrypted messages every day. Even when you have nothing to say. Random length, random time.
Since messages are sent almost constantly, attackers will be unable to draw correlations between trafic and outside action. In intelligence, knowing who is communicating is almost as important as what they are saying, I'd imagine.
The recipient will of course be able to identify the meaningless messages from the real (by virtue of the meaningless ones not decrypting), but attackers will not know which messages to attack.
Traditional stego (hiding stuff in the low-order bits) is mostly useful for hiding the plans for nuclear devices in my collection of mountain vista JPGs.
Did anyone catch the angular velocity of the actuators? It would be in angle/time/grooves, as each joint consists of several grooves. Also the torque would be interesting.
Now the comment:
200 mW is quite a bit for a micro actuator, no? I forget if that was per leg or for the whole ant. but whoa! I seem to recall that modern laptop batteries have power ratings of 10 odd watthours, but they weigh significantly more than 2.5 grams.
How far can it walk with a battery that light? probably only a few minutes.
The key to the whole scheme is that their server will only authenticate a message as valid for a limited time. You can save the plaintext if you want, but that doesn't proove anything -- it's just text, and for all I know you composed it yourself.
The service they offer is that I send you mail (via their server) and then you can ask them whether I really wrote that text. They'll confirm that until the mail expires.
Of course, if I'm stupid enough to sign it with asymetric encraption (c.f. www.theonion.com), then I'm shit out of luck. Unless I go and claim that my private key was compromised. And thereby open up all encrypted emails sent to me. Not a good way to make friends.
you could do it; but it requires that you 1) allow and trust a central authority to authenticate your mail, and 2) require authentication for all mail
Scenario:
Bob sends me mail. This is a two step process; it is sent via Auth, who signs it and sends me the message and Auth's signature. Now I can ask auth to authenticate the message, and until it expires the message will be authentic. After it expires, I'll still have the message, but it won't authenticate, so by our second assumption, it will be worthless.
Mind you, the two assumptions are a bit much for anyone to swallow, but it could work.
This is a completely uninformed question, but do both toolkits have the same use strategy? I obviously don't mean arguments in the same order, but more along the lines of one having an event model and the other using subclassing, or something like that.
in summarium: is it even feasable (sp?) to write a common abstraction layer?
Slashdot Mirror
So I was wondering whether or not it stores MP3s on the minidisc (the atrac system has a fixed bitrate of 256 kbs, IIRC). Ifso, that'd be great. At 256, mp3s kick ATRAC's ass! (at 128, mp3s are slightly worse than ATRAC, IMHO). However, I suspect that the software is just a glorified format converter.
I tried to check the website or call sharp, but the site is of course all glitz, and 1800 BE SHARP
seems specially designed to keep you from actually speaking to anyone. Why do they have those systems? Do they think that by pissing me off, I'm more likely to buy their products?
Anyway, end of rant. If anyone can answer my question, I'd be grateful.
Ok, this is likely an old point, but since I have a policy against saying anything new here goes:
Summary: I don't believe medium+ companies CARE about performance. They see hardware as a capital investment. It's ok to buy $.5M worth of hardware, if that's what is needed for performance, as long as the software is stable.
So I hear you cry, why are they using NT?I don't know to what extent they are, but if it is, the fact that linux has so many new versions so often might be part of the reason.
Linux moves too damn fast for corporate adoption. I'm not even talking about 2.3, there are too many tweaks going on just in 2.2 for conscientious admins to install it. If I were to install it for my (ficticious) company, I'd like to give it a thorough going over before installing it. And that means that all the arguments of "this problem fixed in newest version" are immaterial. That's not the version I'm reviewing. Since so many changes are included in each version, I'd be very hesitant to just install the new one.
No company in its right mind would install beta software as production software, yet that is exactly what is suggested when people say "just install the newest version".
So I think linux is suffering slightly because of this; it is beta software, but not labeled as such. Perhaps what we need is an even stabler branch of the tree; one that only gets bug fixes, not new features.
Scenario:
linux 3 comes out. It incorporates all of the stable and well tested features of 2.2. We get three branches:
3a : corporate. No new features. ever. only
well tested bugfixes, backported from
3.0
3.0 : home user. New stable features and bugfixes
backported from 3.1
3.1 : bleedin' . Anything goes (down, that is).
may reformat your harddrive occasionally.
Or something like that. The idea is to create a stable enough platform for corporate use so that 1) they can have confidence in each new version because there is a longish debugging cycle and 2) we get a good baseline for comparisons to other os's.
The point is to separate out features (bug causes) from bug fixes, so that paranoid coorporations can rely on the software. And make each update small enough to be given an overview before being patched in.
Whaddaya think, eh?
Shouldn't it be CGI? morhping just reshapes one image into another. What they mean is generating a realistic image, or video, impersonating a real person doing or saying something they wouldn't. Think Josef Virek generating Tally Isham in count zero overdrive (?).
Morphing is more snoop doggy dog.
Someone should also post a link to voice fonts (or at least that's what they were called at the time) that IBM were playing with. I ran accross the term in an article in wired couple of years ago (back when it was still readable) talking about a guy who was trying to work his way up the VC hill. He was telling wired about a presentation he made where one guy was constantly heckling him -- in Jimmy Stewart's voice. The heckler had distilled down the particulars of that voice to a voice font, and was able to apply it to whatever input he wanted. The interviewee noted that IBM bought the rights. This is of course useful, as you want your leader to speak to the troops too.
Thermo-electrics, eh? Never heard of it, so I chased down a website (using the ever-amazing google).
The first match I found seemed to suggest that like brakes on elecric cars, these devices could transform heat to electricity. Conservation of energy means that in a laptop, this would cool while recharging the battery (Didn't look closely enough to see if there was a useful voltage, but still!).
Lovely idea, no? Why spend precious energy on a fan, when you can just pump the heat back into the battery. Smile!
I'm soo jealous that you got your name as a login.
I want my johan! I've always been johan, but here someone beat me to it. grr.
Hey johan! yes, you with my login! I'll flame you for it. Or how about distributed rock-paper-scissors. Anything!
Johan
Could you (n2kiq, not bruce) expand on the compromise danger of 3DES layering, please?
I'm at a loss for seeing how that would occur.
Given the sad state of proprietary ciphers for use with cheap hardware (for example Cell Phones, whose ciphers seem to be broken every other week) if it were possible to use the [presumably] very thoroughly cryptanalysed AES wiiner, then this would be an immediate win.
In fact, if the cipher were key-size independent, then the manufacturers would be able to easily balance cost and security. Perhaps cell-phones only need 64 bit keys? (One popular system nowadays has 40 bit keys, but is severely broken, and can be cracked after 40 packets have been intercepted -- 1 second!) Not a problem. Better yet-- imagine phones with settable security (you want 128 bit security, then accept a lousy job of compression 'cause there's only so much this $2 CPU can do per packet)
So even if twofish isn't selected as AES, the fact that it has been very carefully and publically scrutinized gives Counterpane an excellent leg up on the embedded market. Now all they have to do is figure out how to sell it, as it is free. (perhaps auditing implementations?)
Johan
Bruce,
in a recent cryptogram, you write that most symmetric ciphers need more entropy than people can remember and hence supply. Even with bio-metrics adding more bits, it is not really worth the effort to construct ciphers with more than 128 bits of entropy in the key, because people won't give them more than that much entropy in the pass phrase.
However, social and technological pressures make longer and longer keys a necessity. What promising approaches do you see for making remembering and entering -- even though I have long passages of text memorised, I don't want to type them in for each email I want to send -- usefully long passphrases?
Ie, to paraphrase, would you discuss the state of the art of cipher/human interaction, as it pertains to key management.
Johan
If you are referring to symmetric ciphers with a shorter key than message, then a provably unbreakable cipher would imply that P != NP.
Symmetric ciphers are in NP, as you can verify the correctness of a guess in P time, once you have guessed it. So by proving it unbreakable (ie not in P), then you prove them different.
Mind you this says nothing about the converse; ie if we hypothesise that indeed P !=NP, this does not imply that your cipher isn't in P.
Johan
this is currently modded to 4. I'm asking a moderator to please up it to 5. Best Q so far, w/o a doubt.
Hrm. I'd be more interested in what you hope (for the good of all concerned... yadda blah) doesn't happen. For example, if an efficient factoring algorithm were discovered tommorow,this would be a disaster for the RSA folks, and everyone who uses it.
Are there any similar pitfalls that apply to the multi-round Fiestel w/ s-boxes that are the current state of the art for symmetric ciphers?
Johan
I seeing something the telly a couple of years ago about this guy (sorry, no URL, not even a hint of an idea for your searching pleasure. Please supply one if you know) who had written a program to distil the main melodies from complicated scored classical music. He could input Mozart's magic flute (my fave) in all of it's multitimbral glory, and then get back the melody you or I would whistle. Pretty neat.
Even neater was that the process could be run in sort of in reverse. Of course, he didn't recreate the complexity of ol' Wolfie, but he was able to expand the melody to a polyphonic piece.
Something like that could be used here; generate a randomish melody from snippets, tell the expander whether to make it happy or sad, snappy or gloomy, and then add heuristic variations to the presumably stilted accompanyment.
Fun!
Winnowing and Chaffing is pretty damn smart. I must have missed the original article when it first came out. Thanks for pointing it out.
However, it's not quite what I had in mind; It trades availible peak bandwith against easing the restriction against encryption, while I was suggesting trading average bandwidth against traffic analysis. Chaffing solves the problem of exporting crypto; I was pointing out the problem of "why are you communicating _now_?"
Of course, you could do both -- this is probably what you meant no? -- where we send plain multiplexed text most of the time, and then every so often slip in a secret message. Sure, that'd work.
Johan
not really.
We have to assume that the person isn't using encryption, because wiretapping an encrypted line is rather pointless.
So we are talking about unsophisticated users (and whether or not the would-be targets are sophisticated is another story altogether, which if anyone bothered to listen to me, we'd discuss first). Unsophisticated users will typically have one connection to the internet, and not do any fancy tunneling to a crowd.
So there is one very obvious place to place a tap -- the isp. IMHO, any nation that wants to wiretap its digital populace should just require ISPs to provide law-enforcement the ability to selectively tap users. This would be a much more localised solution than working the requirements into an RFC.
Oh, and I should add: req a1 implies that the existence of the random messages is not suspicious.
Johan
well...
I dunno. For this to work,
a) the audio stream would have to be very natural, both in its a1) existence, a2) content, and a3) timing ("hey! why is Jimbob discussing fashion with the prez in the middle of a war?")
b) we would have to communicate the details of the stego some how, in some non-suspicious manner. Req A makes this hard to do, and if we had such a channel, we really wouldn't need stego in the first place.
requirement A is so hard to get right, that you might as well just go for an "open" attack against traffic analysis. Send each other random encrypted messages every day. Even when you have nothing to say. Random length, random time.
Since messages are sent almost constantly, attackers will be unable to draw correlations between trafic and outside action. In intelligence, knowing who is communicating is almost as important as what they are saying, I'd imagine.
The recipient will of course be able to identify the meaningless messages from the real (by virtue of the meaningless ones not decrypting), but attackers will not know which messages to attack.
Traditional stego (hiding stuff in the low-order bits) is mostly useful for hiding the plans for nuclear devices in my collection of mountain vista JPGs.
Johan
a comment and a question.
the question first:
Did anyone catch the angular velocity of the actuators? It would be in angle/time/grooves, as each joint consists of several grooves. Also the torque would be interesting.
Now the comment:
200 mW is quite a bit for a micro actuator, no? I forget if that was per leg or for the whole ant. but whoa! I seem to recall that modern laptop batteries have power ratings of 10 odd watthours, but they weigh significantly more than 2.5 grams.
How far can it walk with a battery that light? probably only a few minutes.
Johan
The key to the whole scheme is that their server will only authenticate a message as valid for a limited time. You can save the plaintext if you want, but that doesn't proove anything -- it's just text, and for all I know you composed it yourself.
The service they offer is that I send you mail (via their server) and then you can ask them whether I really wrote that text. They'll confirm that until the mail expires.
Of course, if I'm stupid enough to sign it with asymetric encraption (c.f. www.theonion.com), then I'm shit out of luck. Unless I go and claim that my private key was compromised. And thereby open up all encrypted emails sent to me. Not a good way to make friends.
Johan
you could do it; but it requires that you
1) allow and trust a central authority to authenticate your mail, and
2) require authentication for all mail
Scenario:
Bob sends me mail. This is a two step process; it is sent via Auth, who signs it and sends me the message and Auth's signature. Now I can ask auth to authenticate the message, and until it expires the message will be authentic. After it expires, I'll still have the message, but it won't authenticate, so by our second assumption, it will be worthless.
Mind you, the two assumptions are a bit much for anyone to swallow, but it could work.
Johan
what a mess I made of that. Oh well. you get the drift.
I thought RC4 was symmetric.
is it?
by yet another completely uninformed question
I thought rc4 was symmetric?
This is a completely uninformed question, but do both toolkits have the same use strategy? I obviously don't mean arguments in the same order, but more along the lines of one having an event model and the other using subclassing, or something like that.
in summarium: is it even feasable (sp?) to write a common abstraction layer?
hey!
don't forget the inimitable Douglas Adams' colors:
infra dead
ultra violent
gang green
Lovely!
ta!
does anyone know why the cypherpunks NYT login appears to be disabled?