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

Apr
5
comment A block cipher whose key changes after each block
Related: XTS
Apr
3
comment The state in RC4-128
1) The state is always 256+2 bytes. 2) What do you mean by a 4x3 bit key? RC4 operates on bytes and your talking about RC4-128 suggests that you're using a 128 bit key.
Apr
2
comment What asymmetric key exchange algorithms are known besides DH?
I think there is some super singular elliptic curve isomorphism thingy. No idea how practical it is.
Apr
2
comment If we should not reuse primes in DH, shouldn't we not reuse ECDH elliptic curve properties?
You can (and IMO should) hardcode primes for classical Diffie-Hellman. Just make sure they're big enough.
Mar
31
comment How is this for security?
Requests for analyzing or reviewing full cryptographic schemes/algos are off-topic. Try to break it down into specifics, such as "under condition A, does structure B have desired property C?"
Mar
30
comment Can an analog of ChaCha with 64-bit words be defined, and would it be secure?
@otus Since ChaCha runs in CTR mode, you can operate on as many blocks at the same time as you want. Typical SIMD ChaCha implementations work on two or three blocks. Hashing is different, because one block depends on the output of the previous block and parallelizable modes come with extra overhead.
Mar
30
comment Can an analog of ChaCha with 64-bit words be defined, and would it be secure?
@otus Using SIMD, two 32 bit operations have the same cost as one 64 bit operation. Thus using the same number of rounds for 32 and 64 bit ChaCha would result in the same performance. As far as I can tell, the 64 bit variant is only faster when you can't use SIMD on a 64 bit CPU.
Mar
30
comment Can an analog of ChaCha with 64-bit words be defined, and would it be secure?
I see no reason why it shouldn't be secure with sufficient rounds. But if you have access to SIMD instructions, ChaCha should be just as fast, so I don't really see a reason to use 64-bit ChaCha.
Mar
30
comment About MAC and HMAC
Also the biggest issue with encypt-and-MAC is that it doesn't provide confidentiality.
Mar
30
comment Which is the longest CSPRNG?
You can easily design PRNGs with arbitrary long periods (or if you admit unbounded memory use even infinite periods), but like poncho said, longer periods offer no advantage once the period is long enough to never repeat in practice.
Mar
29
comment Authenticated encryption with Enc-Sign-Mac
I'd use sign-then-authenticated-encryption, where authenticated encryption may be built using encrypt-then-MAC.
Mar
28
comment Bitwise method of generating r for RSA-KEM
Since a CSPRNG seeded from a low/no entropy seed still produces a random looking sequence, that doesn't seem like a worthwhile protection to me. Also mapping 0 to 2 won't help you in that case, since you can guess it just as easily.
Mar
28
comment Bitwise method of generating r for RSA-KEM
It should be straightforward to show that reducing the space of the message by 1 bit can't reduce security by more than 1 bit.
Mar
28
comment Bitwise method of generating r for RSA-KEM
Why do you require $1<m$? I see no issues with $0$ and $1$.
Mar
25
comment ChaCha20 core vs ideal unkeyed PRP
1) I think the ChaCha(0)=0 property generalizes to all words being identical. 2) ChaCha has obvious rotational symmetries.
Mar
25
comment ChaCha20 core vs ideal unkeyed PRP
I think the OP considers ChaCha without the final addition when they talk about the core.
Mar
25
comment What is the most common encoding of messages to polynomials?
My first guess would be using a random message and deriving a symmetric key from it by hashing (e.g. using HKDF).
Mar
24
comment How succeptible to accidental collision is the construct sha256(uuid4 + now) in Python?
It's at least not worse than a GUID by itself, which should be good enough even without any additional inputs. Personally I'd throw in an extra 32 bytes read from SystemRandom.
Mar
24
comment Parallel hashing function that always gives the same hash despite a variable number of cpus
Polynomial hashes (GHash, Poly1305) would work. Such hashes are only collision resistant against attackers who don't know the key, and 128 bits is a bit on the small side, even without attackers. A Xor-MAC like (the patented) OCB mode uses for its authenticated data has similar properties.
Mar
24
comment Parallel hashing function that always gives the same hash despite a variable number of cpus
"now there's overhead for making 100 1Gb chunks, hashing chunks, concatenating hashes, hashing again" -- the overhead is negligible.