- Minimum time for bruteforce - 5 Updates
- New Lightweight C++ Logging Framework - 3 Updates
- Why macro ? - 1 Update
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 04 03:24PM -0800 On 11/4/2020 1:54 PM, Frederick Gotham wrote: > This technique relies on checking the time twice: Once before the cryptographic function and once afterwards. > A function such as "GetTickCount" on Microsoft, or "get_uptime" on Linux would be preferable over using 'ctime' just in case the system time somehow changes. > Anyone got any ideas on how best to code this? Imagine if Eve was collecting encrypted data sent across the wire for several months... Well, she can spend as much time as she wants to brute force. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 04 04:48PM -0800 On 11/4/2020 1:54 PM, Frederick Gotham wrote: > My current task is to ensure that an embedded Linux device fulfills all the criteria for a particular security standard. [...] > Anyone got any ideas on how best to code this? Wait, this is multiposted to several groups. Step one, stop doing that? |
| Bo Persson <bo@bo-persson.se>: Nov 05 09:01AM +0100 On 2020-11-04 at 22:54, Frederick Gotham wrote: > Sleep_For_Milliseconds(173u); > Decrypt(p,key); > } First, it is very unlikely that an attacker will have to try *every* possible combination before finding the correct one. On average you will fill need to try half the keys. One way do delay an attack is to add a variable delay, and make it longer and longer for each incorrect entry. |
| Juha Nieminen <nospam@thanks.invalid>: Nov 05 01:58PM > My current task is to ensure that an embedded Linux device fulfills all the criteria for a particular security standard. Cryptography and security are extraordinarily complex subjects. In general one should avoid making ad-hoc solutions to security and cryptographic problems, and instead rely on the best knowledge that current computing science has on those subjects. Anyway, unless the system actually needs to accept hundreds of login attempts per second, one of the normal ways to do this is that incorrect keys will introduce an ever-increasing delay to the next attempt (up to some reasonable maximum delay, eg. a few seconds). The delay can reset after some time has passed without further attempts. > A function such as "GetTickCount" on Microsoft, or "get_uptime" on Linux would be preferable over using 'ctime' just in case the system time somehow changes. You could use std::chrono::steady_clock, or look at how it's implemented. Also, I think std::clock() also measures CPU time, not system time, so it could also be used. gcc has the extension __rdtsc() in its x86intrin.h header. However, this returns CPU clock cycles (since startup), so to convert them to time (or, rather, to know how many clock cycles is the timespan you are after) you would need to know the clockrate of the CPU. (There might be some function to get that.) |
| David Brown <david.brown@hesbynett.no>: Nov 05 09:46PM +0100 On 04/11/2020 22:54, Frederick Gotham wrote: > one key. And so I must write code that takes at least 173 > milliseconds to use a key to decode data. An easy way of doing it > would be: 20 bits is not a "cryptographic key" - it's a PIN code. It's suitable for people pressing the numbers by hand, where it takes five seconds to try a code and they get blisters and give up after 20 or 30 shots. When the USA had their idiotic and counter-productive policy of treating "strong" encryption software as "military grade subject to export 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. Once you have picked a rational size for the cryptographic key, and used an existing encryption algorithm and implementation (you are not qualified to make the algorithm or code yourself), your minimum delay problems disappear. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 04 04:38PM -0800 On 10/31/2020 4:10 PM, 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, and a single logging thread that would episodically grab all from each thread. So, a single atomic xchg was used from the logging thread to gather and report. It was a simple distributed multiple producer single consumer setup. log: A thread enters a log in its local memory. log thread: grabs from every threads logs. reports to file. repeats. It scales fairly well. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 05 06:27PM On 04/11/2020 22:59, Öö Tiib wrote: > bar o2; > o2.f2(o1); > } However f2 has to be void f2(foo& o) which doesn't work. /Flibble -- ¬ |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 05 07:15PM On 05/11/2020 00:38, Chris M. Thomasson wrote: > reports to file. > repeats. > It scales fairly well. Good idea, just implemented it. Available on github now. /Flibble -- ¬ |
| Richard Damon <Richard@Damon-Family.org>: Nov 04 08:33PM -0500 On 11/4/20 11:11 AM, Sjouke Burry wrote: > Which safety guy has decided that it is "a good idea" to > leave things running for weeks or months? > I would accuse myself of stupidity if I used my computers that way. Apparently this part of the system is fairly regularly left running between flights and even over night, in part because a reboot of this system takes a while to perform. Sort of like how a lot of people whill just put their computer to sleep overnight, as opposed to shutting down and rebooting in the morning. It sounds like while it is common to shut it down for most maintenance, it doesn't always happens that way, and while it is very unlikely for the plane to have hit the 120 day mark without a reboot, it was worth adding that as an item in the maintenance check list. |
| 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. |
No comments:
Post a Comment