18:56 <kisspunch> Hey, I was looking for feedback on a hand-rolled MAC method. It's closely based on the traditional one-time mac. My mac is: (A&message)^B. It has one known major drawback--the change of one bit of message results in the change of at most one bit of MAC. Other than that, are there additional gotchas, like can parts of the message be shuffled or cloned?

18:58 <copumpkin> curious, why? is it for educational purposes or are you trying to use this in an adversarial setting? :P

19:03 <kisspunch> Some of both. This is one extreme in block size, and I might genuinely want to use small blocks. Small blocks could be done by hand in the context of authenticating one-time-pads. The traditional linear algebra MAC can't be done by hand and can't be understood by the layman. Bits can be understood by the layman, small blocks maybe maybe not.. For now I'm using the traditional MAC but it's the least transparent part of a cryptosy

19:03 <kisspunch> stem and I'd like the whole thing to be transparent.

19:05 <sipa> i can't immediately see what's wrong with it, but if it isn't, i'm curious why one-time MACs like poly1305 etc are so much more complicated

19:06 <kisspunch> The one-time MAC is a specific operation, (ax+b) mod P. Short writeup here, also on the wikipedia page about MAC. http://web.mit.edu/6.857/OldStuff/Fall97/lectures/lecture3.pdf

19:07 <kisspunch> The one-time MAC requires 2N pre-exchanged bits to authenticate N bits, which is why it's not used much

19:07 <kisspunch> It's related to the one-time pad in that way (also in that the bits can be used once), thus the name

19:11 <sipa> i'm still trying to adapt to this one-timeness model of the keys

19:11 <sipa> why would (message^A) not work?

19:11 <kisspunch> message = plaintext ^ C is the encryption

19:11 <sipa> yes, but why would it not work as a MAC?

19:12 <sipa> what's security game?

19:13 <kisspunch> One-time-pads doesn't work against known-plaintext. Suppose you know plaintext. Then you replace (plaintext^C) by (bad^C) by xor-ing together: (plaintext^C) and (plaintext^bad)

19:16 <sipa> with your scheme you can change any single bit of the message, and have a 50% chance of it being valid with the input MAC

19:17 <kisspunch> yes, that's a big drawback, but i know that issue.

19:17 <sipa> doesn't that break usual security expectations?

19:18 <kisspunch> well it means i probably shouldn't call it a MAC, yes. but i'd like to know if there are additional issues

19:19 <kisspunch> i was imagining you could mitigate that issue through some other redesign, but there may be more issues

19:21 <kisspunch> i agree it's a huge weakening

19:25 <kisspunch> for example, if you appended a 160-bit hash to the ciphertext before MAC, you'd still get 160-bit resistance against guessing MACs

19:26 <kisspunch> but yes mostly this is intellectual curiosity about how broken this modification is, the original system seems a lot better

19:31 <kisspunch> the general reason to be interested in one-time MAC, since I didn't mention, is that there are no computational assumptions or attacks--it's not possible to break with a supercomputer

19:32 <kisspunch> so a version you could do by hand would have some obvious appeal to me at least