Reputation
Top tag
Next privilege 5,000 Rep.
Approve tag wiki edits
Badges
1 13 36
Newest
 Enlightened
Impact
~146k people reached

Apr
8
comment May the problem with DES using OFB mode be generalized for all feistel ciphers
Yes, but OFB only uses the encryption "blackbox", so it doesn't decrypt and encrypt repeatedly like you suggest. OFB doesn't need the decryption "blackbox" (just like Feistel ciphers don't need to be able to reverse their one-way $F$ function to work).
Apr
8
comment May the problem with DES using OFB mode be generalized for all feistel ciphers
"So, as we know using a feistel cipher has the nice property that running it twice through the cipher results back in the plaintext" not really, the subkeys are processed in the opposite order.
Apr
6
comment Is there a preferred way/standard on how to transmit an initialization vector for AES encryption
Plus, if you put it at the beginning, you can perform decryption as you receive the data, whereas you can't do that if the IV is appended at the end. Though this shouldn't be an issue either way since you need to MAC what you receive (you do use a MAC, right?)
Apr
3
revised What's the difference between “HashX-512” and “HashX-1024”?
corrected typo
Apr
3
answered What's the difference between “HashX-512” and “HashX-1024”?
Mar
28
comment Why are RSA key sizes almost always a power of two?
Would you prefer key sizes of 818 bits, 1935 bits, 4144 bits? There is no cryptographic advantage, but using nice round numbers allows them to be more efficiently implemented and stored. It is also simpler, convention, and just makes more sense than apparently arbitrarily chosen key sizes. Also, 9000-bit RSA is overkill, people using such large keys are just wasting CPU cycles (and it's not "over 9000" anyway, so it fails in this respect as well ^^).
Mar
27
comment Potential vulnerability in DH key selection - am I understanding this right?
@Polynomial Doesn't "using Java's Random" count as a colossal vulnerability already? I think anything else short of handing over the secret nonce is moot in comparison. Good question nonetheless, timing attacks are very relevant currently.
Mar
25
comment Where can I begin to study the math behind modern cryptography?
Could you clarify "how computers simulates exact mathematical calculations"? Do you mean binary representation to store numbers? Cryptography rarely uses floating-point numbers.
Mar
23
reviewed Approve reduces the coefficients of a modulo 3 on NTRU
Mar
22
comment Could a very long password theoretically eliminate the need for a slow hash?
"would" use, then. But even if the question was hypothetical, your entropy estimates do require the above condition (which I feel is important to state clearly, as this is a common question in cryptography), which is not achievable by humans (for instance, many people would use a sequence of words for such a long password, dropping the entropy to maybe 2-3 bits per character). Unless in the hypothetical scenario, humans are also robots, in which case fair enough. But no matter what humans choose, yes, ultimately such a long password would be almost certainly secure no matter what.
Mar
21
revised How to calculate y value from ((y*y) mod prime) efficiently
edited tags
Mar
21
comment Could a very long password theoretically eliminate the need for a slow hash?
Only if each character of the password is randomly (and independently) selected from the relevant alphabet, which is typically not the case for humans. Of course, a 43-character password does provide a huge safety margin, but some people will still use "123123123..."
Mar
20
comment Sensible usecase for restricting special characters in passwords?
I'd say ease of use. A password with a newline or control character in it would be somewhat awkward to type in. Since nobody will ever use those, why not disable them and spare an unlucky user the pain of figuring out why his password is not being accepted the next time he types it in?
Mar
20
comment How would one crack a weak but unknown encryption protocol?
It's not so much direct analysis on the ciphertext, which doesn't work unless the encryption algorithm is truly crap (for instance, there is no easy distinguisher between, say, AES and Blowfish). The real danger is someone disassembling software which uses your "unknown" protocol and figures out how it works, at which point you better have a secure key to fall back on, or you're screwed. A single ciphertext won't tell you much if your target's cryptographic skills are beyond ROT13 level.
Mar
19
reviewed Approve Key Exchange and anonymity issue
Mar
18
comment Solving congruences using PARI
I don't know much about PARI/GP but I think Mod does more than just take the value of a modulo b (it changes its datatype, too). Can you try just using a%b instead? Though I'm not sure how to get the modular inverse in that case, you'll need to look that up. I'm sorry, I'm not of much help - I don't use PARI/GP.
Mar
17
comment Solving congruences using PARI
Did you read the algorithm outlined on the Wikipedia page I linked in your previous question? There's a walkthrough with 2 congruences (pairwise coprime, though) and then for the general case. Then you can implement it using only standard arithmetic and a modular inverse algorithm (which PARI should have). If this is about using a built-in function of PARI/GP to solve general systems of congruences, it's off-topic here.
Mar
17
reviewed Close Tree hash and multithreading for parallelism
Mar
17
comment Export from US of crypto software with key-size > 56 bits still needs permission?
These export regulations are (thankfully) obsolete, though cryptography is still considered a weapon and some restrictions still apply. See current regulations... this is a good read too.
Mar
17
answered Low Public Exponent Attack for RSA