# Tag Info

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, ...

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 ...

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 ...

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 ...

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 ...

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 ...

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

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 ...

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) $\;\;$ ...

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?

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 ...

Only top voted, non community-wiki answers of a minimum length are eligible