Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

V6 - Proper/safe MAC usage (in contrast to digital signatures) #2310

Open
randomstuff opened this issue Nov 6, 2024 · 4 comments
Open

V6 - Proper/safe MAC usage (in contrast to digital signatures) #2310

randomstuff opened this issue Nov 6, 2024 · 4 comments
Assignees
Labels
2) Awaiting response Awaiting a response from the original poster AppendixV Appendix with crypto details V6 _5.0 - prep This needs to be addressed to prepare 5.0

Comments

@randomstuff
Copy link
Contributor

Should there be a requirement about the proper usage of MAC (in contrast to digital signatures). In particular, if there are more than two participants, MAC is usually not safe.

See for example Differences between Digital Signatures and MACs in the JWS RFC (emphasis mine):

Both signatures and MACs provide for integrity checking -- verifying that the message has not been modified since the integrity value was computed. However, MACs provide for origination identification only under specific circumstances. It can normally be assumed that a private key used for a signature is only in the hands of a single entity (although perhaps a distributed entity, in the case of replicated servers); however, a MAC key needs to be in the hands of all the entities that use it for integrity computation and checking. Validation of a MAC only provides corroboration that the message was generated by one of the parties that knows the symmetric MAC key. This means that origination can only be determined if a MAC key is known only to two entities and the recipient knows that it did not create the message. MAC validation cannot be used to prove origination to a third party.

Note: another problematic scenario mentioned here is when a MAC-ed message send from A to B could be sent again from B to A.

@randomstuff randomstuff changed the title V6 - Proper MAC (in contrast to digital signatures) V6 - Proper/safe MAC usage (in contrast to digital signatures) Nov 6, 2024
@danielcuthbert danielcuthbert self-assigned this Nov 7, 2024
@tghosth tghosth added 1) Discussion ongoing Issue is opened and assigned but no clear proposal yet _5.0 - prep This needs to be addressed to prepare 5.0 V6 labels Nov 7, 2024
@randomstuff
Copy link
Contributor Author

As discussed in #2375, this may not be for V6.

@tghosth
Copy link
Collaborator

tghosth commented Nov 20, 2024

@randomstuff please can you confirm whether this should be tagged as V6 or as AppendixV Appendix with crypto details .

@tghosth tghosth added 2) Awaiting response Awaiting a response from the original poster AppendixV Appendix with crypto details and removed 1) Discussion ongoing Issue is opened and assigned but no clear proposal yet labels Nov 20, 2024
@randomstuff
Copy link
Contributor Author

This would be for V6.

The basic idea boils down to "beware of sharing the same authentication shared secret with more than two parties, maybe you should use digital signatures instead": if more than two parties (A, B, C) share the shared secret, A can spoof B on C or C on B.

Question: Is this useful to include this?

Question: How wan we formulate a requirement about this?

@tghosth
Copy link
Collaborator

tghosth commented Nov 22, 2024

This feels a little too into the weeds of system implementation detail...

I feel like once we start getting into specific implementation principles it opens up a can of worms

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2) Awaiting response Awaiting a response from the original poster AppendixV Appendix with crypto details V6 _5.0 - prep This needs to be addressed to prepare 5.0
Projects
None yet
Development

No branches or pull requests

3 participants