21,565 reputation
12990
bio website
location Paris, France
age
visits member for 3 years, 3 months
seen 10 hours ago

I'm an engineer with experience in applied cryptography, in particular in Smart Card systems.


1d
comment Small Encryption Exponent
@codeomnitrix: the assignment in this question was intended to be solvable in one iteration of the Fermat factoring method; that is, the simple 4 steps in this answer. That may be worth trying in your case (especially if there is any hint that the factors are very close, or mention of the method); and perhaps the full Fermat factoring.
1d
revised simulating rc4-256 with rc4-128
added 4 characters in body
1d
comment what are multi-primes and how are they different from semiprimes?
The patent, and more generally history of multi-prime RSA, are described in this question
2d
answered simulating rc4-256 with rc4-128
2d
comment Less known hash functions producing 128 bit hash
Have you tried RIPEMD and RIPEMD-128? They where not in the reference that you give as at the time you posted. Also, truncation of wider hashes are common. And a MAC with hard-coded key is common, and indistinguishable from a custom hash, even with a reverse-engineering of the code.
2d
comment Building a pad for OTP on-the-fly with Diffie-Hellman
@Guut Boy: I was thinking of OTP with XOR, which is usually implied; and DH in $\mathbb Z_p^*$, again a default assumption. $\;$ I do agree that for $a$ random and chosen independently of $b$, and $g$ a generator of a suitable multiplicative group, $(g^a)^b$ is computationally indistinguishable from random.
2d
awarded  Nice Answer
2d
comment Building a pad for OTP on-the-fly with Diffie-Hellman
@Guut Boy: The question states "protocol would be as hard as breaking DH (discrete logarithm)", which is wrong even if we ignore the minor issue that breaking the DH problem might be easier than breaking the discrete logarithm problem. The issue is that reference to "discrete logarithm" makes it clear "DH" means the DH problem, not the DH protocol (because there is no discrete logarithm protocol). And the proposed protocol (as well as the DH protocol) is trivially broken by MiTM, when the DH problem is not.
2d
comment Inverse of a function $f_k(x) := f (x ⊕ k) ⊕ k$
@user3646249: bijective means that any element of the destination set has exactly one way to be reached; that's at most one way for injective, and at least one way for surjective. A bijection is a bijective function, an injection is an injective function, a surjection is a surjective function.
2d
comment Building a pad for OTP on-the-fly with Diffie-Hellman
@Guut Boy: when working modulus $p$, the $j$-th high bit of the outcome of DH key exchange has a bias, in the order of $2^{-j}$; so you need to ignore enough high bits (or use a post-processing like a hash) in order to get practical security even if you do not consider MiTM attacks. $\;$ And of course neither DH, nor the proposed system, is secure against MiTM attacks. $\;$ (Notice the use of @ so that you are notified of the comment).
2d
comment Decrypt with only the cipher file and the key?
This falls straight against our "Requests for analyzing or deciphering a block of data are off-topic here" policy. That said: the ciphertext is so redundant (with mostly ASCII, and over-proportion of digits and uppercase) that you can practically rule out that any modern, standard, secure cipher was used. Good luck if you have no more context or examples (multiple Wireshark captures, if they are different, could help you).
2d
comment Efficient proof of knowledge using Wegman-Carter hash
@Ricky Demer: I guess you are suggesting that the challenge is (the seed of) some random prime $N$, and the response $M\bmod N$. That seems to works with odds of forgery $2^{-\log_2(N)}$ if $N<log_2(m)\log_2(\log(m))$ where $m$ is the bit size of $M$, or something on that tune; but I doubt this can be made computationally competitive. Using a smooth $N$ can be more efficient (by using the CRT) but is less secure, because an adversary might pre-compute $M$ modulo small primes, then discard $M$.
2d
comment Feistel network output if round function is the identity function
A function $f$ is the identity function when for all $x$, it holds that $f(x)$ is $x$. $\;$ In a (symmetric) Feistel cipher, the data block is split in left and right halves $L_0$ and $R_0$, and it is computed $R_{j+1}:=L_j$ and $L_{j+1}:=R_j\oplus f(L_j)$ where $f$ is the round function (depending on authors, within swap of $L$ and $R$, and perhaps a variation on last or first round).
2d
comment Feistel network output if round function is the identity function
Hint: write down what (L1,R1), (L2,R2), (L3,R3) are, using the properties of XOR, sometime used to swap the content of two memory locations without using a temporary.
2d
comment Inverse of a function $f_k(x) := f (x ⊕ k) ⊕ k$
Welcome to crypto.SE! I hope that I correctly used $\TeX$ to format your question (click edit to see how that's done). $\;$ Hint: is what's asked always possible? Consider the case what $f(x)$ is zero for all $x$. Now, assume you know $f_k(x)$ and $k$, have access to $f$ or $f^{-1}$, and want $x$.
2d
revised Inverse of a function $f_k(x) := f (x ⊕ k) ⊕ k$
TeXify
2d
asked Efficient proof of knowledge using Wegman-Carter hash
2d
comment Large file validation on an embedded system through hash and encryption
Can you elaborate on what you trust, and do not trust, on the embedded system? In particular is there some part of the code/data that the adversary is assumed unable to modify? To read? $\;$ Independently: can you program the system at the CPU level, or are you bound to using built-in primitives (as you would be if you could only define bytecode for a virtual machine)? Is MD5 fast enough for your purpose, or do you want something even faster (that seems possible with a Wegman-Carter hash)? And if not, is the bottleneck MD5, or reading the data?
2d
comment Large file validation on an embedded system through hash and encryption
@McMurrich: what you described in above comment is a simple hash tree. As pointed by Richie Frame, it will not detect alteration of a block that was not supposed to have changed, but did (with no change of the stored hash, remaining at its former, original value, no longer matching the file content). I can't tell if that's a problem in your threat model: on one hand you trust the embedded system (when it accesses the data and compute hashes), and on the other you do not (when it comes to not changing this data).
Nov
23
comment Compact digital signature for noisy data
Yes. But unless I miss something, if we use a conventional hash, it seems the verifier will need the exact same message as the prover in order to produce (or check) the hash; thus the scheme won't be more efficient than the "generic but inefficient construction" given, I'm afraid.