verify contents, but not order

Is there an algorithm that can be used to verify the contents of a cyphertext, but not the order of the elements?

I am thinking that a deck of cards could be shuffled, and it must be verifiable that the deck contains all cards, but not to know what order they are in.

Any ideas how to approach this problem?

-
Your question is a bit underspecified. Please add some detail. Perhaps you can simply sort the parts before hashing, perhaps you need some sort of homomorphic encryption, and perhaps it's impossible. –  CodesInChaos Aug 31 '12 at 21:43
I think he is basically asking for a zero knowledge proof that some ciphertext contains a permutation of some known set. –  Maeher Aug 31 '12 at 21:57
If Maeher is right, search for "Mental Poker" –  CodesInChaos Aug 31 '12 at 23:54
The problem is underspecified, but as asked, I'd answer this: Use an encryption scheme that maps each card to a number from 1 to 52. Ensure that all numbers from 1 to 52 are present, each once. Since you can't decrypt any of them, you have no idea what their order is. But since each of the 52 ciphertexts appears once, each of the 52 plaintexts must too. –  David Schwartz Sep 1 '12 at 9:41

As Maeher & Codesinchaos noted you're going to want to look into Zero Knowledge protocols. Matt Green at Hopkins wrote an easy to understand blog article that gives you one such example w.r.t. mental poker Poker is hard. Claude Crepau wrote a fair amount in the 80s and 90s about zk/mental poker; here is a link to one paper A zero-knowledge Poker protocol that achieves confidentiality of the...

Simari has a good primer on zk here:A Primer on Zero Knowledge Protocols

-
Great links, I am reading through them now. Although, I was hoping for an answer that was more efficient than mental poker, possibly with some other caveats that I don't mind too much about. –  Billy Moon Sep 5 '12 at 17:34

Well, the basic idea is to create or use an encryption scheme where, without knowing exactly what each encrypted thing is, you can count and identify unique records.

Take your playing cards. First off, without looking at any card's face, you can easily count them and verify that they at least came from the same style of deck. This is because each individual card is countable and identifiable as belonging to a deck of a particular style. In terms of data, you would get the data as elements of a list, delimited or otherwise divisible into individual elements, and those elements would have some sort of header you can use to identify the items as belonging to some unique set. However, you could be holding a Pinochle deck with 4 Jokers added, and not a Poker deck, and not know the difference. To be able to tell the difference, you have to know something about the values, without knowing the values.

There are two basic types of encryption that would allow you to accomplish this. One is a one-way hash; the values are translated, theoretically irreversibly, into a form that can be compared for equality but nothing else. If each hash is unique, you can be confident that the makeup of the deck is close enough to a Poker deck that it can be used as one. The other is a "block cipher"; the same key, plugged into the same algorithm, is used to transform each iterative piece of the plaintext into the ciphertext. Theoretically, without knowing the key, you can't discern the plaintext, but assuming that each card's value is encrypted in this way, each ciphertext should be unique; duplicate ciphertexts indicate duplicate plaintexts and thus duplicate cards. The actual ciphering scheme is irrelevant - you could use a Caesar cipher or AES - what's important is that each card's value is independently encrypted in exactly the same way, using no other information than one card's value, the key and the encryption scheme.

EDIT: The last thing you would have to prove is that, with all cards being unique, each one is a card you would expect to find in a poker deck (that is, there is no Zero of Spades). This is the tricky part, and IMHO you can't do it in a Zero-Knowledge way. you would have to know something about how the ciphertexts were encrypted in order to identify ciphertexts that were valid and ones that weren't.

-
You need to also verify that the contents are in a certain subset of values, e.g. 0 to 51. Else some ciphertexts might not represent valid values. –  CodesInChaos Sep 5 '12 at 10:56
This is close to what I am looking for - but there is a verification aspect to it also as mentioned by @CodesInChaos. –  Billy Moon Sep 5 '12 at 17:26
You would have to know whether a ciphertext is valid or not without knowing that a particular ciphertext represents a particular plaintext. If you used hashes, you could store known valid hashes (without storing plaintexts in parallel) and verify that every hash of the ciphered playing card values exists in the table of valid hashes. If they're encrypted, I can't think of a way to verify the ciphertext represents a valid value without knowing the secret information used to encrypt them (and thus knowing how the values were ciphered to determine the range of valid ciphertext values). –  KeithS Sep 5 '12 at 17:39

It is not clear what you are asking.

Maybe you are asking the following. You have a set of 52 ciphertexts, each of which is allegedly the encryption of a different card, and you want to check that these are an encryption of some permutation of the 52 possible cards (i.e., no card appears twice, every card appears at least once) -- in particular, as Maeher suggests, you want a zero-knowledge proof of this fact.

Is that what you are looking for? If yes, a standard solution would be to use a mixnet to randomly reshuffle-and-decrypt all of the ciphertexts, via standard techniques. Then (a) using zero-knowledge proofs, anyone can check that the mixnet was done correctly, and (b) by looking at the decryptions, anyone can check that what you have is a permutation of the 52 possible cards in a deck. Another approach, as CodesInChaos suggests, is to use standard "Mental Poker" protocols -- search for it, you'll find some research papers on the topic.

-
When zero-knowledge proofs can be used, why bother with a mixnet? $\:$ –  Ricky Demer Sep 1 '12 at 8:41
Either approach will work. Mixnets might be more efficient. Mixnets also might be easier to understand, depending upon what you find more intuitive. Or, they might not. It's just one more approach you could consider. (I don't immediately see any reason to think that one will be more of a "bother" than the other, or any reason to think that using zero-knowledge proofs would be inherently superior to mixnets, or vice versa.) And btw, many mixnet schemes do use zero-knowledge proofs internally. –  D.W. Sep 1 '12 at 18:22