2,926 reputation
1518
bio website
location United States
age
visits member for 2 years, 5 months
seen 37 mins ago

Apr
2
comment Encrypting the same message using different schemes
Recall that the keys are independent. $\;$
Apr
1
revised Does changing the random number selected for each message increase security in Schnorr's scheme?
fixed grammar
Apr
1
comment Decrypt AES-128 with key file but missing IV?
Oh, I didn't notice the CBC mode part. $\:$ The all-zero IV would be a workable "default", such as if the key was only used once. $\;\;\;\;$
Apr
1
comment Decrypt AES-128 with key file but missing IV?
Try ECB mode, and then try the all-zero IV. $\;$
Apr
1
comment Generating a number using SHA512 that users can later verify (once I publish secret seed)
@kape123 : $\;\;\;$ Depending on how much money is involved, it might be feasible-enough for you to find a different seed that would generate the same first 4 numbers but subsequently give different numbers. $\:$ Getting more numbers would presumably allow the client to guess the secret seed from the examples more easily, since one should heuristically expect that the seed is uniquely determined by the given numbers. $\:$ Even with 10^10 numbers, I doubt there's a known remotely feasible way for the client to find secret seed. $\;\;\;$
Apr
1
comment Generating a number using SHA512 that users can later verify (once I publish secret seed)
@kape123 : $\;\;\;$ Using it with the method you've posted to verify numbers does not confirm that you haven't manipulated numbers. $\:$ For example, you could choose secret seed after seeing the first client string to make the first generated number be essentially whatever you want. $\:$ By considering the result of fixing a search algorithm's randomness to its optimal value, one can see that, even after choosing all 10 server and client values and seeing their results, the probability of guessing the secret seed is at most (10001^10)/(2^512). $\;\;\;\;\;\;$
Mar
31
comment Can a commutative block cipher be indistinguishable from a random permutation, for fixed key?
There could conceivably be a commutative block cipher whose outputs for a given key on an entry-wise unpredictable list of inputs are indistinguishable from being independently-and-uniformly distributed. $\hspace{.42 in}$
Mar
31
revised Operation sequence authentication shared storage
provided some details for the top part
Mar
31
answered Operation sequence authentication shared storage
Mar
31
comment Attack of an RSA signature scheme using PKCS#1 v1.5 encryption padding
I think it would be more interesting to ask about attacks that are easier than factoring the modulus, $\hspace{.4 in}$ even if they are harder than factoring the private key. $\;$
Mar
31
comment Expand 1-n Oblivious Transfer to retreave only an item I, for which permissions exist
One could use Oblivious Signature-Based Envelopes. $\;$
Mar
30
comment Using the same private key for two ECC key pairs
@CodesInChaos : $\:$ Only insofar as a PRF qualifies as "some kind of hash". $\;\;\;\;$
Mar
30
revised Using the same private key for two ECC key pairs
fixed grammar
Mar
29
comment Generating shared secret random permutation
If you use a field with 2^n elements, then you can split value into two halves arbitrarily (or swap left and right halves). $\:$ If you use a field with 2^n elements and directly split value, then there's no point in using a mask, since you would already have the two halves $\:$ If you use a field with p elements, then you should split value according to how it was chosen (as I mentioned in my previous comment), although you can swap left and right halves. $\;\;\;\;$
Mar
29
comment Generating shared secret random permutation
If you use a field with 2^n elements, then n must be at least the lengths of the card_values, and if it is then the observers' ability to get information from a particular pair of hashes will be at most 3*(2^((254-n)/3)). $\:$ If you use a field with p elements and the card_values are L bits long and you choose left_half and right_half uniformly from {0,1,2,3,...,p-1} rather than as random bit strings, then the observers' ability to get information from a particular pair of hashes will be less than (3*(2^((255-[number of bits in p])/3)))+((2^(L-1))/p). $\;\;\;\;$
Mar
28
comment Generating shared secret random permutation
Yes, that really is enough, one can google paper's about that general idea. $\:$ However, if one wants to reduce the amount of per-card randomness needed at the cost of increasing the amount of reusable randomness needed, then you can get that by using slightly more complicated extractors. $\:$ (Namely, you split the value into more pieces and multiply some or all of them by different parts of the seed.) $\:$ I'll figure out what size of finite field you should use when I get back to my computer much later today. $\;\;\;\;$
Mar
28
comment Generating shared secret random permutation
One can heuristically expect using a cryptographic hash function to also work. $\:$ I have no clue which is more efficient. $\:$ You can also replace "over a finite field" with "modulo a prime". $\:$ (The chooser can test primality with Miller-Rabin, and no one else needs to care about whether the modulus is actually prime.) $\;\;\;\;$
Mar
28
comment Cryptographic system with double keys with reversible order
Actually, does commutativity survive inserting either of those padding schemes? $\;$
Mar
28
revised Generating shared secret random permutation
simplified one block
Mar
28
comment Generating shared secret random permutation
In my previous comment, "a truncation" should be replaced with "the least significant bits". $\hspace{.89 in}$