pbsd

59 ms·

481.
by pbsd 13y ago
The latest revision to the C++ standard, including polymorphic lambdas, makes the xplusone definition much terser: auto xplusone = [](auto x){ return x + 1; }; While at it, here's how Paul Graham's accumulator generator l
482.
by pbsd 13y ago
The standard dictates that decltype(*r) deduces to T&, not T. The std::decay is there to collapse the reference type into a value type. Therefore your simplification results in a compilation error. An alternative way to get the value ty
483.
by pbsd 13y ago
The C++ standard gives little guarantees for the quality of std::random_device. As I remember, MinGW on Windows uses the Mersenne Twister with a hardcoded seed for it. boost::random_device, on the other hand, has better guarantees: it is on
484.
by pbsd 13y ago
The NFS complexity for factorization and discrete logarithm is asymptotically the same. In practice, the matrix step is more costly in discrete logarithm, but this should increase the bit security by at most a handful of bits, which is not
485.
by pbsd 13y ago
Yes. But it makes for a worse didactic example, since Sage does not support it out of the box. Imagine you know the middle 288 bits of p. Then you have to find small roots of the equation x1*2**400 + partialp + x0, which now has 2
486.
by pbsd 13y ago
It's really not that bad with today's computer algebra packages. Here's a simple example in Sage that works most of the time: p = random_prime(2**512) q = random_prime(2**512) n = p*q P.<x> = Polynomi
487.
by pbsd 13y ago
It's not a weakness. If the condition triggers, nothing bad really happens. The justification given in the patch is that the private key might be given to a pluggable random number generator, which may presumably be controlled by an at
488.
by pbsd 13y ago
Curious; VLAs are also one of my main pet peeves with NaCl's bundled C++ wrapper. You can't convincingly argue that it's to prevent memory allocations, since everything is passed and returned as std::string. Additionally, VLA
489.
by pbsd 13y ago
For the sake of historical accuracy, the NIST backdoor argument goes back to 1999 and Michael Scott [1]. I don't really buy it: if the NIST curves can't be trusted purely by association, then I find it very hard to trust the other
490.
by pbsd 13y ago
You're pretty much on point. When designing a scheme, whether a low-level cipher or a higher-level protocol, only a small fraction of the time is spent on the initial design itself. That is not to say that a scheme is designed and prom
491.
by pbsd 13y ago
It's not because of aliasing, it's because of the push_back call inside the inner loop, which may potentially have to allocate (in this case we know it doesn't, but the compiler does not). If you replace squareVec6 with
492.
by pbsd 13y ago
According to this StackOverflow reply [1], they do use the STL, but don't catch the (very rare) exceptions. [1] https://stackoverflow.com/a/15564254
493.
by pbsd 13y ago
That was a very reasonable response, I can roll with that. Just one thing: when I brought up talking directly to the hardware, I did not mean just for performance's sake. Avoiding side-channel attacks often requires to have high contro
494.
by pbsd 13y ago
OpenSSL and similar libraries spend most of their time processing short packets. For example, encrypting a few hundred bytes using AES these days should take only a few hundred CPU cycles. This means that the overhead of calling the crypto
495.
by pbsd 13y ago
Using C as an output language, backed by guarantees at the higher level, could certainly work. I believe ATS [1] works this way, and can even avoid garbage collection altogether if desired. I understand it is not an easy language, though. N
496.
by pbsd 13y ago
This sort of argument is becoming something of a fashion statement amongst some security people. It's not a strictly wrong argument: writing code in languages that make screwing up easy will invariably result in screwups. But it's
497.
by pbsd 13y ago
GMP [1] is the canonical solution for this. It's very fast (at scale) and has bindings to every useful language out there. It's also not that bad for small arguments. If GMP is not suitable, you're probably doing something fa
498.
by pbsd 13y ago
What do you mean by duct tape on x86? I'm quite familiar with the architecture, and this can be interpreted in more than one way.
499.
by pbsd 13y ago
There aren't many comments here, so I'll take the liberty of adding a thing or two. This is a CAESAR submission by Rogaway and friends. It is essentially a construction that uses AES and transforms it into a block cipher of arbitr
500.
by pbsd 13y ago
The actual analysis is available here: http://dualec.org/ I don't see much cryptographically new here; authors stretched what is a simple attack into 17 pages, and noticed that some non-standard TLS extensions that inc
501.
by pbsd 13y ago
AVX-512 does not seem to have PMOVMSKB, which is how I assume it is being done with SSE2. There are other ways to skin that cat, but it's unclear whether they have any advantage over using AVX2 with VPMOVMSKB.
502.
by pbsd 13y ago
R and S are the two signature elements. A is the public key, B is the common base. That is, A = B^a in prime fields, or A = a * B on elliptic curves. R is a random element used for each signature, usually R = k * B for randomly generated k.
503.
by pbsd 13y ago
In contrast with his previous posts, this one does not seem to contain much in the way of novelty, as nearly everything is already contained in the ed25519 paper [1]. To summarize, ECDSA is bad because (in order of gravity): - It requires c
504.
by pbsd 13y ago
If you do the padding and signaling of last nodes correctly, which as far as we know BLAKE2 does, a break in the parallel mode translates to a break in the sequential hash function. This was proven by the Keccak people a while ago [1]. [1]
505.
by pbsd 13y ago
FWIW, BLAKE2 does over 1 gigabyte per second on recent Intel chips. With the parallel modes it should be able to reach 3-4 gigabytes per second with multiple cores.
506.
by pbsd 13y ago
If you're referring to the recent FLUSH+RELOAD attacks, that is hardly ECC-specific. They also owned GnuPG's RSA earlier with the same technique [1]. On the other hand, if your argument is that ECC implementations are generally le
507.
by pbsd 13y ago
I don't see how that could not be a compiler error. The case b = 10 is more interesting because, as far as I can tell, it shows the differences between compilers that do two-phase lookup correctly and those that don't. This seems
508.
by pbsd 13y ago
You are correct. The Contra example is not different from the much simpler program #include <iostream> int main() { static bool p = !p; std::cout << p << std::endl; } The static storag
509.
by pbsd 13y ago
While CFB can be considered a self-synchronizing stream cipher, OFB is a typical synchronous stream cipher. Being stream ciphers, these modes suffer from the usual bit-flipping attacks and nonce-reuse problems, same as CTR. One problem spec
510.
by pbsd 13y ago
For primes of current acceptable size (>= 1024 bits), you might as well drop those extra checks. The elliptic curve method gives you around 2^512 attempts at doing the exact same thing, each one with the same probability of having a smoo

More ›