| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 1 year, 9 months |
| seen | Apr 24 at 2:36 | |
| stats | profile views | 29 |
|
Jan 24 |
comment |
Why is MixColumns omitted from the last round of AES? @PaŭloEbermann Yes, but you need a separate set of precomputed table just for the final round. This is onerous in environments where memory is tight. |
|
Jul 29 |
comment |
Can I jettison MAC if I already have SHA1(M)? @D.W. I'm not sure why I would care about perturbing the ciphertext if the underlying message is immutable; padding attacks rely on being able to change the message (in order to decrypt it based on padding-validity rules). Anyway, thanks for your input. |
|
Jul 29 |
comment |
Can I jettison MAC if I already have SHA1(M)? @D.W. My assertion that adversarial messages will (almost certainly) be rejected is based on the assumption that any perturbation to a string whose SHA1-digest is fixed-and-known is effectively immutable. Gave you give an example where this is false (choose any padding scheme you like). |
|
Jul 24 |
comment |
Can I jettison MAC if I already have SHA1(M)? It's standard in CCA security to give the adversary a decryption oracle (that's what every definition of CCA security does, that I've seen). You of course don't give the adversary credit for decrypting a message he's encrypted with the corresponding encryption oracle. (en.wikipedia.org/wiki/…) |
|
Jul 22 |
comment |
Can I jettison MAC if I already have SHA1(M)? Yeah, I know the padding attacks well. |
|
Jul 21 |
comment |
Can I jettison MAC if I already have SHA1(M)? Thanks for the reply. Your "secure" above works even without encryption(!). My intent was to preserve privacy even in some "reasonable" attack model, meaning the adversary cannot decrypt C=E_K(M) even with access to a decryption oracle and subject to the usual complexity-theoretic limits. |
|
Jul 21 |
comment |
Can I jettison MAC if I already have SHA1(M)? I thought about padding oracles, by the way, but any adversarial message is overwhelmingly likely to just be rejected (the same effect a MAC would cause). Another concern is extension attacks, but I think I've ruled those out as well. |
|
Jul 21 |
comment |
Can I jettison MAC if I already have SHA1(M)? Thanks. Actually in my application there is a digest for every 4MiB, so the resend-problem isn't a problem. I wrote my question in a simplified form to focus on the essential issue. |
|
Jun 7 |
comment |
Is there a simple hash function that one can compute without a computer? The 6k$\pm$1 rule doesn't help much: every integer is between -2 and 3 mod 6. Half of these are even and therefore obviously composite; one is an odd divisible by 3, which is quickly found out. The last 2 satisfy the 6k$\pm$1 rule, so it tells you nothing further. |
|
May 15 |
comment |
Exposing RSA private-key data… bad? The $d$ is the RSA private exponent. Have a look at any exposition on RSA encryption for more details. |
|
Feb 22 |
comment |
Exposing RSA private-key data… bad? Thanks. I had never seen this attack on $n$ when we know $e$ and $d$. |
|
Feb 22 |
comment |
Exposing RSA private-key data… bad? Can you explain how you arrived at this (nice) solution? What was the motivation? |
|
Nov 29 |
comment |
Why is MixColumns omitted from the last round of AES? Thanks for your response, PulpSpy. However, my question is not so much about security implications, but rather "how does omissions of MixColumns make the inverse cipher similar to the cipher?" and "how does this help in implementing the cipher?" For the latter, I have always found it a pain to implement this special-case in AES where you have to omit MixColumns in the final round: for example, you can't use the precomputed tables. |
|
Nov 27 |
comment |
What is pre-image resistance, and how can the lack thereof be exploited? @PaŭloEbermann Moving to chat. |
|
Nov 26 |
comment |
What is pre-image resistance, and how can the lack thereof be exploited? @PaŭloEbermann: Normally public-inputs are given a priori then we (want to) say there is no efficient algorithm to compute a desired output. You cannot say that here since the algorithm is to simply output a correct preimage. When you have a block cipher (for example), the public inputs are the cipher and any pt/ct pairs. But the key is not public, so any algorithm that attacks the block cipher (usually the cipher's semantic security) must actually query its oracle(s) and produce a distinguisher. This cannot be efficiently done for good block ciphers. |
|
Nov 12 |
comment |
What is pre-image resistance, and how can the lack thereof be exploited? @PaŭloEbermann The essence of the problem is this: given a hash function $h$ (which has NO KEY!) and a digest $d=h(m)$, the hash function is "preimage resistant" iff there exists no efficient algorithm that outputs a preimage of $d$ under $h$. But this is silly! Of course there is an algorithm: Output m; works. The point is this: there is no hidden information for an algorithm to try and extract, so how can we define "hard" here? We don't have this problem with keyed algorithms like block-ciphers or public-key schemes... they are keyed. |
|
Nov 12 |
comment |
What is pre-image resistance, and how can the lack thereof be exploited? @PaŭloEbermann Rogaway is talking about collision resistance because it's the "weakest" notion of security for hash functions that people care about. In other words, collision resistance implies preimage resistance (I'm being informal here; Rogaway-Shrimpton formalizes all this). |
|
Nov 12 |
comment |
What is pre-image resistance, and how can the lack thereof be exploited? @PaŭloEbermann Your added comment addresses the issue, but it's not quite right. I'm afraid it would take more space than this comment box to point out why this (subtle) issue is difficult. If you're interested, see the introduction in Rogaway's paper on this topic (cs.ucdavis.edu/~rogaway/papers/ignorance.pdf). |
|
Nov 12 |
comment |
What is pre-image resistance, and how can the lack thereof be exploited? It's important to note that none of the answers you get will be "definitions" of Preimage Resistance. That's because it doesn't have a good one for a given hash function (you can define it on families of hash functions, but I doubt anyone here will do that). |
|
Oct 17 |
comment |
Does AES have any fixed-points? By the way, finding a fixed-point in AES-128 is equivalent to inverting one round of Davies-Meyer built on AES; showing how to do this efficiently would be a startling result. |