3,984 reputation
11032
bio website bradconte.com
location Texas, USA
age 27
visits member for 3 years, 4 months
seen Nov 11 at 6:49

I'm a software engineer with a background in computer science and mathematics. I love cryptography, math, and Linux.

More about me on my website: http://bradconte.com/about.


Mar
18
comment AES encryption takes more time to decrypt than encrypt
Do you know what mode of operation AES is being used in?
Feb
25
comment Strange Password Hashing
Hi there. Crypto.SE discourages custom algorithm analysis, which is really the essence of this question. You may receive better information by sifting your question down to a set of specific questions about achieving certain cryptographic properties. As it stands, the question is possibly in danger of being removed.
Jan
5
comment Deterministically combine more than one source of entropy
I think the canonical way to combine two numbers uniformly distributed between 0 and n is to just add them mod n. (Eg, XOR is often used for doing so, and it is just bitwise addition mod 2.) In the case of floating point, however, it may introduce precision bias due to precision limitations.
Dec
26
comment Unit testing a library RNG and its seeding for practical security
@JeffreyGoldberg: FIPS-140 requires RNGs to undergo "continuous output tests", generally meaning that an output block is compared to the previous output block and an error is raised if they are identical. This requirement may be applied to the entropy-gathering function itself that seeds an RNG, depending on how the entropy-gathering function is defined and constructed. (In my case the entropy-gathering process was deemed an RNG itself and required to undergo the continuity test.)
Oct
30
comment How does the IV or initial counter increase internally for each block in AES CTR mode?
@user4982: It's good to point that out, some approaches just generate a 128-bit random value and count on top of that. But I would argue a 128-bit counter is effectively a NONCE plus a counter with a random initial value, and the size of the counter is just implicit from the context (eg, perhaps a given encrypted message cannot be larger than 2^44 in size).
Oct
19
comment Does encrypting a hash of the message yield a secure MAC?
@pasgabriele: I don't know know for sure, but it seems reasonable. It would be very useful for this question to have that answered. If nothing else, with a fixed CBC IV you would be using CBC-MAC on the message hash. Signatures usually just sign a hash, MACing just the hash should be acceptable too.
Oct
18
comment Does encrypting a hash of the message yield a secure MAC?
@nightcracker: I'm not sure that's a necessary property of MACs. Avoiding leaking $x_0 = x_1$ is a requirement of confidentiality, not authentication. And in practice, the randomized ciphertext of both MTE and ETM will randomize the MAC. (And if you aren't encrypting, the point is moot.)
Oct
18
comment Does encrypting a hash of the message yield a secure MAC?
@pasgabriele: A PRF is a suitable MAC. Your question is probably best posed as: Is $PRP(hash(x))$ a PRF? Considering that a PRP is a PRF for hash-output sized inputs, this seams plausible at the outset.
Oct
18
comment Does encrypting a hash of the message yield a secure MAC?
@nightcracker: Which messages produce the same MAC (with non-negligible probability)? The provided example only finds intermediate values for doing so.
Oct
18
comment Two different approaches for Key Expansion using the AES-256 algorithm?
Good catch. I copied the code from the OP, I don't know why there is + notation. The actual algorithm uses the XOR operation, so maybe those instances should be changed to ^ for clarity. I assume they were intended to indicate the same thing.
Oct
16
comment DSA generate signature and verify
What is the signature you produced, and what is the private key ($x$)?
Oct
14
comment how much trust can we place in protocol verifiers?
This question appears to be off-topic because it is about the general usefulness/trustworthiness of automated proof generators/checkers. If it is actually about something more objective, please clarify the question.
Sep
28
comment Advise key management protocol
Does a standard public-key signing algorithm not suffice? If the recipient has the sender's public key, the sender can just sign with their private key and the recipient can verify the signature.
Sep
25
comment How is the initial permutation of DES created?
It's a bitwise permutation. What values are you thinking might be swapped?
Sep
21
comment Can I construct a feasible stream cipher out of HMAC and a secure hash algorithm?
Very typically, IVs are prepended to the ciphertext and MAC's are appended to it.
Sep
21
comment Can I construct a feasible stream cipher out of HMAC and a secure hash algorithm?
@MaxthonChan: Yes, you can keep the IV with the ciphertext.
Sep
19
comment Can I construct a feasible stream cipher out of HMAC and a secure hash algorithm?
Yes, they should be independent, assuming you want to use the key more than one time.
Sep
18
comment Can I construct a feasible stream cipher out of HMAC and a secure hash algorithm?
Whoops, you are right. Not sure how I missed that, considering what I used it for CFB mode.
Sep
18
comment Encrypting 8 times with 8-bit key beneficial?
For ciphertext only, aside from algorithm-specific properties/weaknesses, I don't know of anything better than brute-force.
Sep
18
comment Estimating bits of entropy
Do we have anything better than that for practical entropy estimates in real life? We don't (well, rarely) deal with truly random events, just events where we have a distribution and very little additional insight beyond that distribution. (Top of my head examples: hard drive seek times, mouse coordinates, etc. They aren't truly random, but at some level of detail you're stuck with a distribution of behavior and no way to analyze the source any more finely.)