Digest for comp.lang.c++@googlegroups.com - 5 updates in 2 topics

comp.lang.c++@googlegroups.com

Google Groups

Topic digest
View all topics

• New Lightweight C++ Logging Framework - 3 Updates
• Minimum time for bruteforce - 2 Updates

New Lightweight C++ Logging Framework

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 05 04:03PM -0800 On 11/5/2020 11:15 AM, Mr Flibble wrote: >>> New lightweight C++ logging framework:   >> nice. Fwiw, iirc, I used a little logging framework where each thread >> had local memory it stored log info,   Forgot to say that I created it. Iirc, I wrote about it on Usenet somewhere many years ago.     and a single logging thread that   >> repeats.   >> It scales fairly well.   > Good idea, just implemented it.  Available on github now.   Nice! The scheme worked well. The consumer thread, or the logger if you will, was able to take a threads entire log list using a single atomic operation. Atomic Exchange. So, if you had say, 10 worker threads, the single log thread would use exactly 10 atomic exchange op's per "log collection" cycle.

"Öö Tiib" <ootiib@hot.ee>: Nov 06 03:46AM -0800 On Thursday, 5 November 2020 20:27:57 UTC+2, Mr Flibble wrote: > > o2.f2(o1); > > }   > However f2 has to be void f2(foo& o) which doesn't work.   Certainly it is so but that is where my confusion started. I do not understand why logger has to access i_logger objects that are not logger's base subobjects? Feels a bit like case of diffused responsibilities.

Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 06 03:50PM On 06/11/2020 11:46, Öö Tiib wrote: > not understand why logger has to access i_logger objects that > are not logger's base subobjects? Feels a bit like case of > diffused responsibilities.   I suggest you read up on the SOLID principles and idea that it makes good engineering sense to depend on abstractions and not concretions.   /Flibble   -- ¬

Back to top

Minimum time for bruteforce

Juha Nieminen <nospam@thanks.invalid>: Nov 06 08:43AM > control", they counted 40 bits as the minimum for "strong" encryption. > And that was decades ago. No one who understands anything about > cryptography would bother with less than 128 bits these days.   He didn't actually say they are using 20-bit keys. It sounded more like just a practical example.   The problem is that the application may be eg. about user-defined passwords, which are usually relatively short.

David Brown <david.brown@hesbynett.no>: Nov 06 02:38PM +0100 On 06/11/2020 09:43, Juha Nieminen wrote: >> cryptography would bother with less than 128 bits these days.   > He didn't actually say they are using 20-bit keys. It sounded more like > just a practical example.   True. But if he had been using 40 bits, he'd have seen he needed a delay of 173 nanoseconds (ignoring his misunderstanding about how many attempts are actually needed), and then he would presumably have realised that you don't need to add a software delay of 173 nanoseconds.   > The problem is that the application may be eg. about user-defined > passwords, which are usually relatively short.   If you have lower-case and upper-case letters, digits and a couple of punctuation marks, that's 64 values - 6 bits of "key" per user password character. (In practice, 5 bits is more realistic as many characters are rarely picked.) Even with short passwords it's not hard to beat 20 bits of variation.   However, when you use user-defined passwords, you don't use the password directly for the cryptographic key - you add salt and pass it through a hash. Run it through SHA256 and you have a 256 bit key. The source does not have 256 bits of entropy, of course - even if the password rules insist on 10 characters, an upper case, a lower case, a digit, and a punctuation character, you might have, say, 30 bits of entropy. But you can't work backwards from the SHA values - you have to work forwards. That means you have to enumerate all the possible passwords and generate the hashes and try them. Tables exist of commonly used passwords, with algorithms to generate variations (like "Secret1!", "Secret2!", etc.). But the job is much harder than simply trying all values from 0 to 2 ^ 30.

Back to top

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.