The mix minion paper briefly mentioned that they require a block cypher to be secure in both directions, but yeah I suppose most block cyphers have this property.
I suppose the actual property is f_k(g_k(x)) = x and h_k(f_k(x)) = x with g_k and f_x being secure encodings, so that f_k can be used in both directions. Lionnes is nice because g_k is h_k, maybe that's always the situation. On Wed, 2015-11-11 at 19:06 -0500, Ian Goldberg wrote: > I'd have to think about whether you even *could* construct the header > with a block cipher. The construction in Figures 1 and 2 of the > above paper relies on the XOR underlying the stream cipher in order > to get the nested MACs to work out. As I understand it, there is not necessarily a need for MACs if you're using a large block cypher, provide the message integrity checks are good enough. I suspect a large block cypher cannot be used though, not just due to the MACs, but due to constructing the padding. There is however another approach that appears to work : Invent a one-sided large block cypher by block chaining regular block cyphers of the size of one hop's information. We want the property that alterations to cypertext create uncontrolled changes to all plaintext before the alteration, or after if we reverse the orientation of the Sphinx header. If an attacker modifies the header, then any address containing or before the modified bit decrypts as scrabbled. We need not MAC the header for this variant, but then we depend upon the addressing information itself being a good enough integrity check. I believe that depends upon further higher level properties of the mixnet, so presumably this breaks provable security in the UC model. It reduces flexibility though too by tying the amount decrypted per hop to the cypher block size. It does however save the 16 bytes per hop spent on MACs. > What Sphinx needs from Lioness is a "large block" block cipher. > You can implement that however you like, but Lioness was a > straightforward construction. I suppose one could use a stream cypher if one knew the plain text was MACed, but again this presumably violates the UC model. Jeff
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
