CodesInChaos
Reputation
12,269
90/100 score
 Apr 29 comment How to implement a Cryptographic Pseudo Random Function I prefer a two phase function: 1) Extract - Hash the seed and the input to a fixed size (say 256 bits) 2) Expand - Use a stream cipher to expand that key to whatever size you want. | You can use HKDF for this. Apr 29 comment How to argue to a paranoid that RSA is safe? There is little to argue beyond "many bright mathematicians tried to break it and nobody in published an attack faster than GNFS" Apr 29 comment Pseudocode for constant time modular exponentiation @fgrieu GnuPG used the naive if e[i] then c *= M until 2013. This enables cross VM attacks: eprint.iacr.org/2013/448 Apr 28 comment How can k3d3/ed25519-java's performance be improved? Using bitshifts for conditionals (select, conditional swap,...) is necessary since the code aims to be constant time. Branches/switch statements have variable runtime due to branch prediction. Apr 28 revised Pseudocode for constant time modular exponentiation added 60 characters in body Apr 28 comment Pseudocode for constant time modular exponentiation The exponentiation part is easy if you're willing to sacrifice performance. The modular reduction is harder, considering that even the modulus is secret. Apr 28 comment Pseudocode for constant time modular exponentiation But you cannot use an if for this. You need a constant time conditional swap for that. Apr 28 comment Pseudocode for constant time modular exponentiation Considering the beginner mistakes in GnuPG's RSA I'm beginning to have doubts about that. Apr 27 comment How can k3d3/ed25519-java's performance be improved? That's still relatively slow. I'd guess the biggest gains could come from switching to custom multiplications like in Ref10, followed by using pre-computation. My C# port of Ref10 (with its base $2^{25.5}$ integers) costs only 92µs for signing and 222µs for verification (2.9 GHz, 64 bit Intel). Even without pre-computation, signing should cost less than 300µs and verification shouldn't be affected at all. Switching from base $2^{25.5}$ to base $2^{51}$ results in about a factor 2 speedup, but isn't possible in C# (and probably neither in Java) due to the lack of 128 bit integers. Apr 27 comment Are RSA or ECC vulnerable to an attack where the same (unknown) plaintext is encrypted with multiple public keys? The "ECC" part is unanswerable without you specifying how precisely you use ECC. Usually we don't encrypt any data with ECC at all, we use it to generate a shared key which is then used to encrypt data. Apr 27 comment Tiger Tree Hash vs generic Merkle Tree The only reason is compatibility with existing protocols. Apr 25 comment Are the RFC3526 MODP groups Schnorr groups? I'd guess these are safe primes, so $r=2$, for Schnorr groups we generally select a much smaller $q$, only twice the security level. Apr 25 answered Can Skein be used as a secure MAC in format H(k || m)? Apr 23 comment Will hashing over and over eventually give the same hash? You will end in circles. I believe the average circle length is $\sqrt{N}$ when there are $N$ possible values. There are many such circles, once again approximately $\sqrt{N}$. Apr 23 comment HMAC definition by using only one key Apr 22 comment Compared to GCM or XTS modes, how secure is H xor R1, E (R2, R1, Message) for confidentiality and integrity? Authenticating the plaintext is risky. You can easily suffer from padding oracles and similar attacks (via timing side channels, error messages, etc.). We prefer encrypt-then-mac algorithms nowdays to avoid these issues. Apr 22 comment Compared to GCM or XTS modes, how secure is H xor R1, E (R2, R1, Message) for confidentiality and integrity? XTS is an unauthenticated mode, so it does not detect modifications of the ciphertext. It only limits how well the attacker can predict the plaintext corresponding to the ciphertext they produced. Apr 22 comment Use cases for CMAC vs. HMAC? Hashes usually faster than block ciphers sounds weird. After all most hashes are built from block ciphers and have stronger requirements than PRPness. Could be a historical accident since hashes are commonly ARX based, which is efficiently implementable in software, but that's no inherent property of hashes. Apr 22 comment Burn after read algorythm. Software verification on compromised environment. Software smart card Intel seems to be working on something that could enable such functionality in future CPUs. (But Intel itself could still subvert it and it obviously can't prevent the analog attack) Apr 22 comment Is less security required for a short stream cipher than for the AES enciphering of very long messages? What exactly is your question?