I don't really like IPv6 for several reasons, which I won't go into here.
But one thing IPv6 would solve for me is this problem:
My (Japanese) ISP is not anxious to have me serving the web from my house. (Not sure if I blame them, if there were a lot of people like me among their customers they'd probably have to start metering us and charging a few yen per GB of upload over some limit each month.) Anyway, a single static IP address from them would cost JPY6000 a month, if I remember right (and if things haven't changed).
IPv6 would take away their excuse for asking for so much money. I'm guessing they'd be hard pressed to find an excuse for not giving me a whole range of static addresses.
Of course, they could claim something about security and require DHCP anyway, I suppose.
The point is, the internet is supposed to evolve until every home has a communications server in their phone. Want a blog? On your own server. Blog gets popular? pay your ISP USD3.00 a month or something to mirror it. Mail? Web site? News? Etc.? On your phone.
NAT in its present form takes too much tweaking to do that.
You talk about whining, I just had to try to help my daughter try to figure out why she didn't want to take the trash out.
You didn't provide links. That's no sin, but the searches I did that day didn't seem to produce the tools that run under Linux. I can't say why, because when I search now I see lots of stuff that appears to run under Linux.
But that day, I ended up at atmel's site, and the only thing I saw in about fifteen minutes of searching that site was stuff like
I didn't even see a nod to free-as-in-freedom software. Sure, I could tell from other pages that they use GCC, but that doesn't mean anything. Lots of companies use GCC under MSWindows in ways that are compatible with the letter of the GPL but don't really give back to the community. Some even deliberately make it hard to move their stuff to Linux. I've been down those roads before, I don't have time to waste doing that any more.
Sometimes, being obscure is cool. Sometimes it gets in the way.
I think you misunderstand identity. That's not surprising. Many people do.
Something you have, something you know, something you are.
Huh? That's really just three things you have. A fingerprint is something you have until that finger gets cut off (either by accident or by someone bent on stealing your luxury car that uses fingerprints to open it). Something you know is just a bit of knowledge you have stored in your brain. An intangible possession, but a possession, nonetheless.
It's a little clearer if we say it this way:
(1) A tangible easily alienable possession, some sort of physical key; (2) an intangible but easily lost possession, some sort of password (OK, passphrase); (3) a tangible and difficult-to-alienate possession, basically a part of the body.
And when you say it like that, you see how ridiculous it all is. Three keys. Redundancy. That's all it means, except that the CAs managed to use the idea for a while to sell their product for more than even they claimed it was.
The current PKA is all upside down. Thawte should be sumbitting their certificates to us for arbitration, not the other way around. And that's why it should be open source, so that we control it.
and a user interface that allows (requires!) the user to control the trust structures built and accessed by the clients.
No closed-source company will do this. Not so much because the PHBs won't allow it, but because closed source will always end up hiding something that shouldn't be hidden. Open source teams will (eventually) get the interface right and get the internals matching the interface.
Only the attachment containing the information you don't want made public needs to be encrypted.
It would be "nice" if the browser could automatically read the attachment, but think about it. If you get a pin number in the mail from your bank, do you open it up out by the mailbox, or do you take it inside and open it up at your desk? (Inside so you can control the amount of observation, at your desk so you don't lose the letter.)
Here in urban Japan, yes, there will almost always be someone who passes close enough by as you are looking at the letter that they could catch a surreptitious glance if you look at it outside. Some places, you really would even want to draw your drapes before you open the envelope.
Why not encrypt the whole thing? Specifically because you don't really want your MUA decrypting it, even if you think it's inconvenient that it doesn't.
I know people who say they do and then behave like they do, for some limited definition of trust.
But the truth is, no, you don't. Not really.
There are multiple roots in every one of your multiple real-world webs of trust. None of the real roots got to be roots by either taking your money or giving money to you. Some of the near-roots may have, and that can be confusing.
Well, you may have a single, ultimate root of trust, but that would by definition be your God. And, by definition, it would be hard to pin down, and hard to prostitute to the service of financial transactions. Unless you just have a pathologically low level of self-confidence.
Trust is not really something that can be automated. We can make an automated database of trust information, but when we try to automate the handshakes of trust, we are operating counter to reason, and counter to our own best interests.
All for the little convenience of on-line transaction. (Or something similar.)
If your financial institution builds its own browser (or contracts it out) it can put whatever certificate in it wants. In fact, if the dedicated browser does nothing but authorize a shopping cart previously filled on an unsecured web page, the dedicated browser doesn't even need a certificate. All it needs is one-time pads and an asymmetric key to talk to the bank. The bank could then talk to the vendor and verify some stamp on the cart, with the amount.
Certificates in a dedicated browser could perhaps make it possible to help a financial institution and a vendor who don't know each other get along, I suppose.
Dedicated browsers are necessary. I little bar in the browser will eventually be faked, and there will be a lot of Joe Sixpacks who ignore it and finance the cracker while he's figuring out how to fake it.
A dedicated browser simply refuses to connect. You get the browser and the CD with the current one-time pads and the bank's asymmetric keys from the brick-and-mortar local office of the financial institution.
Other than that, yeah, the user should be in direct control of the trust structures he builds. Otherwise, he can't trust it. The best the automated stuff can do is help the user make the distinction between the several webs of trust and their meanings.
In the real world, we have multiple roots of trust. It should be the same in the networked world.
Just because the guys who thought up X509 couldn't wrap their heads around a plex, doesn't mean that we should turn back to that single-rooted single hierarchy. (Actually, they did understand it, sort of. Just all the people who stopped after the first chapter in the book that are stuck in the hierarchical sewage plug.)
People who (emotionally) need faceless on-line shopping should pay extra service charges and put up with some extra steps for the authentication.
Alternately-abled individuals should be able to get the extra fees waived.
The rest of us can jolly well take a walk to a local authentication center where someone who probably recognizes us our face can check the photo-id on the card, log into the appropriate merchant network, and put an ack signal on the purchase we've just made on-line. Could be a convenience store clerk or somebody at the [insert-name-of-superstore] service desk, or a postal clerk. (And keep Microsoft software and any general-purpose web browser, including Firefox, well away from the authentication network. In fact, the authentication network should not be visible from the web.)
What about the faceless on-line shopping?
Dedicated software browsers, one for each of your financial institutions. They are programmed with one-time pads and asymmetric authentication, so they just won't even connect with anyone but the financial institution they are programmed for. You go to your brick and mortar local office when you need a new one-time pad and when you first get the client app.
And they do not run on any general purpose PC or PDA. They run on a (probably somewhat standardized) $100 box that has a smallish, cheap LCD (type) screen and a smallish keyboard and plugs directly into your hub or router, not into your PC. (Yeah, I know the router is still a weak point, but we can work on that as well, once everyone realizes just how much of a mirage the junk Microsoft has been selling is.) You can browse the shop with your general purpose browser, and set up the cart, but you have to use the dedicated box to authorize the purchase.
So I look up SRP on google and it looks like you're talking about the stanford remote password protocol.
So I look on the competitive analysis (or something) page and I read something about Arcot Systems offering a software based multifactor and it seems to be recommended as stronger than ssh.
Red flags.
Any cryptographic key is subject to the physical possession vulnerability _by_ _definition_. Trying to handle parts of it in software just drops the bar. There are two problems with the hardware token.
One is that, just like a lock is pickable, hardware tokens can be analyzed.
(One advantage of tumblers is that picking a lock requires a certain amount of expertise to perflorm without being obvious. Electronic keys can be analyzed, well, electronically.)
The other is that the token is subject to the man in the middle. (The collars on card readers at ATMs in the UK, are one example, MSWindows 'bots are another.)
If a bot has a an encrypted software token on it, it has the library to read it, the library can be used by the parasite as easily as by the host. Anybody recommending a protocol that is supposed to be better than ssh who doesn't recognize this can't be trusted.
Their characterization of SSH as a "pseudo-strong" method (ergo, inferior to srp) seems to be entirely based on SSH's ability to fall back. If falling back is a problem,/etc is your friend. Near as I can tell without taking more time than I want to, the only advantage they can claim for srp is the lack of fallback.
Part of the plan with the half gig flash disk was that the data would be stored on the school's server.
Perhaps the reality that there are a lot of places where the OLPC should go where the expectation of a school server won't be met is part of the reason for the larger flash, and they just increased the RAM to reduce thrashing while they were at it.
Also, I note that Java is part of the spec now.
I'd as soon they leave Java off, myself. I tend as much to suspect that the OLPC community has been sucked into the gotta-have-the-kitchen-sink trap as to suspect the M$ trap.
But if we do expect some of the kids to hack the kernel, there's also got to be room on persistent store for the toolchain, and a USB drive really is not a good place to keep the toolchain.
Slashdot Mirror
Maybe he things IPv6 would prevent hiding behind a NAT.
I don't really like IPv6 for several reasons, which I won't go into here.
But one thing IPv6 would solve for me is this problem:
My (Japanese) ISP is not anxious to have me serving the web from my house. (Not sure if I blame them, if there were a lot of people like me among their customers they'd probably have to start metering us and charging a few yen per GB of upload over some limit each month.) Anyway, a single static IP address from them would cost JPY6000 a month, if I remember right (and if things haven't changed).
IPv6 would take away their excuse for asking for so much money. I'm guessing they'd be hard pressed to find an excuse for not giving me a whole range of static addresses.
Of course, they could claim something about security and require DHCP anyway, I suppose.
The point is, the internet is supposed to evolve until every home has a communications server in their phone. Want a blog? On your own server. Blog gets popular? pay your ISP USD3.00 a month or something to mirror it. Mail? Web site? News? Etc.? On your phone.
NAT in its present form takes too much tweaking to do that.
I wish someone would tell my ISP that they've already got IPv6 running.
I'm guessing they're going to want to enforce the property of the tape.
You talk about whining, I just had to try to help my daughter try to figure out why she didn't want to take the trash out.
t ool_id=2725
You didn't provide links. That's no sin, but the searches I did that day didn't seem to produce the tools that run under Linux. I can't say why, because when I search now I see lots of stuff that appears to run under Linux.
But that day, I ended up at atmel's site, and the only thing I saw in about fifteen minutes of searching that site was stuff like
http://www.atmel.com/dyn/products/tools_card.asp?
I didn't even see a nod to free-as-in-freedom software. Sure, I could tell from other pages that they use GCC, but that doesn't mean anything. Lots of companies use GCC under MSWindows in ways that are compatible with the letter of the GPL but don't really give back to the community. Some even deliberately make it hard to move their stuff to Linux. I've been down those roads before, I don't have time to waste doing that any more.
Sometimes, being obscure is cool. Sometimes it gets in the way.
Heh.
Didn't I say that? (I don't recall saying anything to indicate I thought that Microsoft was involved in making the dev tools, now did I?)
"That's where I stopped reading."
Yeah, and that's why you fail to understand yourself.
Well, the dev tools seem to all run under MSWindows. that lets me out of that one, since I don't own any Microsoft software.
The Chumby looks kind of interesting, though.
the AC parent mentions wikipedia.
I'd mod him/her up, but I decided to comment instead of using mod points.
is any less of an oxymoron?
I think you misunderstand identity. That's not surprising. Many people do.
Something you have, something you know, something you are.
Huh? That's really just three things you have. A fingerprint is something you have until that finger gets cut off (either by accident or by someone bent on stealing your luxury car that uses fingerprints to open it). Something you know is just a bit of knowledge you have stored in your brain. An intangible possession, but a possession, nonetheless.
It's a little clearer if we say it this way:
(1) A tangible easily alienable possession, some sort of physical key;
(2) an intangible but easily lost possession, some sort of password (OK, passphrase);
(3) a tangible and difficult-to-alienate possession, basically a part of the body.
And when you say it like that, you see how ridiculous it all is. Three keys. Redundancy. That's all it means, except that the CAs managed to use the idea for a while to sell their product for more than even they claimed it was.
The current PKA is all upside down. Thawte should be sumbitting their certificates to us for arbitration, not the other way around. And that's why it should be open source, so that we control it.
joudanzuki
and a user interface that allows (requires!) the user to control the trust structures built and accessed by the clients.
No closed-source company will do this. Not so much because the PHBs won't allow it, but because closed source will always end up hiding something that shouldn't be hidden. Open source teams will (eventually) get the interface right and get the internals matching the interface.
Only the attachment containing the information you don't want made public needs to be encrypted.
It would be "nice" if the browser could automatically read the attachment, but think about it. If you get a pin number in the mail from your bank, do you open it up out by the mailbox, or do you take it inside and open it up at your desk? (Inside so you can control the amount of observation, at your desk so you don't lose the letter.)
Here in urban Japan, yes, there will almost always be someone who passes close enough by as you are looking at the letter that they could catch a surreptitious glance if you look at it outside. Some places, you really would even want to draw your drapes before you open the envelope.
Why not encrypt the whole thing? Specifically because you don't really want your MUA decrypting it, even if you think it's inconvenient that it doesn't.
joudanzuki
them?
I know people who say they do and then behave like they do, for some limited definition of trust.
But the truth is, no, you don't. Not really.
There are multiple roots in every one of your multiple real-world webs of trust. None of the real roots got to be roots by either taking your money or giving money to you. Some of the near-roots may have, and that can be confusing.
Well, you may have a single, ultimate root of trust, but that would by definition be your God. And, by definition, it would be hard to pin down, and hard to prostitute to the service of financial transactions. Unless you just have a pathologically low level of self-confidence.
Trust is not really something that can be automated. We can make an automated database of trust information, but when we try to automate the handshakes of trust, we are operating counter to reason, and counter to our own best interests.
All for the little convenience of on-line transaction. (Or something similar.)
joudanzuki
If your financial institution builds its own browser (or contracts it out) it can put whatever certificate in it wants. In fact, if the dedicated browser does nothing but authorize a shopping cart previously filled on an unsecured web page, the dedicated browser doesn't even need a certificate. All it needs is one-time pads and an asymmetric key to talk to the bank. The bank could then talk to the vendor and verify some stamp on the cart, with the amount.
Certificates in a dedicated browser could perhaps make it possible to help a financial institution and a vendor who don't know each other get along, I suppose.
Dedicated browsers are necessary. I little bar in the browser will eventually be faked, and there will be a lot of Joe Sixpacks who ignore it and finance the cracker while he's figuring out how to fake it.
A dedicated browser simply refuses to connect. You get the browser and the CD with the current one-time pads and the bank's asymmetric keys from the brick-and-mortar local office of the financial institution.
Other than that, yeah, the user should be in direct control of the trust structures he builds. Otherwise, he can't trust it. The best the automated stuff can do is help the user make the distinction between the several webs of trust and their meanings.
joudanzuki
In the real world, we have multiple roots of trust. It should be the same in the networked world.
Just because the guys who thought up X509 couldn't wrap their heads around a plex, doesn't mean that we should turn back to that single-rooted single hierarchy. (Actually, they did understand it, sort of. Just all the people who stopped after the first chapter in the book that are stuck in the hierarchical sewage plug.)
everyone has to be their own first CA.
is actually the only solution.
People who (emotionally) need faceless on-line shopping should pay extra service charges and put up with some extra steps for the authentication.
Alternately-abled individuals should be able to get the extra fees waived.
The rest of us can jolly well take a walk to a local authentication center where someone who probably recognizes us our face can check the photo-id on the card, log into the appropriate merchant network, and put an ack signal on the purchase we've just made on-line. Could be a convenience store clerk or somebody at the [insert-name-of-superstore] service desk, or a postal clerk. (And keep Microsoft software and any general-purpose web browser, including Firefox, well away from the authentication network. In fact, the authentication network should not be visible from the web.)
What about the faceless on-line shopping?
Dedicated software browsers, one for each of your financial institutions. They are programmed with one-time pads and asymmetric authentication, so they just won't even connect with anyone but the financial institution they are programmed for. You go to your brick and mortar local office when you need a new one-time pad and when you first get the client app.
And they do not run on any general purpose PC or PDA. They run on a (probably somewhat standardized) $100 box that has a smallish, cheap LCD (type) screen and a smallish keyboard and plugs directly into your hub or router, not into your PC. (Yeah, I know the router is still a weak point, but we can work on that as well, once everyone realizes just how much of a mirage the junk Microsoft has been selling is.) You can browse the shop with your general purpose browser, and set up the cart, but you have to use the dedicated box to authorize the purchase.
So I look up SRP on google and it looks like you're talking about the stanford remote password protocol.
/etc is your friend. Near as I can tell without taking more time than I want to, the only advantage they can claim for srp is the lack of fallback.
So I look on the competitive analysis (or something) page and I read something about Arcot Systems offering a software based multifactor and it seems to be recommended as stronger than ssh.
Red flags.
Any cryptographic key is subject to the physical possession vulnerability _by_ _definition_. Trying to handle parts of it in software just drops the bar. There are two problems with the hardware token.
One is that, just like a lock is pickable, hardware tokens can be analyzed.
(One advantage of tumblers is that picking a lock requires a certain amount of expertise to perflorm without being obvious. Electronic keys can be analyzed, well, electronically.)
The other is that the token is subject to the man in the middle. (The collars on card readers at ATMs in the UK, are one example, MSWindows 'bots are another.)
If a bot has a an encrypted software token on it, it has the library to read it, the library can be used by the parasite as easily as by the host. Anybody recommending a protocol that is supposed to be better than ssh who doesn't recognize this can't be trusted.
Their characterization of SSH as a "pseudo-strong" method (ergo, inferior to srp) seems to be entirely based on SSH's ability to fall back. If falling back is a problem,
in which parts do the light skinned Amazon natives live? the parts that are rain forest part or the part that aren't, or some combination of both?
joudanzuki, thinking about paper mills
doncha think?
Part of the plan with the half gig flash disk was that the data would be stored on the school's server.
Perhaps the reality that there are a lot of places where the OLPC should go where the expectation of a school server won't be met is part of the reason for the larger flash, and they just increased the RAM to reduce thrashing while they were at it.
Also, I note that Java is part of the spec now.
I'd as soon they leave Java off, myself. I tend as much to suspect that the OLPC community has been sucked into the gotta-have-the-kitchen-sink trap as to suspect the M$ trap.
But if we do expect some of the kids to hack the kernel, there's also got to be room on persistent store for the toolchain, and a USB drive really is not a good place to keep the toolchain.
But the spectre of MSWindowsCE is troublesome.
what are you thinking?