meta user
network profile
| bio | website | |
|---|---|---|
| location | Paris, France | |
| age | ||
| visits | member for | 1 year, 9 months |
| seen | 4 hours ago | |
| stats | profile views | 93 |
I'm an engineer with experience in applied cryptography, in particular in Smart Card systems.
|
Apr 3 |
comment |
“Weaknesses” in SHA-256d? @Nemo: Samuel Neves remark is that ability to find $m$ and $m'$ of the same length with $\operatorname{SHA-256}(m)=\operatorname{SHA-256}(m')$, allows to trivially find a short padding $p$ such that for any suffix $K$, $\operatorname{SHA-256d}(m||p||K)=\operatorname{SHA-256d}(m'||p||K)$. It could be a problem if SHA-256 was broken (which is: not any soon); and one used a BadMac defined as $\operatorname{BadMac}(K,m)=\operatorname{SHA-256d}(m||K)$, rather than a good MAC such as HMAC. |
|
Mar 28 |
comment |
Assymetric password encryption - Viable? Which algorithm? Hybrid encryption is usually not used to encipher a public or private key, and I am not proposing that. An hybrid encryption scheme enciphers sizable data payload (here: the passwords) using a symmetric cryptosystem, which secret key is enciphered using public key crypto (possibly: once for each recipient, here each server). The total size is that of all the passwords, plus one constant-size cryptogram for each recipient with distinct key. The secret key is recovered by each recipient. It can be cached in RAM. Decryption of the passwords can occur on demand. Refinements allow password updates. |
|
Mar 28 |
comment |
Why are RSA key sizes almost always a power of two? @Joe Zeng: That's not what I meant. In my original answer, the "later" you quote referred to considerations on word/storage unit size. This creates much more marked steps than the (relatively smooth) addition of an extra squaring step, because the later depends on the number of bits in the exponent, which is not bound to be a multiple of something, and is typically a little less than $n$. |
|
Mar 28 |
comment |
Solving hard problems in $\mathbb Z_{p}^{*}$ when $\mathbb p$ is close to $\mathbb 2^{n}$ @Samuel Neves: the rule of thumb you conjecture (I noted the use of perhaps) also applies to composite $N$, and would allow use of $N=2^n-c$ with $c\approx2^{n/5}$ for $n\ge1024$ with no significant security loss in RSA. That has practical applications: appreciably faster implementation of $x\mapsto x^e\bmod N$ (and as an aside more compact public key without use of an arbitrary value). Can you quote other sources of that rule of thumb? |
|
Mar 28 |
comment |
What does the expression $1^n$ mean as a function argument? Please supply a link to the document mentioning the said function. At that point I can only agree with "I am not clear". |
|
Mar 27 |
comment |
one-time pad key related attack @lanc: One can not logically deduce from my previous comment that anything involving pad/key reuse is safe. For many definitions of safe, reusing the same pad/key for another random message is unsafe. For example, the adversary can test if the two random messages are identical, by testing if the two ciphertext are identical. There are situations where that may be important, e.g. if the message is one bit linked to some physical action. |
|
Mar 27 |
comment |
one-time pad key related attack In cryptography, it is standard practice to assume the plaintext of one message (or/and some of the plaintext) gets known. That leaks the OTP's pad for the corresponding plaintext. If that pad was reused, it would no longer protect the confidentiality of the message it combines to. That applies to any plaintext, including random. |
|
Mar 27 |
comment |
How to choose between AES-CCM and AES-GCM for storage volume encryption @CodesInChaos: why do you think GCM "feels very fragile"? My chief reservation about it is that it is not widely implemented yet, and that makes it next to impossible to use in some contexts (e.g. Java Card Classic). |
|
Mar 27 |
comment |
Is it feasible to break Diffie-Hellman key exchange when the implementation uses a poor-quality PRNG? There are at least three different implementations of the default seed for the default Java Random class; one use an at-most-32-bit seed derived from the system time in millisecond (OR MORE); another use an at-most-48-bit seed of ++seedUniquifier + System.nanoTime() where seedUniquifier is some shared global initialized from a public constant; the third uses seedUniquifier()^System.nanoTime() where seedUniquifier() uses a shared global atomically updated per a multiplicative RNG with public seed and multiplier. Neither method is meant to be used for crypto. |
|
Mar 27 |
comment |
Potential vulnerability in DH key selection - am I understanding this right? @Polynomial: if the default Java Random object is used (which may or may not be the case when Random is used), and if you can detect using timing analysis that the $\bar a \geq p$ condition has been triggered, then you can rule out some states or/and initial values of the RNG, and speed-up an attack; in fact, you could conceivably recover the state of the RNG by timing analysis only. That has nothing to do with DH. |
|
Mar 27 |
comment |
Is SpookyHash vulnerable to HashDoS? The creator says it would be possible to create a second preimage (thus collisions, and perhaps many): "When NOT to use (SpookyHash): if you have an opponent. This is not cryptographic. Given a message, a resourceful opponent could write a tool that would produce a modified message with the same hash as the original message". In general, to guard against DoS attacks in a hash table application, it can help to use a secret, random seed or prefix chosen at initialization of the table; it is not perfect, though: there might be e.g. timing attacks able to detect collisions, and then find new ones. |
|
Mar 26 |
comment |
Solving hard problems in $\mathbb Z_{p}^{*}$ when $\mathbb p$ is close to $\mathbb 2^{n}$ Edited the answer. Changed $n$ to $N$ as approriate (implicitly $N\approx2^n$), except $2^n$ remains unchanged and $c\ge n^{1/d}$ became $c>2^{n/d}$; feel free to revert. |
|
Mar 26 |
comment |
Is it feasible to break Diffie-Hellman key exchange when the implementation uses a poor-quality PRNG? @HenrickHellström: the initialization for the default RNG was improved, and is now using seedUniquifier() ^ System.nanoTime(); search for that. |
|
Mar 26 |
comment |
What is the probability of breaking the AES algorithm? There would be practical attacks against reduced-round AES; e.g. this, claiming an attack against 4 rounds with 4 chosen plaintext using $2^{32}$ effort and moderate memory. Theoretical attacks exist for more rounds, e.g this. Difficulty of attack increases "quickly" with the number of rounds, but it is hard to quantitatively characterize. |
|
Mar 25 |
comment |
Solving hard problems in $\mathbb Z_{p}^{*}$ when $\mathbb p$ is close to $\mathbb 2^{n}$ Very related to this other question |
|
Mar 24 |
comment |
Even passwords are vulnerable to hash collision attacks? @Smit Johnth: Yes, rainbow tables and password search by enumeration qualify as first-preimage attacks: they start from a hash, and try to find a value that hash to that; most usually, that's using brute-force. |
|
Mar 23 |
comment |
How to efficiently generate a stream of independent, but biased random bits? @Poncho: indeed the algorithm as given in your answer is FP-friendly, and my "improvement" is not one; on the contrary: 2*bias-1 is more (not less, as I mistakenly thought) numerically stable than bias+(bias-1) is. Oups! Fixed my alternative. |
|
Mar 21 |
comment |
Cracking an RSA with no padding and very small e Further, the last attack has a simple extension working for short $m$ slightly wider than $n^{1/e}$; we are given $c=m^e\bmod n$ and can find by enumeration $k$ such that $k⋅n+c$ is an $e$th power; then $m=(k⋅n+c)^{1/e}$. |
|
Mar 21 |
comment |
How to calculate y value from ((y*y) mod prime) efficiently Try this |
|
Mar 20 |
comment |
Sensible usecase for restricting special characters in passwords? The traditional reason to prevent special characters in passwords is that sometime the password might need to be entered on a device/context (e.g. physical terminal, bootloader) different from the one where the password is defined on (e.g. some full-blown GUI), and special characters might be difficult or impossible to key in the former environment. Users of AZERTY keyboards often learn the hard way it is safer to choose passwords that key-in identically on a QWERTY keyboard. ^ is especially problematic, for it is a dead key on only some keyboards. This really belongs to security.se |
