[00:11:47] --- dev-zero@jabber.org has become available [00:31:13] --- dev-zero@jabber.org has left [01:01:20] --- Simon Wilkinson has become available [01:56:38] --- Simon Wilkinson has left [03:01:17] --- Simon Wilkinson has become available [03:33:36] --- Simon Wilkinson has left [03:35:01] --- Simon Wilkinson has become available [03:58:16] --- dev-zero@jabber.org has become available [04:00:20] --- Simon Wilkinson has left [05:21:09] --- dev-zero@jabber.org has left [05:25:52] --- dev-zero@jabber.org has become available [06:26:47] --- ballbery has become available [07:09:54] --- Simon Wilkinson has become available [07:20:55] --- Simon Wilkinson has left [07:21:38] --- Simon Wilkinson has become available [07:25:59] --- dev-zero@jabber.org has left [07:27:31] --- dev-zero@jabber.org has become available [07:35:17] Haha. I want to assert that the size of a particular structure does not change. [07:35:36] The FreeBSD kernel has a macro to do this, but I haven't looked at its innards. [07:35:40] Dare I ask why? [07:35:57] #if sizeof foo != 6 // #error oops // #endif [07:36:04] sizeof is compile time [07:36:17] opr_Assert(sizeof(foo) == 6) will do it at run time. [07:37:11] I seem to recall that there's a reason you can't do this at compile time. Like #if sizeof(long) == 8 // #define 64BITFTW // #endif doesn't work [07:40:31] --- Simon Wilkinson has left [07:41:28] --- Simon Wilkinson has become available [07:41:41] hm, I thought cpp did sizeof. apparently not [07:42:32] well, come to think of it, it couldnt really do it for struct types, so never mind me [07:49:55] --- Simon Wilkinson has left [07:50:38] --- Simon Wilkinson has become available [08:16:17] --- Simon Wilkinson has left [08:17:48] --- Simon Wilkinson has become available [08:18:16] --- Simon Wilkinson has left [08:23:28] --- deason has become available [08:27:21] iirc, some projects do compile-time asserts by declaring an array whose size is -1 if the assert comes out wrong, if it can't be done with #error [08:28:16] or maybe I mean '0' [08:32:28] Oops, got lost elsewhere in IM. This is to assert that the size of a wire header that is defined as a packed C structure is actually the expected size of that header on the wire. [08:32:39] (I.e., probably overkill.) [08:39:45] --- Simon Wilkinson has become available [08:41:40] --- dev-zero@jabber.org has left [08:43:14] eh, I think that can be useful [08:43:34] http://www.pixelbeat.org/programming/gcc/static_assert.html seems like a good explanation of a few different ways to do it [08:44:06] an array typedef seems good enough to me, if you accept a 'name' in the assert [08:45:40] I wonder how portable it is. In particular does it work with the Irix compiler :) [08:46:26] Well, I'll be getting my Irix machine back from my friend who I loaned it to probably this week, so I could potentially test firsthand. [08:49:14] Simon, I forget if you saw my weird kernel-mode page fault in _hc_rijndaelEncrypt() while trying to hack hcrypto's fortuna prng into the kernel. [08:49:50] I had some fun going from C structures to wire headers. It's not just the size changing that you need to worry about. Different compilers may pack in different ways. I think that there are pathological cases where packing differences can alter the layout, but not the structure size. [08:49:56] I didn't see that page fault. [08:50:30] I also forget if we have any __attribute__((packed)) in the tree yet. I want to say there was like one place. [08:51:04] I don't believe that we do. [08:51:24] That's very gcc specific. [08:52:45] If we keep talking about packing, I'll end up descending into my MIT Keberos on Mac OS rant. [08:53:34] do proper marshaling, structs are not even remotely guaranteed to do something sensible over the wire to another machine [08:53:46] or even a program on the same machine built with a different compiler [08:54:25] hm, account [08:54:27] Anyway, the crash for my page fault was around round 9 of rijndael_Encrypt, so it didn't seem like it would be some variant of a null dereference. My most likely hypothesis is that I was linking the object into the kernel improperly or compiling with the wrong flags. Maybe I should go look at how crypto-aes.o was first added. [08:54:55] Which kernel? [08:55:07] FreeBSD kernel. [08:55:25] The actual targets would be the irix kernel, but it's easier for me to test there. [08:55:49] I'm not sure how much of the crypto stuff has been tested on FreeBSD. So I wouldn't entirely trust that crypto-aes has been tested there, either. It's not one of our best tested platforms ... [08:56:28] Hmm, fair enough. Do you recall where crypto-aes has been tested? [08:56:53] Linux, Solaris definitely. [08:57:09] Mac OS X as well [08:57:26] Maybe I'll try pulling this code up on a linux box, then. (I just hacked RAND_bytes to always use fortuna in the kernel, for testing purposes.) [09:12:24] --- Simon Wilkinson has left [09:12:54] --- Simon Wilkinson has become available [09:16:01] I also want to talk about rxgk, KeyFileExt, and krb5 keytabs, but that should probably be on -devel. [09:16:23] I can quickly summarise what I ended up doing... [09:16:31] Okay. [09:16:39] The key type and subtype gives a fair amount of rope. [09:16:54] But for the actual GSS acceptor I don't see a way around a krb5 keytab. [09:17:08] The critical thing is to remember that all the world is not Kerberos. [09:17:22] That could be hard, given my day job :) [09:17:43] So, we use whatever the mechanism specific acceptor key storage mechanism is. For Kerberos, that's the krb5.keytab [09:17:53] The rxgk shared key is separate from that. [09:18:16] That goes into KeyFileExt, with a key type of rxgk, and a sub type corresponding to its encryption type [09:22:32] Let me check my understanding: on a vlserver (machine), the same actual key for the cell-wide key will be in both a krb5.keytab and the KeyFileExt? [09:23:41] No [09:23:49] The rxgk key is different from the krb5 key [09:24:30] Ohhh. That's a thought. Did the stuff for key agility make it in to the rxgk draft? [09:24:32] The krb5 key is used only for authentication and tokens are encrypted in the rxgk key? [09:24:36] Yes. [09:24:41] Ah. [09:25:53] Think about using something like GSI for the GSSAPI mechanism [09:26:09] I'm not sure I know what you mean by "key agility", here. [09:26:53] The key version number and encryption type of the key used to encrypt the token need to be transmitted with it. [09:27:13] Pretty sure those are present. [09:28:14] What rxgk-afs specifies to send to the client as a "token" is an RXGK_TokenContainer, which has the kvno and enctype as well as the actual opaque blob. [09:30:46] Since the core rxgk document leaves the token format as application-specific, those bits don't need to be specified there. [09:32:14] Cool, that did get fixed, then. [09:32:33] I've slightly lost track, and have still to audit our implementation against the draft [09:32:53] Sounds "fun". [09:33:02] Oh yes. [09:34:06] WRT KeyFileEx, I just added support for creating random rxgk keys to asetkey. Random keys are the only ones that you actually need to support. [09:34:09] I fleshed out the packet handling bits over the last week or so. I'm trying to figure out where to document the behavior of the security header and maxtrailer size. [09:34:40] Max trailer is an implementation detail, isn't it? [09:34:55] And then bos setkey to get the key to other servers? [09:35:13] Or just copy the KeyFileEx areound [09:35:40] > trailer is an implementation detail Well, sort of. One has to deal with the ciphertext expansion somehow... [09:36:02] Yeah, but that really is implementation specific. [09:36:37] --- stephan.wiesand has become available [09:36:44] Oh, by "document" I mean "for OpenAFS developer documentation so the next guy doesn't have to source-dive", not "put in a protocol document". [09:36:51] Oh, sure. [09:37:49] But you can get the necessary constants out of the crypto library [09:38:40] I actually haven't looked at what hcrypto provides very carefully -- MIT krb5 was handier as I was developing, and I needed MIT's gssapi_krb5 anyway. [09:39:05] But I don't think there's a primitive to get the maximum ciphertext expansion directly. [09:39:22] There should be, I think. Isn't it part of the 3961 profile? [09:42:30] I don't see it explicitly mentioned. (Maybe I'm looking in the wrong place.) [09:55:09] --- stephan.wiesand has left [09:58:47] --- ballbery has left [09:59:44] --- ballbery has become available [11:05:01] --- Simon Wilkinson has left [11:05:30] --- Simon Wilkinson has become available [11:47:18] --- Simon Wilkinson has left [11:47:36] --- Simon Wilkinson has become available [13:10:30] --- ballbery has left [13:12:34] --- Simon Wilkinson has left [13:22:10] --- Simon Wilkinson has become available [13:28:10] --- Simon Wilkinson has left [13:42:42] --- Simon Wilkinson has become available [14:07:35] --- dev-zero@jabber.org has become available [14:11:56] --- Simon Wilkinson has left [14:36:24] --- dev-zero@jabber.org has left [15:33:04] --- jaltman/FrogsLeap has left: Disconnected [15:41:01] --- jaltman/FrogsLeap has become available [16:05:42] --- dev-zero@jabber.org has become available [16:44:29] --- deason has left [17:35:11] --- dev-zero@jabber.org has left [17:37:37] --- dev-zero@jabber.org has become available [17:47:15] --- dev-zero@jabber.org has left [22:59:22] --- kula has left [22:59:22] --- kula has become available