10,847 reputation
12455
bio website github.com/CodesInChaos
location Frankfurt, Germany
age
visits member for 3 years, 8 months
seen 11 hours ago

Mar
21
comment Coding of unsigned int to prevent guessing next ID
Either use a 32 bit blockcipher like Skip32 or use proper format preserving encryption (tricky to implement).
Mar
21
comment Are factorization algorithms parallelizable?
@fkraiem I consider the efficiency of factoring algorithms on-topic for crypto.se.
Mar
21
comment Are factorization algorithms parallelizable?
1) don't use BBS 2) The standard factoring algorithm is the number field sieve. There exists a variant called Batch NFS which at least in theory reduces the average cost for factoring if you attack multiple moduli. But I don't know if it leads to a practical improvement for typical key sizes. I'm also not sure to which degree it can be parallelized.
Mar
21
comment Security of simple Skein PBKDF mentioned in the paper
It's not memory hard and is comparable to PBKDF2. Scrypt and bcrypt are still better.
Mar
21
comment Is it safe to prefix the a key with a known value?
Since HMAC exhibits weird behaviour with variable length keys, I wouldn't really count it as an exception.
Mar
20
comment RC4 , Is it possible to find the key if we know the plaintext and ciphertext?
Only if you use many related keys.
Mar
20
comment How can ECDSA signatures be shortened (to be used as a product key)?
Perhaps they implemented BLS signatures. They only produce 2*n bit signatures for n bits of security, compared with 4*n bit signatures with ECDSA. There are also variants of Schnorr/DSA signatures that only produce 3*n bit signatures.
Mar
20
comment ECDSA for encryption
@chrisdew A hybrid system is the way to go with ECC. The alternative is EC-ElGamal and that's clearly an inferior choice. The overhead for ECIES with AES-GCM over a 256 bit curve is 48 bytes, 32 for the ephemeral public key and 16 for the MAC. Or you could simply use NaCl's Box operation, which is conceptually very similar to ECIES.
Mar
19
comment ECDSA for encryption
ECIES (or something similar) is the way to go. I don't see why AES based authenticated encryption wouldn't be a good fit. Of course reusing a key for encryption and signing is a bit of a risk, but IMO it's an acceptable one.
Mar
16
comment What is the most light-weight symmetric cipher thats still usefull?
What's your CPU? How much RAM and ROM do you have? How many CPU cycles can you afford for each byte of the message?
Mar
16
comment RSA Decryption from samples
See Dan Boneh - Twenty Years of Attacks on the RSA Cryptosystem Section 4.2 Hastad's Broadcast Attack.
Mar
16
comment RSA Decryption from samples
What's the public exponent? If e=3 decryption is simple (see Watson's answer). If e is bigger than the number of copies, this attack shouldn't work. But lack of proper padding (preferably OAEP) is still a very bad idea.
Mar
16
comment Reusing a one-time pad?
Since ARM Cortex M0 is a 32 bit processor and supports addition, rotation and xor, it should even be able to efficiently run ChaCha (possibly reduced to 8 or 12 rounds).
Mar
16
comment Reusing a one-time pad?
@Muis Which cipher is cheapest depends on the hardware. I expect RC4 to be reasonably fast on most small CPUs, as long as you can afford the RAM to keep its state. It also has a relatively expensive key setup, especially if you drop the first 1000 bytes (which I strongly recommend), but that doesn't matter for a large file.
Mar
16
comment Reusing a one-time pad?
The OP is suggesting something similar to a Vigenère encryption, not Caesar.
Mar
16
comment Reusing a one-time pad?
If you don't need a lot of security, you could try RC4. It shouldn't need a lot of CPU, but it needs about 300 bytes of RAM for its state. Drop the first 1000 or so bytes of output to avoid the worst biases. There is also a whole field of lightweight cryptography, but I'm can't recommend any particular algorithm.
Mar
16
comment Reusing a one-time pad?
"I have an embedded device."
Mar
15
comment Does “cryptography rather [try] to minimize the expansion of ciphertext”?
I know no advantage, apart from leaking less information about the length of the plaintext -- and that effect can easily be accomplished by padding the plaintext before encryption.
Mar
14
comment Block cipher mode with diffusion on ciphertext
But trying to use this as a MAC doesn't work - for example truncation attacks are trivial in a known-plaintext scenario.
Mar
13
comment Block cipher mode with diffusion on ciphertext
Why do you need this property?