Difference between revisions of "User:Which Linden/Office Hours/2008 Sep 18"

From Second Life Wiki
Jump to: navigation, search
(New page: * [11:03] FWord Utorid: how long until the twigs are here? * [11:03] Saijanai Kuhn: Though... was that his REAL name or just a college nickna...)
 
(Category)
Line 315: Line 315:
 
* [12:14] [[User:Graph Weymann|Graph Weymann]]:  Ash, did you cover crypto-sealers-and-object-sealers?
 
* [12:14] [[User:Graph Weymann|Graph Weymann]]:  Ash, did you cover crypto-sealers-and-object-sealers?
 
* [[User:Which Linden|Which Linden]]
 
* [[User:Which Linden|Which Linden]]
 +
 +
[[Category: AW Groupies Transcripts]]

Revision as of 16:48, 18 September 2008

  • [11:03] FWord Utorid: how long until the twigs are here?
  • [11:03] Saijanai Kuhn: Though... was that his REAL name or just a college nickname...
  • [11:03] FWord Utorid: oh, there we go. hey which
  • [11:03] Which Linden: Yo
  • [11:03] Saijanai Kuhn: nods at t"the twigs"
  • [11:03] Morgaine Dinova: Hiya Which :-)
  • [11:04] Vernes Veranes: That avatar is pure genius
  • [11:04] FWord Utorid: it would be even better if he had a bamboomobile
  • [11:05] FWord Utorid: personally, i think which linden is a ... stalker
  • [11:05] Which Linden: Hey.... ooh that was a good one
  • [11:05] Sheryl Mimulus: hehe
  • [11:06] Which Linden: so what y'all been up to?
  • [11:06] Saijanai Kuhn: writing a GUI for pyogp
  • [11:06] FWord Utorid: waiting for Sai to finish the hard work on that so I can have something to play with
  • [11:07] Which Linden: ha ha, nice
  • [11:07] Morgaine Dinova: Exploring Creative Commons music :-)
  • [11:07] Saijanai Kuhn: bah, shouldn't be this hard. brain is just rusty (corroded shut)
  • [11:07] Which Linden: what GUI framework are you using?
  • [11:07] Saijanai Kuhn: wx
  • [11:07] Durante Franizzi: Was writing a security patch to handle a 0-day issue this morning, now I'm collecting dust while appearing busy at work
  • [11:07] Saijanai Kuhn: tried tk but was too primitive (reminded me of SL GUI for some reason)
  • [11:07] Sheryl Mimulus: lol
  • [11:08] Which Linden: pwned
  • [11:08] Sheryl Mimulus: tk is okay for simple stuff
  • [11:08] Saijanai Kuhn: is pretty sure that original SL GUI lib is a straight port from TK
  • [11:08] Sheryl Mimulus: it quickly gets overloaded
  • [11:09] Which Linden: So.... did folks read mscheffeler's thesis?
  • [11:09] Saijanai Kuhn: I did. still unclear on a few details
  • [11:09] Latha Serevi: Yep
  • [11:09] Which Linden: Don't feel bad if you didn't -- I nearly didn't
  • [11:09] FWord Utorid: I don't know if there was a set agenda for today, if there was then ignore me, but i was wondering how far off a system for opensim L$ api would be
  • [11:09] FWord Utorid: i know you have the diagram and all
  • [11:09] Morgaine Dinova: I haven't, but it's in the browser.
  • [11:09] Which Linden: FWord
  • [11:09] Which Linden: uh
  • [11:10] Which Linden: there is no schedule yet
  • [11:10] FWord Utorid: it's ok :)
  • [11:10] Which Linden: if it's OK I'd like to discuss the thesis
  • [11:10] FWord Utorid: I have a nice rackmount system waiting to be assembled, I'd eventually like to have my own little world going and have people able to do the fundamentals
  • [11:10] Which Linden: sort of a thesis discussion group
  • [11:10] Latha Serevi: sounds great
  • [11:11] Morgaine Dinova: I'll try to stay one page ahead of the discussion :P
  • [11:11] Durante Franizzi: Need a sec, fixing something - brb
  • [11:11] Which Linden: Sai -- what were you hoping for clarification on?
  • [11:12] Saijanai Kuhn: eh, Graph mentioned the caps that could be passed around without need for a separate key.
  • [11:12] Saijanai Kuhn: though I think I may have heard it wrong
  • [11:12] Which Linden: Yeah -- ok we saw the same thing, I think
  • [11:13] Which Linden: I forget which page this is... looking....
  • [11:13] Which Linden: but somewhere it says that you don't need to use cryptography to seal a cap
  • [11:14] Which Linden: p28
  • [11:14] Saijanai Kuhn: was thinking that it was talkign about a script in E embedded in the data to unock the cap but
  • [11:14] Which Linden: " although no actual encryption takes place; the sealed box protects its contents
  • by encapsulation."
  • [11:15] Which Linden: So did we have the same confusion, or are you talkign about a different part?
  • [11:16] Morgaine Dinova: How does encapsulation protect contents?
  • [11:16] Saijanai Kuhn: that one I think
  • [11:16] Saijanai Kuhn: Sealers vs encryption
  • [11:17] Latha Serevi: The E language, with capabilities, built in, is an interesting illustration of this stuff; but our open grid world is pretty much precluded from being built "inside" any such secure environment. So, perhaps we'll need to do more explicit security?
  • [11:18] XLR8RRICK Hudson: hello everyone
  • [11:18] Saijanai Kuhn: not sure how sealer/unsealer pattern is different than a regular cap
  • [11:18] Which Linden: Yeah -- I dunno how encapsulation is equivalent to encryption
  • [11:19] Which Linden: My guess is -- because the E runtime enforces a lot of things that are not enforceable over the wild internet, they can make guarantees like that that would require crypto over an unsecured transport
  • [11:20] Saijanai Kuhn: ah, thinking maybe you request encryption (sealing) from a third party, which returns the encrypted (selaed) version which you can hand off to anyone
  • [11:20] Which Linden: I noticed that in E, you can see a capability that you cannot use
  • [11:20] Sheryl Mimulus: sounds like security through obscurity
  • [11:21] Latha Serevi: not at all, Sheryl, to me
  • [11:21] Latha Serevi: keeping a password secret is not security-through-obscurity
  • [11:21] Morgaine Dinova: We'll have expiring capabilities too, so those will be caps that are held but unusable after a while too.
  • [11:22] Latha Serevi: I haven't spent much time immersed in the capability worldview; the idea of generating and giving out the most-specific capability possible makes much sense, and minimizes risk; so a lot of capabilities we give out could be so specific (perhaps even tied to the individual and the moment) that encryption would be superfluous.
  • [11:22] Saijanai Kuhn: Lath yeah, but don't think this is the sealer/unsealer pattern mentioned
  • [11:22] Latha Serevi: Then again, the "seed cap" seems like a master key to the world, and I need to learn how paranoid to be about it.
  • [11:22] Sheryl Mimulus: I was refering to encapsulation, not caps
  • [11:22] Saijanai Kuhn: it SEEMS liek it might be useful for establishing secure communications even through the relatively insecure Agent Domain, but not sure
  • [11:23] Which Linden: So -- the purpose of a "sealed" capability, in the thesis, is to package up a capability so that a third party can send thesealed cap along, and only the recipient can "unseal" it and use it
  • [11:23] Sheryl Mimulus: encapsulation generifies the contents.. so its not encryption
  • [11:23] Morgaine Dinova: I'm looking forward to non-restricted worlds appearing and interop'ing, as they'll be simpler and might well progress a lot faster. We have a rod for our backs with perms.
  • [11:23] Which Linden: I think that in our http-based caps system we'd definitely do that via PKI
  • [11:24] Saijanai Kuhn: MOrgaine, lots ofdifferent kinds of permissions system. The thesis decribes a world with a caps-based system with no central authority
  • [11:24] Morgaine Dinova: Sounds good
  • [11:25] Which Linden: Yes, it seemed as though the thrust of the thesis was to prove that such a thing could be done
  • [11:25] Latha Serevi: Morgaine, in the metaphor, does the rod keep my back straight, or whip my backside?
  • [11:26] Morgaine Dinova: Well, just as long as it;s not inserted ...
  • [11:26] Latha Serevi: I interpret the sealer/unsealer pattern as the "E" equivalent of an encrypted communication.
  • [11:26] Saijanai Kuhn: [1] the reference to sealer/unsealer pattern
  • [11:27] Morgaine Dinova: Tnx Sai
  • [11:27] FWord Utorid: when do we get pdf on a prim?
  • [11:27] FWord Utorid:  :P
  • [11:27] Morgaine Dinova: It's coming out right after DNF
  • [11:28] FWord Utorid: [2]
  • [11:28] Which Linden: thanks for the link sai
  • [11:28] Saijanai Kuhn: page 18
  • [11:30] Morgaine Dinova: FWord: there's a hint in the disambiguation page here --- [3]
  • [11:31] FWord Utorid: morgaine, i am pretty sure which DNF you were referencing ;)
  • [11:31] Morgaine Dinova: Heh
  • [11:31] Saijanai Kuhn: so really, for our purposes, you need to have a trusted third party (or 2) for the sealing/unsealing, and establish communications with it/them without the knowledge of the AD
  • [11:32] Latha Serevi: Surely not, Sai!
  • [11:32] Morgaine Dinova: I like the line "It was won several vaporware awards."
  • [11:32] Latha Serevi: My own mental model was, we could always public-key-encrypt
  • [11:32] Which Linden: Yeah
  • [11:32] Durante Franizzi: seems so, yes.. unless you're going to go trust-based with multiple sets of keys.. one public, one private.. 3 or more to certify, with IPsec.. from a 3rd party grid link, anyway
  • [11:32] Which Linden: So the sealer knows your public key
  • [11:32] Saijanai Kuhn: sure, that's an alternative. This is encryption without the client being involved directly either
  • [11:33] FWord Utorid: would xmpp support this sort of scenario?
  • [11:33] Durante Franizzi: Pardon me if that was mentioned, missed the first part of the discussion earlier :)
  • [11:33] Latha Serevi: (PKE is sort of a bottom line default to show we don't need 3rd parties necessarily; alhough since in VR's we know we have a lot of 3rd parties "up and accessible" we'll probably do less of that than most)
  • [11:33] Saijanai Kuhn: we're just trying to understand a reference to sealer/unsealer in the thesis on virtual worlds and caps
  • [11:34] Durante Franizzi: affirmative, thank ya
  • [11:34] Which Linden: Yeah -- so to resolve the question about the thesis I think the existence of a runtime explains it
  • [11:34] Saijanai Kuhn: [4] with reference to sealer/unsealer pattern found here on page 18: [5]
  • [11:34] Which Linden: The major difference between the caps of E and LL's caps is the runtime
  • [11:35] Durante Franizzi: thank you Sai
  • [11:35] Saijanai Kuhn: right. E's caps are generated by the language, while SL's caps are generated by the server
  • [11:35] Which Linden: So, in E, you can have a cap without being able to use it, because the runtime prevents you
  • [11:36] Which Linden: And likewise you can fail to unseal a sealed cap because the runtime stops you
  • [11:36] Which Linden: I thought the most useful part of the thesis was the design patterns
  • [11:37] Morgaine Dinova: We'll have the same though, because our capabilities will expire (some of them)
  • [11:37] FWord Utorid: i expect to crash soon
  • [11:38] Saijanai Kuhn: yeah, though its sometimes hard for me to translate the pattern as used in E to the equivalent in SL's space
  • [11:38] Latha Serevi: In LL caps, must a cap be generated by the same entity that will check it later? (so it can save its random number away?) I'm trying to understand if we have a bit of work to do in going to the opengrid world. Do we need caps that can be used in multiple places and must be "checked" by a 3rd party, or can we make sure they're always locally-generated. I hope this question makes sense.
  • [11:38] Which Linden: Latha: what do you mean by "checking"?
  • [11:38] Latha Serevi: "is this a valid cap for this operation"
  • [11:39] Which Linden: Oh... that's the cap uh.... host
  • [11:39] Saijanai Kuhn: well, the server that handles the url does the checking as it handles the URL, right?
  • [11:39] Which Linden: Yeah
  • [11:39] Saijanai Kuhn: so if its a valid url, then its a valid operation, one hopes
  • [11:40] Which Linden: [6]
  • [11:40] Which Linden: Yes, exactly as Sai says -- if you have a url that the cap server knows about, you can do the operation that the cap is assigned to do
  • [11:40] Which Linden: I guess then, Latha's question is about where the caps are generated
  • [11:41] Stirling Allen: That is the point of a cap system, by the time it reaches the token, the token is assumed to be valid.
  • [11:41] Which Linden: I.e. if all caps go through caps.sl.com or if you could grant them from caps.mydomain.com
  • [11:41] Latha Serevi: So perhaps my question translates to, how do we define the mapping between caps and operations. Say, I'm a region that wants to create a cap that can rezz an object in me. Whaty do I do next?
  • [11:42] Stirling Allen: We have to assume in an interop world that caps can be generated by any entity that uses the protocol. Client, AD, RD or other.
  • [11:42] Which Linden: Ah....well there's a section in the thesis that deals with cap meta-data, that might be sort of useful to stimulate ourthinking
  • [11:42] Latha Serevi: (rezz an object in me, today, if your name is Saijanai?) (I need to have a caps server running inside "myself"?)
  • [11:42] Which Linden: But generally, Latha, at the time that the cap is granted, both parties have to know about what it does
  • [11:43] Saijanai Kuhn: though, you can have an interrogation protocol defined forany cap in the system
  • [11:43] FWord Utorid: good cap, bad cap?
  • [11:43] Saijanai Kuhn: with a default response of "not telling--you need to already know"
  • [11:44] Latha Serevi: (am I always the grantor of all caps relevant to me? I doubt it. So how do I "hear about" a cap being invoked on some other grantor?)
  • [11:44] Which Linden: Yeah, but that doens't help you if the interrogation says the caps does "Operation FooBar" and you don't know what FooBar means
  • [11:44] Which Linden: AH -- ok, so now, Latha, you're talking about granularity of cap granting
  • [11:44] Stirling Allen: Latha: no, an entity can grant to another entity a cap that will allow the other entity to generate caps.
  • [11:45] Scooter Back: would need to establish keys to the cap to determine if the cap is trusted. Kinda like pgp
  • [11:45] Latha Serevi: I'm trying to understand the network of caps-passing-around-and-generating that we would need in order for me to control who rezzes objects in my region.
  • [11:45] Scooter Back: a 3rd party that has trust can mediate between two that don't
  • [11:46] Latha Serevi: ...and whether my own process must generate a random number for each operation to be done.
  • [11:46] Scooter Back: "the friend of my friend is my friend" approach
  • [11:46] FWord Utorid: it is like shaking hands with Vishnu
  • [11:46] Latha Serevi: Scooter, that sounds like what I'm trying _not_ to do
  • [11:46] Ash Venkman: howdy.
  • [11:47] Saijanai Kuhn: hey ash
  • [11:47] Durante Franizzi: Agreed, 3 or more 'trusted' signing for each other through a 3rd party.. which keeps a few types of attacks out of the equation, and would cut down on grid instability
  • [11:47] Which Linden: Latha, by "me" do you mean your agent, or you personally, or a region under your control?
  • [11:47] Latha Serevi: region under my control
  • [11:47] Scooter Back: but it would increase traffic
  • [11:47] Ash Venkman: Sai said there was a question about sealers/unsealers?
  • [11:47] Scooter Back: on that third party
  • [11:47] Scooter Back: and create a potential single point of failure
  • [11:48] Latha Serevi: Ash, yes, we were trying to figure out whether sealer/unsealer is just the "E" equivalent of an encrypted envelope.
  • [11:48] Ash Venkman: They're equivalent in some ways ---
  • [11:48] Durante Franizzi: which is why I mentioned signing for each other - the 3rd party is just to certify/document that they are, similar to lines conf on an IRCD
  • [11:48] Which Linden: Ash -- yeah, what Latha said -- it seems as though E's implementation of sealing does not use encryption, so how does it guarantee that things are secure?
  • [11:48] Ash Venkman: in a distributed system, you can implement them with public/private keys
  • [11:49] Saijanai Kuhn: LOL.
  • [11:49] Durante Franizzi: which if they split, or lose effective hub, communication and re-cert can be had in the meantime until machine returns.. and re-establishess
  • [11:49] Scooter Back: an option would be with CRC checks
  • [11:49] Latha Serevi: I wonder if Scooter and Durante aren't off a little on the wrong track?
  • [11:49] Saijanai Kuhn: That's what we ended up assuming. Graph just suggested that it could be done wthout keys, but I think he meant you could hand the encryption off to a third party for selaing/unsealing
  • [11:49] Scooter Back: sorry
  • [11:50] FWord Utorid: crash
  • [11:50] Durante Franizzi: I'm looking at it from the security standpoint first - threat mitigation has to come before encryption or the layer(s)/methods used are useless.. but sorry, please continue.
  • [11:50] Ash Venkman: well, first off, if you're dealing with the non-distributed case, where all the objects are in the same address space, you can implement it trivially without any sort of encryption
  • [11:51] Scooter Back: basically, lan to lan
  • [11:51] Which Linden: ah ok -- the local address space
  • [11:51] Ash Venkman: well I meant, in a single process
  • [11:51] Ash Venkman: buuuuuut.... if you have a distributed capability protocol already set up (which OGP is), you can do it without an extra encryption layer on top of that,
  • [11:51] Which Linden: well -- there's still a lot of security surface area there -- i.e. you have to prevent people from creating arbitrary memory structures
  • [11:52] Scooter Back: preventing the propigation of an unauthorzed object between trusting partners
  • [11:52] Saijanai Kuhn: Ash, there's one usecase where further encryption would be neded: where the parties don't trust the Agent Domain. E.G. private corporate chat
  • [11:53] Which Linden: I'm trying to think how the existing caps model could work
  • [11:53] Which Linden: To implement this
  • [11:53] Ash Venkman: oh, well. that's just about data, not capabilities.
  • [11:53] Ash Venkman: Which, here's the basic idea
  • [11:53] Saijanai Kuhn: well, the cap is passed from the corporate HQ to the client in encrypted form so the AD can't even tell its a cap
  • [11:53] Saijanai Kuhn: no man in the middle there
  • [11:53] Ash Venkman: sure, pretty standard
  • [11:54] Ash Venkman: So fundamentally, the way that would work is that you invoke a capability (A), passing it another capability (B) as an argument
  • [11:54] Ash Venkman: and what you get back is a different capability
  • [11:54] Which Linden: mmm... yes
  • [11:55] Ash Venkman: A is an sealer, you give it the thing you want to seal
  • [11:55] Which Linden: so B is the shared secret essentially
  • [11:55] Ash Venkman: you get back a capability to a sealed box
  • [11:55] Scooter Back: capC = capA(capB)
  • [11:55] Scooter Back:  ?
  • [11:55] Ash Venkman: which you can pass around to anybody, and they can't do much useful with it
  • [11:55] Saijanai Kuhn: still assumes that the AD is trusted though
  • [11:55] Ash Venkman: unless they have a capability to the unsealer
  • [11:56] Which Linden: Sai: not sure how the AD comes into this actually, since the sealed cap could be granted by anyone
  • [11:56] Ash Venkman: in which case they can do a similar operation -- pass the sealed box cap to the unsealer, and get back the real object
  • [11:56] Saijanai Kuhn: well, was thinking back to the secure group chat established through the AD. PRobably other scenarios too
  • [11:57] Ash Venkman: the trust scenario works out pretty much exactly the same as public-key encryption
  • [11:57] Saijanai Kuhn: the client needs to have out-of-band kowledge about the unsealer
  • [11:57] Ash Venkman: just without the difficult math ;)
  • [11:57] Latha Serevi: Sai: I'd just assume that a "sealed cap" is encrypted in open-grid-land.
  • [11:57] FWord Utorid: i don't know why you would rely on caps for secure chat, and not some sort of encrypted key to mung the communication
  • [11:57] Which Linden: Well, with the difficult math being done by the transport rather than by the app code
  • [11:57] Ash Venkman: well
  • [11:58] Which Linden: FWord: secure chat would go over https neh?
  • [11:58] Saijanai Kuhn: eh, actually, I think an encrypted cap would be more secure than long-winded communication
  • [11:58] Which Linden: Actually -- Ash, isn't that vulnerable to MITM?
  • [11:58] FWord Utorid: which, it could be encrypted on the client, and decrypted by the receiving client.
  • [11:58] Ash Venkman: which: In what sense?
  • [11:59] Which Linden: let's say Eve gets ahold of the sealed cap
  • [11:59] Ash Venkman: sure
  • [11:59] Which Linden: She then grants a new cap to herself and passes that on to the unsealing party
  • [11:59] Which Linden: The unsealing party then sends B using that cap
  • [12:00] Which Linden: And now Eve knows B
  • [12:00] Ash Venkman: not sure what "grants a new cap to herself" means?
  • [12:00] Morgaine Dinova: Not all secure chat can go over SSL. When you don't trust the server and/or proxies en route, you need end-to-end chat encryption.
  • [12:00] FWord Utorid: capsturbation
  • [12:00] Ash Venkman: anyway, remember that the unsealer corresponds to a private key -- it is not an object you share freely
  • [12:00] Which Linden: In this situation, the sealer and the unsealer are treating Eve as an untrusted transport
  • [12:01] Ash Venkman: so if Eve can get access to the unsealer, you're already in trouble.
  • [12:01] Which Linden: right -- what I'm saying is
  • [12:01] Which Linden: the unsealing party uses teh unsealer by supplying it as an argument to a cap
  • [12:01] Which Linden: that it is given
  • [12:01] Ash Venkman: no, sorry, I guess i explained it backwards
  • [12:01] Which Linden: oh
  • [12:01] Which Linden:  :-)
  • [12:02] Ash Venkman: the unsealer is the one you invoke, with the sealed object
  • [12:02] Which Linden: ahhhh
  • [12:02] Ash Venkman: and it gives you back the actual thing.
  • [12:02] Ash Venkman: so, to use some pseudocode:
  • [12:02] Saijanai Kuhn: right. However, wehter unsealer is a cap or an encyrption key, it has to be given to the client out-of-band from the unsecure transport
  • [12:03] Which Linden: yeah what Sai said
  • [12:03] Which Linden: but that is unavoidable, Sai, unfortunately. PKI is the same way
  • [12:03] Ash Venkman: OK, yeah, you've got it
  • [12:03] Which Linden: oh... yousaid that
  • [12:03] Which Linden: right ok
  • [12:03] Which Linden: nice
  • [12:04] Which Linden: thanks for being patient with us :-)
  • [12:04] Ash Venkman: hey, I know what it's like
  • [12:04] Ash Venkman: it's frustrating when some flavor of tech has a whole different vocabulary for everything. :)
  • [12:04] Which Linden: yes, that made the thesis a bit hard to read
  • [12:05] Saijanai Kuhn: seems to me that the unsealer cap ismore secure since it can have a limited lifespan and can be invalidated with a single switch at corporate HQ
  • [12:05] Latha Serevi: In all trust networks, cap-based or not, we must define what relationships we want to set up. I'm hoping we can make some tentative stabs at that soon, so we can figure out what OGP primitives we might need in order to set them up. F'rinstance, in order to do the business of simulating a region, what caps relationships must I have set up beforehand?
  • [12:05] Which Linden: but then again I'm sure that the initial OO documents were just as annoying
  • [12:05] FWord Utorid: to clarify, though, this sealer / unsealer methodology is from an entirely different premise than SL caps, correct? it's part of E?
  • [12:05] Ash Venkman: fword: No, it's the same premise
  • [12:05] Saijanai Kuhn: Which, you'd have to talktoAlan Kay about that
  • [12:05] Morgaine Dinova: But the sealed cap is just a token that can be forged. That makes it no more secure than simply relying on the large UUID space in the first place.
  • [12:05] Ash Venkman: fword: you can implement them in E, sure, it's not some built-in concept
  • [12:05] Ash Venkman: morgaine: what do you mean by "forged"?
  • [12:06] Which Linden: FWord: we're talking about how to implement sealer/unsealer with SL caps
  • [12:06] FWord Utorid: ok. but existing SL caps don't use this
  • [12:06] FWord Utorid: ok
  • [12:06] Ash Venkman: fword: They could, it's just a design pattern.
  • [12:06] Which Linden: Morgaine: well, the large uuid space is pretty secure
  • [12:06] Morgaine Dinova: Either created from scratch (using magic), or duplicated to pass to someone else, etc
  • [12:06] Ash Venkman: morgaine: I don't believe in magic :)
  • [12:06] Saijanai Kuhn: Morgaine, as long as the cap is sealed using an unknown unsealer, its pretty darned secure
  • [12:07] Ash Venkman: and i'm not sure what you mean by "duplicated" either
  • [12:07] Ash Venkman: it's just an unguessable URL
  • [12:07] Saijanai Kuhn: hard tocrack a 128 bit encryption if you only have a 128 bit sample
  • [12:07] Durante Franizzi: hard to anyway, even with a cluster and rainbow tables
  • [12:08] Which Linden: Yeah, by "unguessable" we mean "really, you're not going to guess it"
  • [12:08] Which Linden: "SRSLY"
  • [12:08] Ash Venkman: durante: well no, a rainbow table works when you have some plaintext you can guess at
  • [12:08] Ash Venkman: durante: that's different from trying to guess a completely random number
  • [12:08] Durante Franizzi: it wont be sent mixed data?
  • [12:08] Which Linden: We have considered putting some constants in the low-uuid values that just say "Iterating over UUID values is not going to work. Give up"
  • [12:08] Ash Venkman: which: haha, that'd be amusing. :)
  • [12:09] Which Linden:  :-)
  • [12:09] Durante Franizzi: New plan, before I comment further.. I'm going to finish reading the thesis *blushes*
  • [12:09] Saijanai Kuhn: there's a jillion possible mapings of MD5 that would hield ["http://"] as the first part of the cap
  • [12:09] Ash Venkman: saijani: no, because the cap URL isn't a hash of anything meaningful at all
  • [12:09] Morgaine Dinova: Well if you trust the sparseness of the caps address space, then you don't need sealing nor encryption anyway, because guessing an encryption key is mathematically equivalent to guessing a UUID.
  • [12:09] Which Linden: Ash, I think he's talking about if the cap url itself was encrypted
  • [12:09] Ash Venkman: morgaine: yes, but no.
  • [12:09] Saijanai Kuhn: Mogaine this is for sending via a non-trusted transport.
  • [12:10] Ash Venkman: right
  • [12:10] Saijanai Kuhn: IBM doesn't trust LInden's Agent Domain with the connection point for its high level corporate chat
  • [12:10] Which Linden: But I agree that it's not necessary to encrypt the cap url, using the unsealer cap paradigm
  • [12:10] Ash Venkman: OK, cool :)
  • [12:10] Ash Venkman: obviously you'd want to encrypt the chat contents for privacy reasons anyway
  • [12:10] Ash Venkman: but there's a difference between leaking data and leaking authority
  • [12:11] Saijanai Kuhn: sure but encrypting the connection point would add a great deal of security.
  • [12:11] Which Linden: Though with HTTP-based caps they are kinda the same thing
  • [12:11] Which Linden: Since the cap url would be sent in plaintext too
  • [12:11] Which Linden: But -- no matter!
  • [12:11] Ash Venkman: which: well that's the point of the sealer pattern
  • [12:12] Stirling Allen: the solution to the insecure nature of URLs is to pad with random characters before encrypting.
  • [12:12] Ash Venkman: mm.
  • [12:12] Saijanai Kuhn: a cap in the SL space is padded with random characters
  • [12:12] Ash Venkman: it's all random characters, really.
  • [12:13] Which Linden: Hey, I gotta go
  • [12:13] Latha Serevi: This has been some good discussion of the mechanics of caps; but we also need to talk, sometime, about what to build "on top of" caps in order to implement the needed trust relationships. Should we leave that for a different day?
  • [12:13] Which Linden: You all are welcome to party on here
  • [12:13] Ash Venkman: ttyl :)
  • [12:13] Morgaine Dinova: Any non-broken encryption algorithm already does that internally, you don't need to pad the incoming data.
  • [12:13] Graph Weymann: yo
  • [12:13] Which Linden: Thanks for a very interesting discussion!
  • [12:13] Durante Franizzi: thank ya Which
  • [12:13] Which Linden: Hey graph
  • [12:13] Saijanai Kuhn: hey graph, which is just leaving... :-/
  • [12:13] Morgaine Dinova: Hi Graph
  • [12:13] Which Linden: Should I try and ping you next time?
  • [12:13] Graph Weymann: I heard clarrification was needed on sealers
  • [12:14] Graph Weymann: Nah, I wasn't around.
  • [12:14] Which Linden: Ash explained it pretty well
  • [12:14] Morgaine Dinova: Yup, our windows are leaking
  • [12:14] Which Linden: I'll put up the transcript
  • [12:14] Saijanai Kuhn: I pinged him in irc about an hour ago ;-)
  • [12:14] Graph Weymann: OK
  • [12:14] Graph Weymann: Ash, did you cover crypto-sealers-and-object-sealers?
  • Which Linden