1,978 reputation
417
bio website touset.org
location San Francisco, CA
age 30
visits member for 1 year, 6 months
seen 8 hours ago

Cyclist. Rubyist.


Apr
1
comment Generating a number using SHA512 that users can later verify (once I publish secret seed)
If your requirement is not to leak the PRNG seed, then you must use a CSPRNG. Use an existing one, and not one your own invention. If you have an additional requirement that your seeds must be shown to have been chosen in such a way that the results were not manipulated, then use a commitment scheme such as described above and publish your commitment in advance.
Apr
1
comment Generating a number using SHA512 that users can later verify (once I publish secret seed)
You've also said in multiple places that you want to prove that you haven't manipulated the RNG results. Since you're only generating numbers between 1 and 100, that's quite difficult. Just as an example, it took me less than one second to find a random seed in Ruby that resulted in the "random" numbers 1, 2, 3, out of a max of 100. Without some kind of commitment scheme, users simply cannot be assured that you haven't manipulated the results.
Apr
1
answered Generating a number using SHA512 that users can later verify (once I publish secret seed)
Apr
1
comment Generating a number using SHA512 that users can later verify (once I publish secret seed)
@kape123 Any time you combine cryptographic primitives, you are in dangerous territory. How many random numbers do you intend to generate within a period where you publish the seed? If only a few, there's literally nothing you can do to satisfy your requirements — it would be trivial to brute-force guess a seed with any algorithm until it gave you some sequence of numbers you desired. So there would be no way to demonstrate to a consumer that you didn't intentionally influence.
Mar
31
comment Generating a number using SHA512 that users can later verify (once I publish secret seed)
@e-sushi Also: correct way to map random number to defined range?
Mar
31
comment Generating a number using SHA512 that users can later verify (once I publish secret seed)
You are incorrect; you don't need to do it this way (which seems problematic; trivially, you're dividing $2^{32}$ possible values into 100 buckets, and this cannot happen with equal probability). Your requirements seem to be that the RNG is deterministic (based on a seed) and unpredictable (without the seed).
Mar
31
comment Generating a number using SHA512 that users can later verify (once I publish secret seed)
Please don't try and create your own CSPRNG. Use an existing off-the-shelf one, like RNGCryptoServiceProvider.
Mar
31
comment Is there a point using GCM block chiper with Authenticated DH?
As @figlesquidge mentions, CTR is actually extremely susceptible to bit-flips. A bit flipped in a CTR ciphertext flips the bit at the same location in the plaintext. This is because the CTR construction is (put simply) $c = E(k, n \vert\vert c) \oplus m$ where $n$ is the nonce and $c$ is the block counter.
Mar
31
comment Is there a point using GCM block chiper with Authenticated DH?
It's a common misconception that modified ciphertexts produce garbage when decrypted. This is highly dependent upon the mode of encryption, and flipping bits in many commonly-used modes (e.g., CBC, CTR) has well-defined and predictable effects on the plaintext, even if the plaintext itself is unknown to the attacker.
Mar
28
comment Is Encryption without knowing the input directly possible at all?
To Ricky's point, there's no way for Alice to prove this outside of involving the other parties in the computation. Fundamentally, Alice can always write down each $t_i,E(pk_j,t_i)$ pair on a sheet of paper.
Mar
28
comment Perl DES PCBC as protection against decryption/crypt analysis
But the problem with trying to protect against "future cryptanalysis methods" is that we fundamentally have no idea what they will be. Modern ciphers protect against all of the threats we know about (and hopefully many we don't); if there was something simple to do that cryptographers believed would increase security against attackers for the next 100 years, it would already be baked in.
Mar
28
comment Perl DES PCBC as protection against decryption/crypt analysis
As I mention in my common on Richie's post, PCBC does not have the property you think it does. If any two consecutive blocks are known, given a break in the underlying algorithm, an attacker would recover the XOR or the corresponding plaintexts. You appear to want an all-or-nothing transform.
Mar
28
comment Perl DES PCBC as protection against decryption/crypt analysis
Given two consecutive ciphertext blocks $c_{i}, c_{i+1}$ a break of the cipher would allow the attacker to recover $p_{i} \oplus p_{i+1}$ which more or less means the (remaining) plaintext is still recoverable.
Mar
28
comment Perl DES PCBC as protection against decryption/crypt analysis
If there was any published analysis demonstrating that such a use of PCBC would somehow turn a broken cipher into a secure one, that knowledge would already be incorporated into modern algorithms. You are attempting what amounts to cryptographic voodoo, and I don't think you'll find much support for it here. The common refrain is: GPG for data at rest, TLS for data in motion.
Mar
27
comment Perl DES PCBC as protection against decryption/crypt analysis
Using strong, modern encryption algorithms defeats cryptanalysis. If the algorithms we had today couldn't withstand cryptanalysis, we would replace them!
Mar
27
comment Perl DES PCBC as protection against decryption/crypt analysis
It's strong encryption that makes ciphertext difficult to turn into a plaintext. I'm not sure what advantage you think error propagation gives you.
Mar
27
comment Perl DES PCBC as protection against decryption/crypt analysis
First off, DES should be considered utterly broken for all modern purposes. The keys are trivially brute-forceable given computing power nowadays.
Mar
25
comment Is PBKDF2-HMAC-SHA1 really broken?
On the PHC mailing list, it was also realized recently that because the password in PBKDF2 takes the place of the key HMAC parameter (rather than the message), passwords also collide when they have trailing ASCII NULs on the end (ex. "password", "password\0", "password\0\0", etc.).
Mar
22
comment No of keys used in Triple DES Algorithm
I'm not sure what you mean by "security perception". One long key and three short keys (whose sum of lengths are the same as the length of the long key) are completely interchangeable.
Mar
22
answered No of keys used in Triple DES Algorithm