Reputation
889
Top tag
Next privilege 1,000 Rep.
Edit questions and answers
Badges
2 14
Newest
 Yearling
Impact
~40k people reached

Dec
3
comment Can a secret message be securely transmitted within a MAC tag?
I've updated my answer to address the code book and MAC scheme separately. My answer doesn't say that this scheme is insecure - indeed it states just the opposite! The 'don't roll your own' axiom remains true though; I've clarified that it applies to production systems.
Nov
30
comment RFC 6979 - Why not simply hash the message & the private key for deterministic ECDSA?
It decouples the output length of the hash function from the required length of k. I would have said it was to provide security even in the presence of a collision in the hash function, but I don't think it does.
Nov
30
comment Can a secret message be securely transmitted within a MAC tag?
Thanks, fixed the length. The actual data sent is of very restricted size, which is what I am referring to by 'message'. How this message is interpreted is up to the system it exists in as you point out. I wouldn't recommend using this non-standard approach - I've updated my answer to reflect this.
Sep
8
comment Which PRNG security requirements do I need for key generation
"get a hardware random number generator" or get two, one each from two countries whose governments distrust each other...
Aug
24
comment What current authenticated key exchange standards exist?
Yes, though the schemes specified in SP800-56A are not complete protocols, they are relevant.
Aug
17
comment Are there cryptographic hash functions that can be computed using only paper and pen without leaking any information about the plaintext?
Aha, I understand. Might be worth incorporating that into the question - I interpreted the read only random access store as a piece of paper with the message on. If you have an example usage scenario in mind that would be interesting.
Aug
17
comment Are there cryptographic hash functions that can be computed using only paper and pen without leaking any information about the plaintext?
Can you expand on why you have your side channel constraint? It doesn't seem to fit in with my model of what you're trying to achieve. The original (sensitive) information is on paper with the user. Why can they not create additional sensitive information and then either destroy it or leave it along with the original?
Aug
14
comment Pre-image resistant but not 2nd pre-image resistant?
Thanks for the info and good explanations and also the pointer to the hash function lounge - see my answer for what came of it.
Aug
2
comment Recent attacks on RSA
I was surprised after a quick search to not find any reference to their company selling EC products/solutions.
Jul
17
comment Physical analogue for MACs
@stephen Fair point, it does take a bit of thinking about. I think it could work for any scientifically minded person with no knowledge of crypto. Just to clarify in case there's any doubt: I completely made all this up.
Jul
13
comment Physical analogue for MACs
+1. The only thing this doesn't capture is the avalanche effect, whereby a small change to the contents of the delivery doesn't lead to a large (or any) change to the representation of the delivery (the delivery note). The description could be any representation of the contents, e.g. photographs, textual, a wax model...
Jul
11
comment Is FIPS 140-2's “Continuous random number generator test” practical?
Let us know what your lab says.
Jul
8
comment What current authenticated key exchange standards exist?
Thanks Ricky, but I'm now specifically looking for standards (NIST, ISO, IETF,...), not just proposals in the literature.
Jul
6
comment Using a Hash as a secure PRNG
Reseeding and support for arbitrary output lengths are some of the reasons why the specification for Hash_DRBG is longer than your specification, which is why I pointed them out.
Jun
20
comment When truncating an AES MAC value by “w” , how do I justify that “w” is still negligible?
forgot to ping @Watson for requested edit
Jun
10
comment Is it possible to anonymize web traffic so that the IP Address cannot be determined while still being able to determine distinct IPs?
The deterministic encryption scheme doesn't meet the first requirement - given an IP address, an attacker can compute the ciphertext and then determine what requests came from that address.
May
28
comment How to verify a shared secret using only AES?
Indeed; suggested update to answer to make that constraint clear.
May
28
comment How to verify a shared secret using only AES?
Be careful if you choose an unauthenticated mode to encrypt P_own||P_other - for example if you use CTR (or CFB with a 1 block size message) an attacker can subvert the protocol by computing E(k, P_b||P_a) from P_a, P_b and E(k,P_a||P_b); if using ECB and P_a and P_b are each a multiple of the block size, a trivial rearranging of the messages is all that is needed.
May
19
comment Is this algorithm secure?
That's right; provided the password is there in full in the input to HMAC (if HMAC is being used with a standard hash algorithm), adding additional entropy-less data doesn't lower the entropy of the output.
May
18
comment When truncating an AES MAC value by “w” , how do I justify that “w” is still negligible?
Thanks Watson, please do edit the answer.