Reputation
3,427
Top tag
Next privilege 3,500 Rep.
Protect questions
Badges
6 28
Newest
 Nice Answer
Impact
~70k people reached

Jun
4
comment Sending the next one-time pad key in this one-time pad message?
It doesn't matter. Your only assertion of the digits is that they are (probably) normal. Normal isn't remotely close to strong enough a property for cryptographic use. Additionally, you can't assume the attacker doesn't have access to the beginning of the keystream — perhaps you're encrypting something that's partially attacker-controlled.
Jun
4
comment How do we know a cryptographic primitive won't fail suddenly?
Longer version: security is about risk management. Will AES be broken tomorrow? Almost certainly not. Next year? Probably not. Next decade? Likely not. Next century? Who cares? At the point where you're using AES, you have far more likely risks than a break in your ciphers.
Jun
3
comment Sending the next one-time pad key in this one-time pad message?
There is no test to determine how random a number is, as randomness is measured by the entropy in the generation of a number; it fundamentally cannot be a measure on a number itself (or even a sequence). Is "1" a random number? Is the sequence "1, 1, 1"? What about "51, 14, 22, 109"? Alternatively, the output of AES passes statistical tests for randomness. But if I give you the output of $\mathrm{AES}(k, 0)$, $\mathrm{AES}(k, 1)$, $\mathrm{AES}(k, 2)$, given a secret $k$ that I know, you have no way to guess the next value. But I do.
Jun
3
comment Brute Force on Key
With authenticated encryption modes, it's actually quite easy. You don't decrypt the text; you simply try to verify the authentication tag given the key, nonce, ciphertext, and additional authenticated data.
Jun
2
comment AES-CTR in BouncyCastle with string key, without IV or salt
@MLProgrammer-CiM Really, just read the code you pasted. There are comments explaining exactly what it's doing to turn the password into a key (badly) and generate a nonce (badly).
Jun
2
comment AES-CTR in BouncyCastle with string key, without IV or salt
@MaartenBodewes A timestamp as the nonce is alone worth damning the entire thing. If you happen to generate two ciphertexts within the same millisecond, confidentiality of those ciphertexts is completely broken. Worse implementations might exist, but the bar should be higher than "not the worst".
Jun
2
comment AES-CTR in BouncyCastle with string key, without IV or salt
As an aside, this implementation of AES was, in my opinion, written by someone completely unqualified to implement cryptography for a production environment. The API is absurd, the comments reveal cryptographic incompetence, a millisecond timestamp is used as a nonce, etc. I wouldn't use this code to protect anything remotely important.
May
28
comment Can AES be considered as Perfectly Secure?
More concretely, "perfectly secure" means that mathematically, the ciphertext contains no information about the message unless you have the key (except for a maximum possible length). That said, it's a poor choice of terminology, because one-time pads are susceptible to some forms of attack (for instance, they are malleable).
May
28
comment Is it practical to use a stream cipher in a block cipher mode?
Cryptography is not an subject where you should endeavor to be creative. What do you hope to accomplish with such a construct? What shortcoming of a stream cipher are you aiming to overcome?
May
26
comment One time pad in CBC mode?
The point @mikeazo is trying to make is that your question is nonsensical. It's like asking whether or not it's safer to have anti-lock brakes on a jet-ski. Just as anti-lock brakes only apply to wheeled vehicles, CBC mode only applies to block ciphers — but one-time pads are a form of stream cipher. The property you want to avoid is malleability, but this is not something CBC defends against as it is trivially malleable. You are looking for cryptographic authenticity.
May
26
comment HKDF entropy extraction
Both any new cryptographic concept added to a system and any line of cryptographic code written brings non-negligible risk of messing it up. Cryptographers strive to use the absolute minimum necessary to provide the required security to a system.
May
24
comment HKDF entropy extraction
Again, if you are trying to defend against an operating system that is actively working against you, you have already lost. CryptGenRandom may very well be backdoored. If it is, you have no reasonable expectation that any other function of the operating system is acting faithfully.
May
22
comment HKDF entropy extraction
This is security theater. First, CryptGenRandom already collects entropy from mouse movements, keystroke timings, etc — and using a much more well-tuned algorithm than you are likely to. Second, if Microsoft is untrustworthy and CryptGenRandom is backdoored, you're already screwed. Just use the output of CryptGenRandom and spend your leftover time addressing attack scenarios with a higher ratio of risk vs mitigation effort.
May
21
comment one-way deterministic hash for low entropy input?
The best you can do in this case is something like an HMAC with a secret key. If an attacker doesn't have the key (or an oracle), they won't be able to enumerate the hashes.
May
20
comment Can i get a list of over hard and long RSA keys? i think i have found a vulnerability in RSA Algorithm
Sorry, but unless you have discovered a new branch of mathematics, it is overwhelmingly likely that you have not found a way to quickly factor large primes.
May
18
comment Building a combined encryption scheme from two encryption schemes that's secure if at least on of them is secure
What directions have you tried? The hint in the question, plus @MaartenBodewes's answer is 98% of the solution.
May
15
comment Authenticate a short message with redundant encryption instead of using a MAC?
If you are validating tens of thousands of these per second, are you certain your assumption holds that sub-millisecond resolution is good enough to guarantee uniqueness?
May
15
comment Authenticate a short message with redundant encryption instead of using a MAC?
Yes, this would absolutely not work with a stream cipher, as flipping the same bit in both halves would result in the same plaintext output.
May
11
comment AES_GMAC implementation
To elaborate on @SOJPM's comment, it seems suspicious that you would have any need to implement AES-GCM as a person with a non-cryptographic background. If this is for a class, it's curious that there would be an expectation of implementing such an algorithm without having previously analyzed the construction. So it, frighteningly, looks like you might actually be trying to implement this for a real-world use.
May
1
comment Block cipher does not provide security by itself
Put succinctly by Bruce Schneier, cryptography is not magic dust you can sprinkle on your software to confer the property of "security".