Re: [Babel-users] [babel] HMAC Key rotation key format (was ripemd)
For interconnected domains and whatever, I would rather just use DTLS with relatively shortlived and auto-renewed certs (real-time revocation is hard to do if you are authenticating routing - chicken 'n' egg problem; one alternative is of course some sort of manual blacklisting if you want to go with long-lived certs). If HNCP is in picture, DNCP trust based consensus model is also an option - with it, (self-signed) certificates can have long lifetime as their usefulness is determined by consensus of nodes -> as long as there's only few compromised nodes, you can blacklist them in real time if you control the rest of the nodes. Cheers, -Markus ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [babel] Blake2S, blake2B or neither? [was: rather than ripemd160...]
> On 30 Nov 2018, at 13.23, Juliusz Chroboczek wrote: >>> With these numbers, I withdraw my support of including anything else >>> than SHA256 as MTI. I think specifying Blake2B or 2S as well makes >>> sense (mostly for crypto robustness reasons for having alternative >>> that is specified) but making it MAY-SHOULD seems sensible to me. >> I can probably live with that :) > > Excellent, it looks like we're converging. Thanks to both of you for the > informative and kind discussion. > > At this stage, I see four possibilities: > > (1) leave the document as it is; > (2) add a mention that implementation of Blake2S is RECOMMENDED (SHOULD); > (3) add a mention that implementation of Blake2B is RECOMMENDED; > (4) add a mention that implementation of both 2B and 2S is RECOMMENDED. > > I am in favour of (1), since I am convinced that SHA256 is fast enough for > all reasonable devices. (2) makes sense to me, and I won't oppose it. > I'll need some convincing in order to do (3) or (4), since Blake2B does > not appear bring any significant speed advantage over SHA256. > > In either case, I'm planning to implement SHA256, Blake2B and Blake2S in > the reference implementation. I do not actually recommend 2B based on the numbers. By looking at them, you notice that the setup time for 2B is higher and even on 64bit platform the gain is not insane even on large operations (25%ish, perhaps). -2BP is what I have and will recommend for large bulk hashing (-P variant allows for paralllelization of hashing to multiple cores), but for smaller stuff it seems Blake2S is faster on both 32 and 64bit. As they are all based on same cryptographic base, it is likely that if weakness is found in one, it is present in others. That said, as BLAKE algorithm was at the time of SHA-3 contest analyzed to be strictly superior to SHA-2 in some features, it seems unlikely. But you never know. The above discussion cuts out options 3 and 4 for me. I am mostly indifferent between 1 and 2; SHA256 (especially with hardware acceleration) is probably faster than Blake (even with just Intel optimized assembler it is 60-70% of Blake 2B), and if we’re talking millions of pps (acceleration present) it is entirely academic anyway for a routing protocol. The tinfoil hat argument for 2 is that it provides fallback if SHA256 breaks down somehow in the future. So I have SLIGHT preference for 2 but am happy enough with 1 as well. Cheers, -Markus ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [babel] rather than ripemd160...
Here's some raw numbers (clickbait): - my Macbook (sanity check) - Turris Omnia (2016 highend) - Buffalo WZR-600DHP (2012 midend) https://github.com/fingon/go-hashperf TL;DR (probably the interesting part): 2012 midend home router does 40 bytes: - 37.5k pps of SHA256 - bit over 40k pps of Blake2B - 91k pps of Blake2S Setup overhead disappears both in SHA256 and Blake2 at ~500 byte mark (500 and 1200 bytes roughly equal MB/s); with 200 byte packets setup still wastes ~1/4 of performance (both SHA256 and Blake2) and even more with 40 byte packets. With these numbers, I withdraw my support of including anything else than SHA256 as MTI. I think specifying Blake2B or 2S as well makes sense (mostly for crypto robustness reasons for having alternative that is specified) but making it MAY-SHOULD seems sensible to me. The code is there, go ahead to test on your own routers if you care. I didn't bother testing arm64 in the end, as those are even faster than arm (the ridiculous blake2s number of 460k pps for Blake2s on Turris Omnia convinced me that it is not really worth it to test on faster hardware). -Markus ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [babel] HMAC and MTI [was: rather than ripemd160...]
On 26 Nov 2018, at 15.46, Juliusz Chroboczek wrote: >> I'm not sure if we *can* make [blake2s] MTI in the spec as well (does it >> need to be defined by a standards track RFC for us to do that?), but if >> we can, I think we should seriously consider it... > Opinions? I like Blake (family of) hash functions so on that front +1; however, no idea how bureaucracy works. Dave had a good point as well though, comparing -2s and -2b performance on some set of hardware (e.g. arm, mips, intel) might be in order before picking between the two. I am not convinced -2s is the way _forward_. Even now most of hardware in my home is already 64bit .. -Markus ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
