Reputation
14,430
Next tag badge:
102/100 score
17/20 answers
Badges
1 36 76
Newest
 Nice Answer
Impact
~288k people reached

Feb
11
comment AES encryption takes more time to decrypt than encrypt
Can you include a link to the library you're using?
Feb
11
comment Pseudorandom function library
I'd first use HMAC-SHA-2 to reduce the input to a fixed size key and then use that key in a stream cipher to obtain arbitrary length output.
Feb
11
comment Attacking multi block MAC constructions
@xxx I have deleted my comment mentioning your original name. But please refrain from vandalizing the question or my answer. You asked the question and can't take it back.
Feb
11
comment AES encryption takes more time to decrypt than encrypt
You could use a mode that only requires encryption, such as CTR mode.
Feb
10
comment Why does NaCL have different keys for signing and encryption?
NaCl uses authenticated encryption (crypto_box). You can use crypto_box for authentication (typically with long term keys) and confidentiality (typically with ephemeral keys). Sharing long term keys between signatures and crypto_box based authentication is useful.
Feb
10
comment Strategies for securing public key storage on software
Obfuscation isn't enough, but that doesn't mean there is something better either. Software DRM inherently relies on security through obscurity.
Feb
9
comment Remove padding (CBC) from decrypted text
The IV generation code makes no sense. 32 Base64 characters would correspond to a cipher with 192 bit blocks, which is highly unusual.
Feb
8
comment Hash function as secure as one-time pad?
The identity function is collision resistant. Preimage resistance is obviously impossible against a computationally unbounded attacker if the cost of each hash xomputation is bounded.
Feb
3
comment Python implementation of a blind signature scheme which doesn't involve RSA
RSA based blind signatures are relatively easy to understand and IMO have less room for mistakes than group based blind signatures. If you want simpler padding, use FDH instead of PSS. I trust them significantly more, the only major downside is performance. One pitfall is that you should make sure that GCD(m, N) = 1, not only GCD(r, N) = 1.
Feb
2
comment Multiple encryption of part of block
1) This technique is known as Ciphertext stealing. It's secure in principle, but as @mikeazo already pointed out using ECB and using 64 bit block ciphers is generally a bad idea. 2) There are fancier length preserving encryption schemes. 3) I strongly recommend adding a nonce/IV and a MAC. While these increase the size of the message, the security implications of not having them can be severe.
Jan
30
comment How secure is it to use password as AES key?
At minimum it's bad style, since AES expects a uniformly random key. It also means that the password needs to be much stronger than what you'd need if you used a proper password based KDF.
Jan
30
comment Merkle hash tree updates
The basic variant of merkle trees is only efficient for leaf replacements and appending to the end of the dat, but not efficient insertions/deletions in the middle. But there are other hash tree constructions that allow efficient insertions.
Jan
28
comment How do I communicate the value of the initialization vector to the end user? Should it be part of the encrypted message?
Standard practice is using a random per message IV and sending it alongside the message, typically as a prefix. So in principle you got the IV handling right.
Jan
28
comment Why isn't CTR mode (counter mode) used more often?
@MaartenBodewes In that case I couldn't use what Microsoft built into .NET either. In fact whenever I needed raw CTR (not authenticated encryption like GCM), I needed random read access, which the .NET API doesn't provide.
Jan
28
comment Why isn't CTR mode (counter mode) used more often?
@Anthony Luckily implementing CTR on top of ECB is pretty easy. Perhaps 10 lines of code.
Jan
28
comment Why isn't CTR mode (counter mode) used more often?
One problem with CTR mode is that there isn't just a single way of turning counter and nonce into input for the block cipher core.
Jan
27
comment Is there a strong cryptographic reason for GCM's 2^39 - 256 bit limit?
I'm talking about using a message counter as nonce. That way you can have a collision between (k, n_1, c_1) and (k, n_2, c_2).
Jan
27
comment Is there a strong cryptographic reason for GCM's 2^39 - 256 bit limit?
For GCM to be secure the inputs to AES must be unique. With concatenation having a unique nonce (responsibility of the caller) and a unique block counter (part of GCM itself) is enough to guarantee unique inputs to AES. With XOR the caller must make sure that the 128 bit nonces are spaced far enough from each other so that xor-ing the counter doesn't cause a collision. That's annoying.
Jan
27
comment Is there a strong cryptographic reason for GCM's 2^39 - 256 bit limit?
With concatenation the caller only has to ensure the nonce is unique. For example they can use a counter. If you use xor or add nonce and counter you get overlaps, so a counter as nonce would be fatally broken.
Jan
26
comment How does BLAKE2 ensure that hash(A) != hash(B) when B = A||0 and both A & B have the same number of blocks?
My blog entry Alternative Blake Padding might be relevant, where I propose a simplified padding, which with some minor tweaks turned into the Blake2 padding.