Reputation
Top tag
Next privilege 5,000 Rep.
Approve tag wiki edits
Badges
9 30
Newest
 Pundit
Impact
~117k people reached

Feb
26
comment Applicability of birthday attack to AES brute force
Yes, a birthday attack scenario comes when a user generates many keys, and an attacker need only collide with one at random.
Feb
19
comment How to construct encrypted functions (with either public or private data)?
Assuming an FHE scheme with encryption function $E$ that calculates $F(X)$ given public $F$ and encrypted $X$, instead of $F = f(x)$, $X = E(x)$, you would use $F = g(X,Y)$, $X = E(x), Y = E(f))$, where $g(f, x) = f(x)$.
Feb
19
comment How to construct encrypted functions (with either public or private data)?
@sashank In typical FHE, the function is public and the data is encrypted. What Mike Azo is proposing is one further step of abstraction. The function is now "given a circuit and some input, return the output of applying those inputs to the circuit", and the encrypted data is, "a circuit and some input".
Feb
16
comment How does hash speed vary based on string length?
@SLC To reiterate fgrieu's point, SHA-256 is not a suitable function for storing and verifying passwords, precisely because it is fast. Use a dedicated password hashing function like bcrypt, scrypt, or PBKDF2.
Feb
9
comment How is a message digest decrypted?
@RobertFlook Encryption is not authentication. Just because an attacker can't read a message doesn't mean they can't either manipulate it in a predictable way, or (as is typical with computer systems) at random until they get the result they're hoping for. Being able to discard a forged message before processing it can even prevent an attacker from recovering the plaintext in adaptive chosen-ciphertext attacks.
Feb
7
comment What is wrong with simple concatenation in salted password hashes?
None of these constructs are secure, and unfortunately, length extension attacks have nothing to do with it. Please just use bcrypt or scrypt. See this answer for more details.
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.