20,530 reputation
32573
bio website
location
age
visits member for 3 years, 2 months
seen 3 hours ago

Oct
28
comment ID-based key exchange protocol with PFS
Alex, (1) in that case your requirement should be that you want an efficient protocol (specify what you want to achieve, not how to achieve it), (2) I very much doubt that signatures make the protocol inefficient. Signatures are fast. I mean, you're OK with the inefficiency of bilinear pairings, but not with ordinary digital signatures? That's counter-intuitive.
Oct
28
comment ID-based key exchange protocol with PFS
What is the reason for your requirement "besides using digital signatures"? What's wrong with using digital signatures? This seems like an odd requirement to impose.
Oct
27
comment ID-based key exchange protocol with PFS
@Alex, you're right, that's an even better scheme. I've added it to my answer. (For future reference, if you already know of a partial answer to your question when asking your question, it would be helpful to include it in the question; that increases the chances that someone can give you a helpful answer.) I've edited my answer, and I believe that everything in my answer is accurate.
Oct
27
comment ID-based key exchange protocol with PFS
@Alex, thanks for your interest. I described a hybrid scheme (which derives ephemeral session keys using DH/ECDH) in the 2nd paragraph of my answer, right after the phrase "hybrid scheme".
Oct
25
comment Hypothetical unknown cipher - security in obscurity?
Your premises are implausible in practice. What if an alien bought a pig at the market, and the pig the alien picked just happened to be able to fly? Hey, it could happen....
Oct
24
comment How do I prove that this PRNG is easily distinguished from a random sequence of numbers (modulo m)?
What have you tried? Where did you get stuck? (We expect you to make some effort before asking here.) Do you know what the definition of "distinguishing from a random sequence" is? Have you tried plugging into the definition? Where did this problem arise? What's the context/motivation? Why do you need to prove it? If it's a textbook exercise, have you reviewed the material on PRGs and on elementary number theory?
Oct
23
comment Should I use the first or last bits from a SHA-256 hash?
@Pacerier - No. There is no reason to believe that using the last bits would be detrimental to security (and there are very strong reasons to expect that it is not detrimental). You're misreading the contents of that link.
Oct
21
comment What's wrong with MARS?
"As I understand only MARS and Serpent implement measures to counter future cryptoanalytic attacks" - Your understanding is faulty. All of the finalists (probably all of the submissions, or essentially all of them) included measures that their designers hoped would counter future cryptanalytic attacks.
Oct
21
comment What's wrong with MARS?
Did you read any of the analysis that was published on MARS? There were a series of workshops with a whole bunch of papers that came out of the proces. Did you read NIST's document explaining their final choice of the AES? If not, those would be good documents to go read!
Oct
20
comment Encoding information in packet lengths to actively sidestep encryption
The relevant concepts are: "side channels", "covert channels", and "steganography". As K.G. said, covert channels or stego are probably the ones most relevant to you.
Oct
10
comment The Goldreich-Goldwasser-Micali Construction with bad PRGS
I very much doubt that GGM will offer useful security if the underlying PRG has a significant bias. I think your argument is unconvincing and your hypothesis is unlikely to hold.
Oct
8
comment Predicting values from a Linear Congruential Generator
See also security.stackexchange.com/q/4268/971 for more on cracking LCGs (though with a different set of assumptions).
Oct
7
comment Openssl & RSA : how many public exponents are possible?
There are no security benefits to large exponents (assuming you use RSA properly, including proper padding and so forth; and if you don't use RSA properly, then you've got bigger problems and might be in trouble no matter what exponent you use).
Oct
3
comment Calculating ciphersize of Paillier, SSE and OPE
Similar comments apply to SSE and OPE. It is extremely unlikely that 64 bits will be sufficient for the ciphertexts of SSE and OPE. And, as explained in my answer, the length of the ciphertexts for OPE and SSE depends upon which scheme you use, so there is not one answer to the question (your answer seems to be based upon the erroneous premise that there is only a single algorithm for SSE/OPE).
Oct
3
comment Calculating ciphersize of Paillier, SSE and OPE
A Paillier ciphertext will be a lot longer than 64 bits. Probably more like 4096 bits (assuming a 2048-bit key, which is about the level needed to provide good security today, given the state of modern factoring algorithms).
Oct
3
comment Reordering non-block-aligned parts with DES in ECB mode
Can you tell me the context where you ran into this? What makes you think it is possible to exchange the first line with the last? Why are you so set on that specific goal? That seems awfully specific (as opposed to, say, swapping some pair of entries of the attacker's choice). I assume you know that you can swap any pair of ciphertext blocks, and the corresponding plaintext blocks will be swapped? So if you can find a pair of blocks that, when swapped, leaves the format of the plaintext undisturbed (and such that the exchange is favorable to the attacker), that's a valid attack.
Oct
3
comment Using multiple secret keys
Yeah, that's not gonna work. Someone who is not physically at the specific location, but who knows where the specific location is, can still infer the key and decrypt the ciphertext. There's been academic work on this sort of problem (e.g., by Dorothy Denning), but it's a much harder problem than you seem to realize.
Oct
2
comment Extracting only the entropy
@Blaze, oh, good grief. No it doesn't. Read the paper. Nowhere does the paper say "/dev/random is no good". I challenge you to find anywhere where it says that. If you are thinking of the title ("/dev/random is not robust"), by 'robust' they are referring to a particular technical/mathematical definition of robustness. Failure to meet that definition doesn't mean that "/dev/random is no good". As the abstract says "it remains unclear if these attacks lead to actual exploitable vulnerabilities in practice".
Oct
2
comment Using multiple secret keys
Why do you want to use these keys? What are your goals? What threat are you trying to avoid? What are you trying to achieve? What bad outcomes are you trying to avoid?
Oct
2
comment Extracting only the entropy
@Blaze, OK, well, I'll put it this way then: it sounds to me like you may be drawing unwarranted and overly strong conclusions. The research you cite does not imply that "/dev/random is no good" (nor do the authors of those papers make broad claims like that). Be careful; cryptography is a subtle and nuanced business, you can't always reduce things to simple sound bites.