Reputation
3,585
Top tag
Next privilege 4,000 Rep.
Access 'trusted user' tools
Badges
6 29
Newest
 Nice Answer
Impact
~76k people reached

Jun
5
comment Is the one-time-pad a secure system according to modern definitions?
What? That's not even remotely correct. An attacker, even in a modern context, with the ciphertext and key can recover the plaintext.
Jun
4
comment How do we know a cryptographic primitive won't fail suddenly?
And there may be as-yet unconsidered notions of security that we only begin to realize the importance of some time in the future.
Jun
4
comment Is it OK to use a hash of the key as nonce for AES GCM?
The nonce is typically transmitted along with the ciphertext — there is no requirement for it to be kept secret. Given what I provided above, it should be painfully obvious why you would want to use a variable nonce: to encrypt more than one plaintext with a single key. If any {key,nonce} pair is ever reused (particularly in CTR-based modes), secrecy of the messages the pair was used for is completely lost.
Jun
4
comment Sending the next one-time pad key in this one-time pad message?
You do not get good cryptography by bolting bad cryptography onto more bad cryptography. You just get differently bad cryptography.
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
revised Sending the next one-time pad key in this one-time pad message?
edited body
Jun
3
revised Is it OK to use a hash of the key as nonce for AES GCM?
added 30 characters in body
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
answered Sending the next one-time pad key in this one-time pad message?
Jun
3
revised Is it OK to use a hash of the key as nonce for AES GCM?
added 363 characters in body
Jun
3
answered Is it OK to use a hash of the key as nonce for AES GCM?
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.