| bio | website | |
|---|---|---|
| location | Paris, France | |
| age | ||
| visits | member for | 1 year, 9 months |
| seen | 3 hours ago | |
| stats | profile views | 93 |
I'm an engineer with experience in applied cryptography, in particular in Smart Card systems.
|
1d |
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. |
|
1d |
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. |
|
1d |
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. |
|
2d |
comment |
What are the potential security impacts of using CRAM-MD5 for Emails, when not using an SSL connection? The summary of CRAM-MD5 protocol weaknesses on wikipedia is not bad. |
|
2d |
comment |
Help me describe/identify this challenge-response protocol/algorithm? @Cybergibbons: in a secure MAC with $k$ possible keys small enough that all keys are enumerable, and $o$ possible outputs, little more than $\lceil k/o\rceil$ examples are necessary to find the key. Here $k=256$ (after vector becomes public), $o=100000$, thus little more than one example is enough. In fairness, an adversary was not supposed to get the program that you reverse-engineered to extract vector; but even considering this, the algorithm is ridiculously weak, see 3a' |
|
2d |
comment |
Now that quantum computers have been out for a while, has RSA been cracked? I want to point as worthwhile this opinion and report on the recent events surrounding the D-Wave computer. Especially that part: "Matthias Troyer’s group spent a few months carefully studying the D-Wave problem—after which, they were able to write optimized simulated annealing code that solves the D-Wave problem on a normal, off-the-shelf classical computer, about 15 times faster than the D-Wave machine itself solves the D-Wave problem! " |
|
May 16 |
comment |
True random numbers generated by sensors Two problems with use of any hardware as the source of true randomness are 1) hardware fails 2) how much entropy it generates is hard to estimate, and often quite variable. For example, it is entirely conceivable that a particular's iPhone accelerometer is damaged, with constant output of the physical sensor; that an iPhone lays on a steady surface; that apparent noise in the output in that condition (if any) is an artifact of an algorithm, and deterministic; that some factor (temperature, orientation w.r.t. to gravity field..) reduce to nothing the actual entropy available. |
|
May 16 |
comment |
SHA-1:Is there any mathematical result that gives us the minimum number of 1's in a 160-bit SHA-1 hash output? Additional hint: build (perhaps with a spreadsheet or short program) a Pascal Triangle of appropriate size (perhaps filling it with odds rather than raw number of possibilities); then sum the appropriate terms. |
|
May 15 |
comment |
Increased CRC collision probability when adding bits to input message Indeed, if version 2 was using a different polynomial than V1, there would be collisions between CRC for V1 and V2. I address this issue in the fourth paragraph of my answer. |
|
May 7 |
comment |
What's the difference between AES and earlier block ciphers? @Smit Johnth: Other common operating modes (CFB, OFB, CTR) have the same vulnerability: constant plaintext is correlated to lower odds of collision between ciphertext blocks, and that may be a concern for (nowadays) practical data sizes and 64-bit block ciphers. The best fix is to use a wider block cipher (kludges are possible with CBC and CFB; e.g. add the block index to each plaintext bock). |
|
May 7 |
comment |
Are digital signatures secure for signing lots of small messages? Perhaps make that any good digital signature algorithm; some standards have been lacking in this respect; e.g; ISO/IEC 9796 (better known as ISO/IEC 9796-1) which was withdrawn following attacks, and ISO/IEC 9796-2 which has a more or less serious vulnerability in its original (and most used) mode. |
|
May 7 |
comment |
RSA leak bits to factor N Very nice question, that stands not fully answered!! An observation: leaking 1 more bit can only help any well-tuned algorithm by a factor of at most 2 (otherwise, we could use that to construct a better algorithm). Therefore, for N of a size making it borderline factorisable (or equivalently, low k), the optimal solution can not be hinting a mediocre algorithm (like any improvement of Fermat factoring). The problem may have different solutions depending on how much N is above the state of the factoring art. |
|
May 7 |
comment |
RSA leak bits to factor N Are you thinking at hinting an Elliptic Curve factoring algorithm? Seems promising, for EC factoring is very near the best factorization algorithm around. Could you elaborate? |
|
May 6 |
comment |
What is a CBC Mac Scheme? How does knowing one block release other? The minimum before asking TWO homework questions about CBC-MAC is to study what that is. |
|
May 6 |
comment |
Is there any strong enough pen-and-paper or mind cipher? I think that the suggestion to use RC4-52 in this answer can be made reasonably secure, and practicable with a deck of card by a trained operator. Devil is in the details, in particular the key and nounce/salt setup. I add that much less than 52 symbols should be used for plain and ciphertext, and keystream outside that range should be discarded (I conjecture it strengthen the keystream generator significantly). |
|
May 5 |
comment |
how much is secure to encrypt a password using itself (as encryption key) for storing it on a unsecure media? Is this homework? There's a tag for that. Hint: how much CPU.time would it take to find the password using an implementation of AES based on this, assuming the password is the first one described here? Compare with proper use of scrypt. |
|
May 5 |
comment |
Is there any strong enough pen-and-paper or mind cipher? The OTP is a perfectly strong encryption system, simple enough to be performed with pen and paper, but is neither a cipher by some theoretical definitions thereof; and is not practical, for the pad is hard to generate, impossible to remember, and hard to conceal. |
|
May 5 |
comment |
What length should the padding be when encrypting or signing with RSA? @ispiro: Yes padding is right (added it in the answer). The simplest: use a standard signature and verification library implementing RSASSA of PKCS#1, or ISO/IEC 9796-2. If you want to roll your own implementation (which makes some sense for copy protection), you can still use a standard scheme. You will be very much on the safe side w.r.t. signature forgery doing as in a)&b) in your comment above, baring implementation mistakes (in particular: the verifier MUST check both the signed message/computer-id, and the deterministic random-like portion of the padding obtained from that). |
|
May 4 |
comment |
Why is the basic (fixed-length) CBC MAC construction not a secure MAC when it is used on variable-sized messages? Is that homework? There's a tag for that. Hint: given one message of $n>0$ blocks and its authenticator, build a message of $2n$ blocks with the same authenticator. |
|
May 3 |
comment |
What length should the padding be when encrypting or signing with RSA? Is your + denoting addition, or some other operation? Also: you can write $(m+salt)^d \bmod n$ as $(m+salt)^d \bmod n$. |