pbsd

33 ms·

271.
by pbsd 11y ago
I don't know about NIST standardization, but you can see what the Keccak team is planning with the Keyak and Ketje CAESAR candidates: http://keyak.noekeon.org/ http://ketje.noekeon.org/
272.
by pbsd 11y ago
Biases caused by modulo reduction are dangerous when the source integer is relatively close to the target distribution. This bias is unlikely to be useful for attackers. The probability difference between the most likely output, 0, and the
273.
by pbsd 11y ago
> This is, cryptographically speaking, a stretch. Not only that, this transforms any symmetric-key encryption scheme into a public-key encryption scheme---share the obfuscated "white-box" code as the public-key for encryption,
274.
by pbsd 11y ago
I'm not sure if you are being sarcastic, but to be honest I don't really remember. I guess I picked it up over time from here and there. Then moved on to more formal documentation, that is, the standards.
275.
by pbsd 11y ago
I'm not particularly convinced. The make_unique example given could be implemented in a similar manner with existing C++ features, and it would not require yet another complexity-inducing feature into C++: #include <memory>
276.
by pbsd 11y ago
They already have. The upcoming AVX-512 extensions [1] introduce the VPMADD52LUQ and VPMADD52HUQ instructions, which add the high or low 52 bits of a 52x52-bit multiplication to a 64-bit integer. Presumably this is done via the preexisting
277.
by pbsd 11y ago
> The drawback however, is that these implementation only get that fast because ChaCha is embarrassingly parallel. That is my point exactly. Why would you design, in this day and age, a generator that doesn't vectorize well? It will
278.
by pbsd 11y ago
'A bit faster' is an understatement. On the benchmarking machine used by the PCG author, you would get a ~2.5x speedup over that implementation, which would put Chacha20 roughly at (amortized) 5 cycles per 32-bit word. If you go C
279.
by pbsd 11y ago
I suppose it would. However, RCR is a notoriously slow microcoded instruction in modern x86. You'd be better off with something like add rax, rbx ; lo + hi setc cl shrd rax, rcx, 1 Or, better, the generic way to do it
280.
by pbsd 11y ago
With C++14 you don't need to define the format string outside functions, but it does get a little hairy. Here's a half-assed example: http://coliru.stacked-crooked.com/a/3f34563e9a85af51
281.
by pbsd 11y ago
That is also the case in usual implementations of stdint.h, where int8_t is defined to be `signed char`. In C and C++, `char`, `signed char`, and `unsigned char` are different types, and `char` is not guaranteed to be signed or unsigned---t
282.
by pbsd 11y ago
Visual Studio has had stdint.h since its 2010 edition. Before that there were readily-available substitutes (like https://code.google.com/p/msinttypes/ ), or you could do it yourself by typedef'ing [unsigned]
283.
by pbsd 11y ago
I'm pretty sure I remember Delphi using the carry flag to return boolean values.
284.
by pbsd 11y ago
Kalyna was the result of a public competition started in 2006 [1], so it mirrors design preferences of that time. There were 4 other candidates, some were broken, and none of them seem any more cache-timing resistant than Kalyna. [1] https
285.
by pbsd 11y ago
No, it will complain that A::foo is pure virtual, and that B must implement `foo`. However, if you define in B the method `void foo() { A::foo(); }`, it will work. In destructors this happens implicitly. There was an old Herb Sutter GotW
286.
by pbsd 11y ago
You cannot just declare the destructor of a base class, since it will get called by the derived class destructors and linking will then fail. But you can write out an implementation for a pure virtual function, which will still keep the b
287.
by pbsd 11y ago
Don't forget the variants with a stack-adjusting immediate, 0xC2 and 0xCA. Those can also come in handy.
288.
by pbsd 11y ago
You can find an official Intel source for Haswell in here (page 15): http://pages.cs.wisc.edu/~rajwar/papers/ieee_micro_haswell.p...
289.
by pbsd 11y ago
Broken a few weeks later: https://eprint.iacr.org/2015/519
290.
by pbsd 11y ago
MD5's compression function was already broken 20 years ago: http://cseweb.ucsd.edu/~bsy/dobbertin.ps
291.
by pbsd 11y ago
Vista did increase hardware requirements across the board. But the change we are discussing here was made in Windows 8 and later, which is exactly when Microsoft started caring about getting Windows into tablets and, in particular, ARM chip
292.
by pbsd 11y ago
> And IIRC, the diffuser is quite fast Kinda. When Elephant was designed AES-NI did not exist, and so AES was expected to work at somewhere between 10-20 cycles per byte. Elephant worked somewhere between 5-10 cpb, so it was not a lot of
293.
by pbsd 11y ago
2048-bit keys/primes are around 1 billion times harder than 1024.
294.
by pbsd 11y ago
Group 14 is fine. You might as well also tell people to use custom block ciphers, since a precomputation of roughly the same magnitude---compute a common plaintext under many possible keys---would break AES-128 pretty quickly as well. I wou
295.
by pbsd 11y ago
This is not at all surprising; even I had pointed out the looming DH problem in an earlier thread: https://news.ycombinator.com/item?id=8810316 One small nit with the paper: it is claimed that there had been technical diffi
296.
by pbsd 11y ago
Such worries have mostly faded by now, though you will see some conservative people still preferring RSA. Keep in mind that the computational study of integer factorization only started seriously in the 70s with CFRAC, making the "m
297.
by pbsd 11y ago
While the equivalence between RSA and integer factorization is still an open question, the Rabin (exponent 2) trapdoor permutation is tightly equivalent to factoring. Furthermore, for most groups the DHP is polynomially equivalent to the DL
298.
by pbsd 11y ago
Information-theoretically secure encryption and authentication do exist, so in a sense unbreakable (authenticated) encryption is a fact. Outside of that, the existence of OWFs is indeed an assumption, but I doubt anyone's losing sleep
299.
by pbsd 11y ago
This technique is quite old, actually, and has historically been used to compress RSA keys. It is perfectly safe, provided you don't have access to the original modulus (the intuition here is that if p is chosen uniformly at random, th
300.
by pbsd 12y ago
mixAndPermute is actually 'RSA' encryption; the modulus factors as 43 * 47 and the public exponent is 5. Inverting it is a matter of computing x^773 mod 2021.

More ›