Tag Info

New answers tagged

0

Sort-of, like the way you describe. $\:$ (It's still O(2n), as in previous case.) For encryption, one could have scrypt be involved, to reduce the leakage rate. For signatures, one could use a scheme in which each message has at most one valid signature, so that anyone who knows the public key and sees the output can potentially detect manipulation.


1

Below is one possibility, but for a large set of values not a really efficient one as the work and the size is linear in the number of values. Say we are working in a cyclic multiplicative group $G$ of prime order $p$ with generators $g$ and $h$ (such that the discrete logarithm between $g$ and $h$ is unknown to the users) and I assume that the values on ...


6

Some brief thoughts: Shared secret Generation: $$s=E_a(B)=E_b(A)$$ The shared secret is generated by encrypting the other users public key with your private key. This is effectively an ECDH step, which is very reasonable, and one of the key aims of C25519$^{[1]}$. Key Generation: $$s_0=\mathrm{SHA256}(s); s_i=\mathrm{SHA256}(s_{i-1})$$ First, using the ...


2

It's actually somewhat simpler than I'd thought, since I don't think it would help much to usually be able to avoid contacting the tracker. Each time a (registered) client joins the Torrent, they establish a secure channel for their communication with the tracker in that session. The tracker informs the downloader and uploader of the other's IP address and ...


4

The current specification says that tracker GET requests specify the following variables: uploaded=... (bytes) downloaded=... (bytes) left=... (bytes) This is great for public trackers but is poorly designed for private trackers. The problem is that the numbers don't always add up as they should and this can be for several reasons. For example, you might ...


1

Moxie Marlinspike calls it in his article http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/ the doom principle: if you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom. He also demonstrates two attacks which are possible because of trying to ...


0

One of the major advantages of GCM is the authenticated data input that you can pass. Think about headers of a message that you want authenticated but not encrypted. This is a great thing to have in many practical implementations where some data has to stay in clear but manipulating it by an attacker has serious consequences.


2

Unless you are absolutely sure that you don't need to and that the cost is going to be significant then I would absolutely say you should use authenticated encryption. One reason is bit-flipping attacks - flipping a few bits at the 'right' point in your encrypted message might lead well to a message that is legal (the classic example is if someone learns ...


1

Your approach makes getting information other than count of cards in possession of each player at least as hard as breaking the PRFness of HMAC. To make it information-theoretically impossible "for all the ... each player", $\;\;$ if different card_values have different lengths then use $\;\;$ SHA256(commonly_agreed_public_salt:card_value) $\;\;$ ...


0

What about SRP? It has an additional property, that you do not need to keep the shared secret unprotected on the server. http://srp.stanford.edu/design.html You did not specify if you want to restrict the number of roundtrips, but I guess with SRP they can be minimized.


0

No one is stopping you from running the polynomial setup yourself. Knowledge of the polynomial is equivalent to knowing the actual secret. And knowledge of the complete polynomial is required to evaluate the polynomial at any point. But this doesn't have to be a third party; it might be the case that your particular context uses a third party for this task, ...


6

We simply have to trust this party because this scheme requires a trusted setup. We can use verifiable secret sharing, that allows the parties to check whether the shares they have obtained are consistent. If we do not want to have a trusted dealer who sets up the shares at all, we have to switch to dealer-free secret sharing schemes. See for instance, ...


0

It depends on the situation. The third party can be a computer in a datacenter with armed guards at the door. Or it can be an employee who doesn't want to screw up and be fired. Or other things. Of course, none of those solutions are 100% foolproof, and it would be better to have a protocol which doesn't use a trusted third party, but if no such protocol is ...


3

If they don't trust the server they sure shouldn't send any money. The "trusted" third party is used to solve the problem of participants who don't trust each other. So by definition, your problem can only be somewhat mitigated, not solved completely. I'm not sure what you mean by "provably fair". If the server can't prove he cannot cheat, it's not provably ...


1

You are looking for secure coin flipping protocols. See the following: How to fairly select a random number for a game without trusting a third party? Verify product without revealing multipliers Proof that lottery does not know outcome of draw A fair peer-based coin-flipping protocol? Is this scheme a provably fair random number generation?


3

You're close with the idea of using an envelope; the standard answer is to use a commitment scheme; this is a scheme where someone can publish a 'commitment' to a value, and then later revealing what that value was. The two essential properties of commitments are: Someone just looking at the commitment cannot tell what the secret was Someone with the ...



Top 50 recent answers are included