meta user
network profile
| bio | website | |
|---|---|---|
| location | Paris, France | |
| age | ||
| visits | member for | 1 year, 9 months |
| seen | 5 hours ago | |
| stats | profile views | 93 |
I'm an engineer with experience in applied cryptography, in particular in Smart Card systems.
|
15h |
revised |
How random are comercial TRNGS Additions following comment |
|
1d |
revised |
How random are comercial TRNGS Discuss the thermal vs radio aspect of the question |
|
1d |
revised |
How random are comercial TRNGS Expand, add references, polish |
|
1d |
revised |
How random are comercial TRNGS typo |
|
1d |
revised |
How random are comercial TRNGS added 3088 characters in body |
|
1d |
answered | How random are comercial TRNGS |
|
2d |
comment |
Increased CRC collision probability when adding bits to input message @jmbeck: I'm proposing to trade a little usable space in the V2 format against improved error-detection capability. E.g. if V1 messages are 12-bytes payload + 1-byte CRC, V2 could be 10-bytes payload + 2-byte CRC/EDC + (K xor (1-byte CRC of the 12 previous bytes)), for some non-zero byte K to be decided from the polynomial (K=0xFF is rarely disastrous). The receiver computes the 1-byte V1 CRC of the first 12 bytes and uses that to reject the message or determine its type as V1 or V2, and (for V2) further checks the additional 2-bytes EDC/CRC. The undetected error rate is almost as good as V1. |
|
2d |
comment |
Is the likelihood of a birthday collision linear (evenly distributed) for all ciphers? When are they not? Also: see this about principal versus principle. |
|
2d |
comment |
Is the likelihood of a birthday collision linear (evenly distributed) for all ciphers? When are they not? You need to improve the question. Ask yourself: Does bias in the distribution of birthdays make collisions more or less likely? Is "all PRFs evenly distributed in set E" a proposition? Is AES a PRF, a block cipher, or modelisable as a PRP? Is the output of a permutation biased, for random input? |
|
May 21 |
comment |
Do I need to keep a 64-bit version number secret? The proposal $Version_n \oplus Hash(iv_n)$ (notice the fix) is security by obscurity: security lies in the method, not a key. Hiding the key version, as well as including it in the HMAC, looks pointless to me. If its desirable for some reason to hide the key version, what about replacing $Version_n$ by $Version_n \oplus HMAC(HMAC(version | iv | ciphertext | ..., key_{version_n}), longtermkey)$? |
|
May 21 |
comment |
Is Wikipedia's table about SHA-2 collisions correct? @Paŭlo Ebermann: What about a separate column for the best reduced-round attacks? |
|
May 21 |
comment |
Increased CRC collision probability when adding bits to input message @jmbeck: The summary would be: use the SAME polynomial, for defining the 1-byte field used as CRC for V1 and V2 (or multiple versions), with (in V2) a final XOR by an appropriate constant (or appropriate constants for more version), determined from the polynomial. Optionally, format the V2 (and up) messages as having an additional EDC (e.g. another CRC), inserted before the 1-byte CRC is computed. |
|
May 19 |
revised |
What is the recommended replacement for MD5? typo |
|
May 19 |
reviewed | Approve suggested edit on One time Pad Adversary |
|
May 18 |
comment |
Alternatives to HMAC + CBC? @Luke: If the attacker does not have "direct access to the database" or an equivalent mean, why do you want to encipher each record, and protect their integrity with a keyed scheme? You may need authenticated and enciphered access to the database, and this is NOT the same as authenticating and enciphering each record. |
|
May 18 |
comment |
Alternatives to HMAC + CBC? Also, in the database context: while the confidentiality of each record is protected, the location of updated records is not. And the atomicity of the updates of multiple related records (e.g. update of accounts in a manner preserving the overall balance) is not protected. |
|
May 18 |
comment |
Alternatives to HMAC + CBC? Indeed, the scheme is solid at the record level. I second @Reid's comment: each record's integrity is protected, but the database's integrity is not. Adding an identifier of the record's location in the HMAC helps, by preventing moving records, but it still allows rolling back each record of the database to an earlier state. Even if we link the update of records in some way, the database as a whole can still be rolled back. |
|
May 17 |
revised |
What are the potential security impacts of using CRAM-MD5 for Emails, when not using an SSL connection? Better expalin the main weakness |
|
May 17 |
revised |
What are the potential security impacts of using CRAM-MD5 for Emails, when not using an SSL connection? Polish |
|
May 17 |
answered | What are the potential security impacts of using CRAM-MD5 for Emails, when not using an SSL connection? |
