I'm willing (since I have that whole merge in my head still) - to try to merge up hmac-challenge if that will help move things along. ?
Well, my take on it was that the hmac codebase was very difficult to move forward in its current state and needed a rebase on head for it to move forward. I'm pretty good at hairy merges, and it only cost me half of fifth of (admittedly good) vodka, which I will try to extract from you the next time we meet. I'm very keen on having authentication available as an option. My principal worry is that it's going to be massively cpu intensive, and here I am regularly blowing things up and measuring things a lot... I was pleased to see that armv8 and current intel processors have some major sha1 instructions that speed up many benchmarks by 5x or more, but mips... mips... sigh. and ripe160, not so much. I have not inspected the protocol much, what are the odds that all the auth could be offloaded into the kernel (ebpf) On Mon, Nov 12, 2018 at 7:52 AM Juliusz Chroboczek <[email protected]> wrote: > > > In looking over the bird patch, it looks like I merged the wrong > > thing. > > Yes, it looks like it. hmac-challenge is the right code. > > Weronika, perhaps you could rename the branch hmac to something less > exciting? > > Dave, please be aware that the HMAC code is not quite finished yet. Once > we got a working prototype, we focused on getting the protocol > specification in time for IETF-102 and before the girls' internship ended. Yep. My impression was that they had to move on and that they are no longer on the project. (a side note, in current modern american "politically correct" english you can't use the word "girls" anymore. Ladies or Women. There's a whole new generation of easily offended millenials that care. I left the country in 2006 and came back to be lectured on this subject multiple times. Even in spanish "chicas" is becoming verboten. I have to reach for george carlin's wonderful riffs on the use of soft language just to cope) > In particular, we need to do some restructuring to current master (passing > an interface pointer to a number of functions that lost access to the > interface structure in the unicast refactoring) before we can merge HMAC. I *think*, in the fixups in the merge, I had that covered. > > The following features are supported by the protocol but not by the > implementation : > > - graceful key rotation (ability to add/remove keys at runtime); From what I understand you need to be able to insert a key via the tcp interface or config file and retire a key over time (either with a hard deadline or after everybody shifts over for long enough) I was pleased that the recent dns key rollover worked so well. Still, given how often things go down, I can see it taking *months* before it would be safe to rotate a key. > - graceful deployment (ability to send signed packets but accept > unsigned ones). yea, just hit that. :) I assume this would be a conf option, like "graceful"? I still had a dream of being able to gradually shift a network over to authed, or have authed and unauthed bits. > > I do have one objection to the codebase, in that it pulls in > > libgcrypt, ssl, and pthreads... about 5MB? of libs... for two hash > > functions. > > Yeah, we should just include an implementation of SHA-256 in the code. no RIPE? > > -- Juliusz > > -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 _______________________________________________ Babel-users mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
