Unfortunately, this isn't a public meeting. When asked about
that, Richard Stallman said
inviting a public audience to a
negotiation isn't the best way to get an agreement.
RMS uses his powers of tact and diplomacy to suggest getting an agreement with less public participation! This certainly isn't the RMS that the average Slashdotter imagines... --
*more* contexts? Is Perl's use of context good?
on
Apocalypse 2
·
· Score: 4
I love Perl in lots of ways, it really is the language that rolls its sleeves up and gets the job done, but the first thing I'd take out if I had a free hand is the entire distinction between scalar and array contexts. As Perl is moving closer to a pure OO way of thinking, it becomes more attractive to make the distinction explicit, by using different names for "foo in scalar context" and "foo in array context".
However, it seems that Perl 6 will extend the concept of "context" still further!
Proposal 1 is ``that a hash in scalar context evaluate to the number of keys in the hash.'' (You can find that out now, but only by using the keys() function in scalar context.) Proposal 1 is okay by me if we change ``scalar context'' to ``numeric context'', since in scalar context a hash will produce a reference to the hash, which just happens to numify to the number of entries.
So now you can get the wrong thing by expecting a number but accidentally creating a scalar rather than numeric context! You've got to have a new operator, presumably numeric(), to sit next to scalar()!
Will there be a context for every type, built-in and dynmically created, in Perl? Or will the contexts remain a weird wart on the type system?
I don't know what the right solution is, since Perl 6 would barely be Perl at all without the contexts, but moving away from contexts at least would be good.
I could be wrong here. I'm writing this mainly because for the most part I love Perl, and I'd be interested in being persuaded that context is a good thing and worht the potential for confusion, that it's better to have a distinction between
my $line = <FILE>;
my @wholething = <FILE>;
than having
my $line = FILE.line();
my @wholething = FILE.lines();
I think I'm intellectually inclined to feel that Python does most things the right way, but somehow I still find myself reaching for Perl when I need to get the job done... --
qmail has an extremely restrictive license which is quite bothersome. My favourite Sendmail killer is Exim; others prefer Postfix. --
Like open source, non-techies benefit from it
on
3G Delayed in Japan
·
· Score: 2
It's like open source software: a non-technical user won't have a scooby[1] how to configure their phone to do weird things the same way they could hardly hack source, but that's OK, because in both cases it's likely a techie user will already have done it for them, and put it somewhere they can download. So you don't have to understand how to configure your phone to make use of the flexibility.
Although frankly, if ordinary users are prepared to learn how to text each other, they can't be as put off by the slightly inconvenient and tricky as we've always thought...
[1] It means "a clue" in Scotland at least. --
Dr Rudolf von Bitte Rucker is better known as...
on
The New Flatland
·
· Score: 4
Rudy Rucker, author of the Software, Wetware, Freeware, Realware series. He later wrote a somewhat more accessible introduction to thinking about dimension called The Fourth Dimension and How to Get There which I recommend highly. Rudy Rucker is lots of fun and most things he gets involved with are cool - check out his list of works. --
I wrote a program which used the current time *2 as a 10-byte IV. When the time rolls over, that program will fail. Why was I doing such a dirty trick? I was trying to squeeze every last byte out of an RC4-based cryptosystem written in Perl.
The bug was spotted by co-author Jeff Allen, who suggested this fix: *invert* the time with "~". That should keep going until the 32-bit clock runs out in 2038.
I've had to introduce a space in ";for" to get around Slashdot's random space adding system (bah!) - the minimal version is on my Web pages. Incidentally, the ~ fix didn't save a character, because we still had to leave a space between the = and the ~ since =~ is a distinct Perl token... --
Passphrases are typically low entropy beasts; a brute force attack tends to be effective against them if you can gather a decent wodge of computing power. You can use key stretching to make things harder, but that only gets you so far.
So the point of the primary key and tamper-resistant hardware approach is that the attacker no longer has the option of trying passphrases on their supercomputer. With what I'm suggesting, the only way to try a passphrase is to try and use it to log into the iButton. The iButton gets to decide how often you can try in a given time period, and for how long it'll lock you out if those attempts fail. That's vastly more secure.
Also, you now need two things to break in: the passphrase and the bit of hardware. Even if they've used "password" as their password, stealing the laptop still isn't enough; and you're much less likely to leave the iButton lying around anywhere.
Obviously the passphrase will be hashed as part of the key stretching protocol, and obviously you design things so that even if you can break the tamper-resistance you still have to brute-force the passphrase, but the iButton adds a very significant extra hurdle that could really make the difference for security. --
Store the primary encryption key on tamper-resistant hardware like an iButton. That's designed to destroy the data onboard if anyone tries to open the case, without the need for messy explosives, and the steel case means the tamper resistance is pretty good.
Then use the passphrase to negotiate with the iButton for the key onboard. Unless you can defeat the tamper-resistance, bang goes any hope of dictionary attacks on supercomputers; you have to try each passphrase against the iButton, and it will impose longer and longer delays between tries. A strong password protocol like SRP will prevent some attacks based on this system.
Now the security from your passphrase is vastly greater. The iButton is pretty dinky and can be kept on your keyring (the thing that has your house keys on it, not a PGP keyring); it's unlikely you'll leave it in the back of a taxi alongside the laptop.
Of course the primary key is a proper high-entropy key (100 bits or more) so there's no hope of a brute force attack.
I'm implementing exactly this as part of my work (I'm employed by www.convergence.de). We've demonstrated signing with all the hard crypto happening on the iButton, and now we're completing the integration with GPG; I've met with Werner Koch about the best way to do this. The tamper resistance on the iButton is excellent, and the programming is easier than other such solutions. I'd write more but my wrists hurt; however, please feel free to mail me iwth any questions. --
Cryptography is my day job. Yet practically everything I know about the field, I got from papers downloaded for free from the Net. I've only paid for two things: Applied Cryptography and the proceedings of one conference (FSE2). I haven't had access to an academic library for five years.
Most papers can be found if you know how to search - find the exact title from CiteSeer, then search for that with Google, failing that search for the authors. If you get really desperate, as I have twice, you can mail the authors and ask very nicely for a copy - most authors want to help. I'm planning on offering hosting for some authors who don't have web pages of their own, because I'd like to see their papers online but they don't have time to maintain them. I go to a lot of work to make my online papers as useful as possible: see http://www.ciphergoth.org/ for examples.
This has to be the future. It's crazy to make amateurs like I was jump through hoops to get access to this information, there's no longer any sane reason for it. I hope the move away from print publications for academia happens as fast as possible and if there's anything I can do to hasten it, I'm there. --
I've barely been back in Britain for two days after visiting Tokyo and Yokohama, and I find this - cool! Though I now live in Edinburgh, I was born and brought up in London and visit often so the comparison is interesting.
The "Mobile Girls". In this, I don't actually think Japan is any different from the UK, or Germany or Sweden. Here in Europe practically everyone between 11 and 40 has a mobile phone (and lots of other people too), and the girls can text like lightening here too. My little sisters have a mobile and they can text faster than I can. The amazing thing about the Japanese girls is that they can do it in Kanji! A friend I met there demonstrated: you enter what you want to say in a phonemic form, then the 'phone offers you several ways to say the same thing in Kanji script. That, combined with the larger screens of the iMode phones, means it's convenient to receive much longer messages.
Oh, and DoCoMo phones can receive email as conveniently as a text message. I wish I had that.
Technology adoption. In Tokyo, I got the net from an Ethernet cable in my hotel room. Damn fast too. I wish I'd had the same in Yokohama.
Conformism. I don't think it's as bad as people say. Certainly the streets of Tokyo don't look like the humourless regiments people seem to imagine, just people holding hands, laughing and enjoying themselves at the weekend in the glorious weather under the cherry blossom. I went to a Tokyo goth club and it was a fabulous experience - you can see pictures at
www.cluefactory.org.uk/paul/photos/tokyo/eve/
- no conformism there!
I've never been that far away before - Tokyo was a real eye-opener, and while there were many unusual things (Pocari Sweat is called that because it's an isotonic sports drink), the Japanese are not the aliens people seem to think. And don't worry about the politeness rules too much, they're used to gaijin getting it wrong, just don't blow your nose in public... --
If you don't think this is surprising, maybe you haven't fully understood it. He defines a number, W_UTM, which must have some perfectly ordinary value - it's not one of these weird, undetermined things, like the continuum hypothesis or something. It's just the probability that a random Turing machine will halt. Every Turing machine either halts or doesn't halt, so if only you could solve the halting problem you could get a good approximation to W_UTM in a moment. Since you can't, W_UTM is unknowable. But it's *much more unknowable than you might expect*. To quote the lecture:
So this
becomes a specific real number, and let's say I write it out in binary, so I get a
sequence of 0's and 1's, it's a very simple-minded definition. Well, it turns out
these 0's and 1's have no mathematical structure. They cannot be compressed. To
calculate the first N bits of this number in binary requires an N-bit program. To
be able to prove what the first N bits of this number are requires N bits of axioms.
This is irreducible mathematical information, that's the key idea.
Dwell on that a little. That is serious weirdness. --
First, it would cost you a fair bit just to get this thrown out of court. Most likely, though, it won't be thrown out, it'd come to trial. By the time of the trial date, the prosecution would be citing it as part of their evidence and claiming it's new for some stupid trivial reason. And it'll cost you tens of thousands of dollars to contest.
It's important to understand that being in the right, morally or legally, is barely of the least importance here. --
Sometimes those who say "I don't like to use or contribute to that piece of software, because although it's free beer, I don't like the license" get accused of whining: "hey, it's free, if you don't like it don't use it but don't whine about it". The real lesson to draw from this is that licenses *do* matter and it's worthwhile discussing what we want out of them. --
No details of PDF have been kept secret in the hope of making this scheme stronger. The scheme explicitly relies on implementors agreeing to honour it. Adobe have thought about digital signatures, but it's tricky to get right, so they've put it off for future releases. --
I used to be on the core RIP team for Harlequin ScriptWorks, the world's most popular high-end RIP, and implementing the code to honour the PrintPermission flag was my very first job on the team.
For debugging purposes, we added a switch that allowed us not to honour the print permission flag; this switch is absent in non-debug RIPS.
Re-encoding a PDF file to remove this flag would be non-trivial, but ignoring it is absolutely trivial. I'd be amazed if it would take me more than twenty minutes to re-create the patch
under discussion given the xpdf source code.
As "circumvention devices" go, it's not DeCSS. It's not even CueCat. It's more like rot-13. --
A "white hat" is someone who understands security, and uses it to advance security, not to break into other people's systems without their permission. For example, I'd concur with the people who put the "Powered by IIS" message on www.apache.org that this was a gray hat activity, not white hat as Apache said.
I can think of situations where breaking into systems without permission would be justifiable (happens all the time in Buffy!) but it's still Black Hat, I think. --
...they always mean "Distinctions between one kind of egg and another are never relevant".
And it's just *never* true. The assertion that "criminals are criminals" mindlessly lumps in Nelson Mandela with Jeffery Dahmer. "Hacking is hacking" puts RMS in the same category as RTM.
As it happens, I'm generally against breaking into computer systems as a political act; I just thought you should know that statements like "criminals are criminals" is a big flag that you're going to be talking nonsense. --
Amazon will survive. They have a way of making actual money: profit off book sales. And they don't have to cut their margins to the bone: they aren't the cheapest book site on the Web by any means, but they use convenience to keep their customers.
Yes, I know the one-click patent is evil. I'm not discussing what should be here, but what I think will be. --
Sealand has multiple connectivity into the UK and into Amsterdam.
Now, maybe all of those ISPs will capitulate. But supposing they don't? Supposing, say, one of the well-connected Amsterdam ISPs stands firm, and is backed up by the Amsterdam court? I don't think the RIAA are going to try and cut off Amsterdam, which is a major Internet hub for Europe, but maybe they'll demand that US ISPs fake the routing tables so you can't route to Sealand? Then another offshore alternative opens up, more routing frob...
Eventually the RIAA and MPAA will demand that the Internet as we know it be dismantled in favour of a networking protocol that is better at supporting censorship. Eventually they'll demand an Internet that has "providers", who are big companies that can afford legal fees and scrupulously provide only legal content, and "users" who can send email and read content provided by "providers" but who can't afford the legal fees needed to publish anything, and whose communication with each other is heavily mediated by the "providers" taking legal responsibility. They'll want changes to the law, backed by new international conventions, that make even Slashdot illegal, because Slashdot can't guarantee someone won't put DeCSS here.
They won't necessarily get what they demand, but they will eventually be forced to demand it if their position is to make any sense at all. And they're not the kind of people to say "OK, that would be too nasty, we'll concede defeat." --
Slashdot Mirror
--
However, it seems that Perl 6 will extend the concept of "context" still further!
So now you can get the wrong thing by expecting a number but accidentally creating a scalar rather than numeric context! You've got to have a new operator, presumably numeric(), to sit next to scalar()!
Will there be a context for every type, built-in and dynmically created, in Perl? Or will the contexts remain a weird wart on the type system?
I don't know what the right solution is, since Perl 6 would barely be Perl at all without the contexts, but moving away from contexts at least would be good.
I could be wrong here. I'm writing this mainly because for the most part I love Perl, and I'd be interested in being persuaded that context is a good thing and worht the potential for confusion, that it's better to have a distinction between
my $line = <FILE>;
my @wholething = <FILE>;
than having
my $line = FILE.line();
my @wholething = FILE.lines();
I think I'm intellectually inclined to feel that Python does most things the right way, but somehow I still find myself reaching for Perl when I need to get the job done...
--
qmail has an extremely restrictive license which is quite bothersome. My favourite Sendmail killer is Exim; others prefer Postfix.
--
It's like open source software: a non-technical user won't have a scooby[1] how to configure their phone to do weird things the same way they could hardly hack source, but that's OK, because in both cases it's likely a techie user will already have done it for them, and put it somewhere they can download. So you don't have to understand how to configure your phone to make use of the flexibility.
Although frankly, if ordinary users are prepared to learn how to text each other, they can't be as put off by the slightly inconvenient and tricky as we've always thought...
[1] It means "a clue" in Scotland at least.
--
Rudy Rucker, author of the Software, Wetware, Freeware, Realware series. He later wrote a somewhat more accessible introduction to thinking about dimension called The Fourth Dimension and How to Get There which I recommend highly. Rudy Rucker is lots of fun and most things he gets involved with are cool - check out his list of works.
--
You can back a PDA up.
Really, there are many reasons, but that one stands head and shoulders above the rest.
--
I wrote a program which used the current time *2 as a 10-byte IV. When the time rolls over, that program will fail. Why was I doing such a dirty trick? I was trying to squeeze every last byte out of an RC4-based cryptosystem written in Perl.
; for$x(@t=@s=0..255){S
The bug was spotted by co-author Jeff Allen, who suggested this fix: *invert* the time with "~". That should keep going until the 32-bit clock runs out in 2038.
#!/usr/bin/perl -0777i_MUNITION,see_http://ciphersaber.gurus.com
(pop)?read STDIN,$p,10:print$p= ~time;sub S{@s[$x,$y]=@s[$y,$x]}sub
Q{$s[($_[0]+=$_[1])%=@s]}@k=unpack'C*',(pop).$p
Q$y,$k[$x%@k]+Q$x}$x=$y=0;print map{chr($_^Q S Q$y,Q$x,1)}unpack'C*',<>
I've had to introduce a space in ";for" to get around Slashdot's random space adding system (bah!) - the minimal version is on my Web pages. Incidentally, the ~ fix didn't save a character, because we still had to leave a space between the = and the ~ since =~ is a distinct Perl token...
--
Passphrases are typically low entropy beasts; a brute force attack tends to be effective against them if you can gather a decent wodge of computing power. You can use key stretching to make things harder, but that only gets you so far.
So the point of the primary key and tamper-resistant hardware approach is that the attacker no longer has the option of trying passphrases on their supercomputer. With what I'm suggesting, the only way to try a passphrase is to try and use it to log into the iButton. The iButton gets to decide how often you can try in a given time period, and for how long it'll lock you out if those attempts fail. That's vastly more secure.
Also, you now need two things to break in: the passphrase and the bit of hardware. Even if they've used "password" as their password, stealing the laptop still isn't enough; and you're much less likely to leave the iButton lying around anywhere.
Obviously the passphrase will be hashed as part of the key stretching protocol, and obviously you design things so that even if you can break the tamper-resistance you still have to brute-force the passphrase, but the iButton adds a very significant extra hurdle that could really make the difference for security.
--
Store the primary encryption key on tamper-resistant hardware like an iButton. That's designed to destroy the data onboard if anyone tries to open the case, without the need for messy explosives, and the steel case means the tamper resistance is pretty good.
Then use the passphrase to negotiate with the iButton for the key onboard. Unless you can defeat the tamper-resistance, bang goes any hope of dictionary attacks on supercomputers; you have to try each passphrase against the iButton, and it will impose longer and longer delays between tries. A strong password protocol like SRP will prevent some attacks based on this system.
Now the security from your passphrase is vastly greater. The iButton is pretty dinky and can be kept on your keyring (the thing that has your house keys on it, not a PGP keyring); it's unlikely you'll leave it in the back of a taxi alongside the laptop.
Of course the primary key is a proper high-entropy key (100 bits or more) so there's no hope of a brute force attack.
Does that sound secure enough?
--
I'm implementing exactly this as part of my work (I'm employed by www.convergence.de). We've demonstrated signing with all the hard crypto happening on the iButton, and now we're completing the integration with GPG; I've met with Werner Koch about the best way to do this. The tamper resistance on the iButton is excellent, and the programming is easier than other such solutions. I'd write more but my wrists hurt; however, please feel free to mail me iwth any questions.
--
A website is cracked.
A cipher is cryptanalyzed.
--
Cryptography is my day job. Yet practically everything I know about the field, I got from papers downloaded for free from the Net. I've only paid for two things: Applied Cryptography and the proceedings of one conference (FSE2). I haven't had access to an academic library for five years.
Most papers can be found if you know how to search - find the exact title from CiteSeer, then search for that with Google, failing that search for the authors. If you get really desperate, as I have twice, you can mail the authors and ask very nicely for a copy - most authors want to help. I'm planning on offering hosting for some authors who don't have web pages of their own, because I'd like to see their papers online but they don't have time to maintain them. I go to a lot of work to make my online papers as useful as possible: see http://www.ciphergoth.org/ for examples.
This has to be the future. It's crazy to make amateurs like I was jump through hoops to get access to this information, there's no longer any sane reason for it. I hope the move away from print publications for academia happens as fast as possible and if there's anything I can do to hasten it, I'm there.
--
I've barely been back in Britain for two days after visiting Tokyo and Yokohama, and I find this - cool! Though I now live in Edinburgh, I was born and brought up in London and visit often so the comparison is interesting.
The "Mobile Girls". In this, I don't actually think Japan is any different from the UK, or Germany or Sweden. Here in Europe practically everyone between 11 and 40 has a mobile phone (and lots of other people too), and the girls can text like lightening here too. My little sisters have a mobile and they can text faster than I can. The amazing thing about the Japanese girls is that they can do it in Kanji! A friend I met there demonstrated: you enter what you want to say in a phonemic form, then the 'phone offers you several ways to say the same thing in Kanji script. That, combined with the larger screens of the iMode phones, means it's convenient to receive much longer messages.
Oh, and DoCoMo phones can receive email as conveniently as a text message. I wish I had that.
Technology adoption. In Tokyo, I got the net from an Ethernet cable in my hotel room. Damn fast too. I wish I'd had the same in Yokohama.
Conformism. I don't think it's as bad as people say. Certainly the streets of Tokyo don't look like the humourless regiments people seem to imagine, just people holding hands, laughing and enjoying themselves at the weekend in the glorious weather under the cherry blossom. I went to a Tokyo goth club and it was a fabulous experience - you can see pictures at
www.cluefactory.org.uk/paul/photos/tokyo/eve/
- no conformism there!
I've never been that far away before - Tokyo was a real eye-opener, and while there were many unusual things (Pocari Sweat is called that because it's an isotonic sports drink), the Japanese are not the aliens people seem to think. And don't worry about the politeness rules too much, they're used to gaijin getting it wrong, just don't blow your nose in public...
--
The general category for such software is "malware".
--
--
First, it would cost you a fair bit just to get this thrown out of court. Most likely, though, it won't be thrown out, it'd come to trial. By the time of the trial date, the prosecution would be citing it as part of their evidence and claiming it's new for some stupid trivial reason. And it'll cost you tens of thousands of dollars to contest.
It's important to understand that being in the right, morally or legally, is barely of the least importance here.
--
Sometimes those who say "I don't like to use or contribute to that piece of software, because although it's free beer, I don't like the license" get accused of whining: "hey, it's free, if you don't like it don't use it but don't whine about it". The real lesson to draw from this is that licenses *do* matter and it's worthwhile discussing what we want out of them.
--
No details of PDF have been kept secret in the hope of making this scheme stronger. The scheme explicitly relies on implementors agreeing to honour it. Adobe have thought about digital signatures, but it's tricky to get right, so they've put it off for future releases.
--
As "circumvention devices" go, it's not DeCSS. It's not even CueCat. It's more like rot-13.
--
A "white hat" is someone who understands security, and uses it to advance security, not to break into other people's systems without their permission. For example, I'd concur with the people who put the "Powered by IIS" message on www.apache.org that this was a gray hat activity, not white hat as Apache said.
I can think of situations where breaking into systems without permission would be justifiable (happens all the time in Buffy!) but it's still Black Hat, I think.
--
...they always mean "Distinctions between one kind of egg and another are never relevant".
And it's just *never* true. The assertion that "criminals are criminals" mindlessly lumps in Nelson Mandela with Jeffery Dahmer. "Hacking is hacking" puts RMS in the same category as RTM.
As it happens, I'm generally against breaking into computer systems as a political act; I just thought you should know that statements like "criminals are criminals" is a big flag that you're going to be talking nonsense.
--
Amazon will survive. They have a way of making actual money: profit off book sales. And they don't have to cut their margins to the bone: they aren't the cheapest book site on the Web by any means, but they use convenience to keep their customers.
Yes, I know the one-click patent is evil. I'm not discussing what should be here, but what I think will be.
--
Sealand has multiple connectivity into the UK and into Amsterdam.
Now, maybe all of those ISPs will capitulate. But supposing they don't? Supposing, say, one of the well-connected Amsterdam ISPs stands firm, and is backed up by the Amsterdam court? I don't think the RIAA are going to try and cut off Amsterdam, which is a major Internet hub for Europe, but maybe they'll demand that US ISPs fake the routing tables so you can't route to Sealand? Then another offshore alternative opens up, more routing frob...
Eventually the RIAA and MPAA will demand that the Internet as we know it be dismantled in favour of a networking protocol that is better at supporting censorship. Eventually they'll demand an Internet that has "providers", who are big companies that can afford legal fees and scrupulously provide only legal content, and "users" who can send email and read content provided by "providers" but who can't afford the legal fees needed to publish anything, and whose communication with each other is heavily mediated by the "providers" taking legal responsibility. They'll want changes to the law, backed by new international conventions, that make even Slashdot illegal, because Slashdot can't guarantee someone won't put DeCSS here.
They won't necessarily get what they demand, but they will eventually be forced to demand it if their position is to make any sense at all. And they're not the kind of people to say "OK, that would be too nasty, we'll concede defeat."
--
Schneier voiced exactly that opinion in a recent Cryptogram.
--
I know crypto though - see my Web pages. Explain it to me.
--