pbsd

44 ms·

391.
by pbsd 12y ago
You're right, arriving at that kind of conclusion from the existence of a tutorial is bad reasoning. I had wrong expectations, I suppose. I must thank you for pointing that link out to me, though: it said what I was trying to say much
392.
by pbsd 12y ago
My comment appears to have been more polarizing than I ever expected. Let me clear some things up. In your unique_ptr example, you're right: the reference doesn't outlast its owner, but it becomes a dangerous zombie after getting
393.
by pbsd 12y ago
Iterator invalidation, dangling references, and use-after-move are all essentially the same thing---references outlasting their owner---no need to multiply the issues. Buffer overflows are an issue, yes, unavoidable due to the C legacy. On
394.
by pbsd 12y ago
See slide 42 of STL's recent talk for what I guess will be a similar example: https://github.com/CppCon/CppCon2014/tree/master/Presentatio...
395.
by pbsd 12y ago
People tend to expect more stability from a systems language than a web one. Can I trust that my Rust 1.0 code will work, unchanged, 20 years from now? If not, the language is likely to remain in the enthusiast realm.
396.
by pbsd 12y ago
No: Z3 proves the Hacker's Delight* trick almost instantly. The implementation above is not actually faster in practice, so it's rarely used; but its equivalence to popcount relies on Z/2^64Z properties that solvers do not se
397.
by pbsd 12y ago
> The computation power needed to break SHA-1 is higher then attacking RSA[-1024]. You better back that assertion with something. Even in the worst possible case (for SHA-1), it seems to me that SHA-1 is cheaper to collide than it is to
398.
by pbsd 12y ago
To out-pedant you: even assuming that the differential collision attacks we know about are incorrect [1], we absolutely know how to break SHA-1 given enough compute, that is, roughly the same resources needed to break RSA-1024. The answer i
399.
by pbsd 12y ago
SMT solvers have been getting better and better, but they still fail at relatively simple things. I often use them to prove certain low-level optimizations are correct, and sometimes simple things completely choke the solver. The following
400.
by pbsd 12y ago
You can't overload the `.` operator. However, something like this would work: `x | (f , g)`.
401.
by pbsd 12y ago
It's pretty straightforward to just iterate the key schedule backwards using the inverse S-box and a few xors; no need for any fancy stuff.
402.
by pbsd 12y ago
> For encryption operations these aren't catastrophic things to leak — the final block of output is ciphertext, and the final AES round key, while theoretically dangerous, is not enough on its own to permit an attack on AES This is
403.
by pbsd 12y ago
Maybe in some high-throughput application, or something under hard performance constraints. IIRC VMWare uses Salsa20/12 for its remote desktop encryption thing. 20 rounds gives a more comfortable security margin, though, so it's a
404.
by pbsd 12y ago
Correct, it's algorithm-agnostic. FWIW, Salsa20/12 is the officially-sanctioned eSTREAM winner; it's a perfectly fine cipher choice.
405.
by pbsd 12y ago
That last sentence is paraphrasing a recent djb cfrg post: http://www.ietf.org/mail-archive/web/cfrg/current/msg04880.h...
406.
by pbsd 12y ago
Nitpick: std::optional<T> does not exist in C++11, nor in the recently-approved C++14. It is, nevertheless, in the process of getting into the standard, and is already present in GCC 4.9's libstdc++ as std::experimental::optional
407.
by pbsd 12y ago
Oops, you're right of course; I got reference collapsing rules confused with the regular binding rules. Proxy objects will only bind to auto const& or auto&&, though, since they're generally returned by value. I was su
408.
by pbsd 12y ago
> or the most succinct (replace && by & if writing): That is strictly not necessary. `auto&&` is what is now being called a universal reference: `item` resolves to `const int&` if `myVec` is const, and to `int&amp
409.
by pbsd 12y ago
Previous discussion: https://news.ycombinator.com/item?id=8129309
410.
by pbsd 12y ago
The caller code. It is saying that the caller cannot dereference the returned pointer, under pain of undefined behavior.
411.
by pbsd 12y ago
Not exactly; from §7.20.3 in C99: If the size of the space requested is zero, the behavior is implementation- defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that t
412.
by pbsd 12y ago
Matt links to a paper on forward-secure public key encryption in the notes. While this shows it is possible in principle, the actual procedure is pretty awkward, and probably not usable in this current state.
413.
by pbsd 12y ago
Yeah. Joux's attack is conceptually simple. You have 2 tags T_0, T_1, obtained with distinct messages and the same IV. This means T_0 = S_0 ^ X and T_1 = S_1 ^ X, where X is the same value for both. So you have T_0 ^ T_1 = S_0 ^ S_1. S
414.
by pbsd 12y ago
Nonce reuse? It usually gets you at least forgeries, and in GCM's case it even gets you key recovery. I agree that the published sets of challenges don't really need much theory.
415.
by pbsd 12y ago
Blinding ECC is as easy as RSA, if not easier. Coron's classic paper has 3 easy measures to blind a scalar multiplication, and more have appeared since then: http://link.springer.com/chapter/10.1007%2F3-540-48059-
416.
by pbsd 12y ago
Yes, realistically you can only add at most ~30 bits of security to a password. This does not save very poor passwords, but can save decent ones. 'Strong' means different things in different contexts. SHA-256, for example, is a st
417.
by pbsd 12y ago
You mention yescrypt as an example of a good KDF, but its main design goal is to be a password hashing function! The main difference between a password-based KDF and a password hashing function is that the KDF usually needs to support varia
418.
by pbsd 12y ago
> Even though I support your conclusion of it being a manufactured controversy, this part of your post is not correct - it's actually 2 times - and is at the heart of the discussion. A citation from the Keccak site: Depends how you&
419.
by pbsd 12y ago
The quantum scenario is not particularly applicable here. Generic preimage attacks on sponges are essentially collision-finding on the capacity. Grover does not beat classical algorithms at this; Brassard-Høyer-Tapp doesn't either, if
420.
by pbsd 12y ago
This was a manufactured controversy if I ever saw one. The controversial changes were proposed by the Keccak team sometime after Keccak was announced as the SHA-3 winner [1], and did not originate from NIST. The idea was to decouple the sec

More ›