Reputation
3,901
Top tag
Next privilege 5,000 Rep.
Approve tag wiki edits
Badges
8 30
Newest
 Enlightened
Impact
~101k people reached

Feb
1
comment Would a Rubik's cube be a trapdoor function?
The algorithm to solve a cube is not brute forcing it — trying every possible permutation is. The algorithm to solve a cube is equivalent to a catastrophic known-plaintext cryptanalytic attack against the "Rubiks cipher".
Jan
27
comment Which cryptography technique does not increase the size of the plain data?
If you can store an initialization vector (typically 16 bytes) per encryption, this becomes trivial (use any stream cipher with a unique IV). However, the IV must be available to the decryption process. This IV can be stored separately from the encrypted data, or in some cases it can be inferred through context.
Jan
27
comment How can a message encrypted with the public key be decrypted with the private key?
You might find the Wikipedia article on RSA helpful. There are other asymmetric cryptosystems based on other principles, but RSA is relatively easy to understand. Long story short, it's based on modular exponentiation.
Jan
22
comment Which cryptography technique does not increase the size of the plain data?
Can 16 bytes of extra data be sent, in or out of band, once per file/session/stream?
Jan
8
comment Is it secure to use hexadecimal data for IV instead of raw binary?
An IV isn't necessarily always random bits. In some modes, it can be a simple counter. That said, the gist of your answer is correct: you should only ever provide an IV, key, or ciphertext in the format expected by your cryptographic library; usually, that is in the form of raw binary data. Encode this data however you wish for storage and transport, but always convert it back before sending it through cryptographic routines.
Jan
5
comment Is it feasible to build an index of prime factors?
Reading this answer again, the storage problem is even worse! According to the holographic principle, the maximum information density in a volume is proportional to the square of its radius (e.g., its surface area) rather than the cube (e.g., its volume). Redoing the math, we can only pack roughly $10^{84}$ values in the observable universe, and would need $10^{224}$ universes to store them. And of course, once you've stored them, you'd need to be able to efficiently look them up when needed, which is a whole other can of worms.
Dec
30
comment AES key equal to IV (CBC mode)
This has got to be the most-asked cryptographic question ever. There is a special level of hell reserved for those who reuse IVs despite thousands of dire warnings from cryptographers.
Dec
20
comment Guessing the IV for CBC
That said, if you don't know the original plaintext, you can at least recover all but the original block of plaintext without having the IV.
Dec
17
comment Can I store the initialisation vector (IV) in the filename?
GCM isn't "fancy". It's just a mode of operation. If whatever library you're using doesn't support it, find one that does. In 2015, non-authenticated modes of operation are no longer considered acceptable.
Dec
7
comment 2 Part Encryption
If the user is capable of generating a new key, and performing some transform on it such that the new key can decrypt the original data, it follows that the user can decrypt the original data. So why not simply decrypt it and reencrypt it with the second key?
Dec
4
comment What is cryptographic agility?
Another concern is downgrade attacks. If both sides of a client/server system are forced to support legacy cryptographic protocols, because some clients/servers haven't updated, even a pair of modern implementations can be tricked into falling back to an insecure ciphersuite. See recent TLS attacks involving export-grade ciphers.
Nov
28
comment Unbreakable encryption
1. Your algorithm can't and won't be kept secret indefinitely. 2. An attacker who can read your database can submit arbitrary passwords and see the encrypted result, and can use this to reverse engineer your scheme. 3. Encrypting passwords in the first place (instead of hashing them) is incredibly bad form and comes with its own set of exploitable behaviors.
Nov
23
comment argon2 versus bcrypt/PBKDF2 password hashing security gain
@SEJPM: even cperciva points out the TMTO, although it apparently has a constant tradeoff factor (which I believe argon2 avoids; I'll have to confirm).
Nov
23
comment argon2 versus bcrypt/PBKDF2 password hashing security gain
@otus: You're right; it's been awhile since I've read the scrypt paper. I'll update the answer.
Nov
21
comment For AES CBC, can I encrypt the IV with AES ECB and the same key and include it with the message?
In that video, he references (what I believe is) this paper which proves CBC under several notions of security. The only thing the paper appears to require of IVs in CBC mode is unpredictability to an attacker. The BEAST attack he mentions is possible because the IV fails the test of unpredictability, not secrecy. You'll also note that he mentions in literally the next sentence that his main advice is to not use CBC, which I fully agree with.
Nov
20
comment For AES CBC, can I encrypt the IV with AES ECB and the same key and include it with the message?
This is a pretty great example of how trying to add security to a system by blinding throwing more crypto at it can actually weaken security.
Nov
20
comment For AES CBC, can I encrypt the IV with AES ECB and the same key and include it with the message?
The requirements for an IV in CBC mode are uniqueness and unpredictability. A counter is insufficient.
Nov
20
comment For AES CBC, can I encrypt the IV with AES ECB and the same key and include it with the message?
You are inventing imaginary vulnerabilities where none exist. If cryptographers considered cleartext IVs to be a weakness, block cipher modes would have been designed in ways that didn't have such a weakness. Please do not try to be clever. Please do not try to invent your own crypto. Please just use off-the-shelf libraries that handle all of these details for you.
Nov
20
comment Keyless integrity checking with SHA-256
You're throwing the baby out with the bathwater; if you hypothesize state-level actors with arbitrary crypto-breaking capabilities, they can break any crypto. Keep in mind that creating and exploiting a chosen-prefix collision attack is considered more difficult than merely finding a collision (given a break in the underlying hash function). The answer to why not use a different hash function is because the described application doesn't require or benefit from resistance to length-extension attacks. You should choose primitives based on the capabilities actually required for your use-case.
Nov
20
comment Keyless integrity checking with SHA-256
The attack you suggest is a special-case of second preimage resistance: given $x$, it should be computationally infeasible to find a second preimage $x' != x$ such that $H(x) = H(x')$. In this case you're actually reducing the scope of the resistance to $x'$ of the form $x' = x\vert\vert y$.