SUD2 - Notifying other clients of the SUD2 methods supported
Posted: 30 Mar 2013, 16:34
I have realized that SUD2 is more composable than I expected and I think it would be cleaner to add a few INF fields so clients can know which methods can they use to speak between them without a need of updating the protocol version.
Basically SUD2 is composed of the following items: an obfuscation scheme (in the specification it is AES in CTR mode), an authenticated encryption with authenticated data scheme (in this case AES in SIV mode), if desired a compression scheme (in this case zlib), and also if desired a dictionary. I think than instead of just bumping the FOURCC version every time we need/want to update one of these, for example somebody may suggest we replace zlib with lzop or lz4 or come up with a better dictionary or even suggest using OFB mode when the patents expire, we should announce the supported schemes through INF fields so other clients can know and act in consequence.
As such I was thinking of the following named parameters:
SO: a coma separated list of the obfuscation modes supported by the client, 128 bit AES in CTR mode is number 0. In general we should avoid changing these as much as possible since each different obfuscation mode requires at least one decryption for key in order to know whether it is the correct one or not.
SE: a coma separated list of the authenticated encryption modes supported by the client, 128 bit AES in SIV mode is number 0.
SC: A field in the format mode,dictionary1, dictionary2,...:mode,dictionary1,dictionary2 ... (for example 0:1,1,2:2,3:5,1,2,4 would mean that mode 0 is supported (and no dictionaries can be used), 1 is supported with dictionaries 1 and 2, mode two is supported with the dictionary 3 and mode 5 is supported with the dictionaries 1,2 and 4) where mode 0 is no compression (where obviously no dictionaries are used) and mode 1 is DEFLATE (where 0 means no dictionary and 1 is the SUD2 dictionary). The dictionaries vary between compression modes, but in all of them the dictionary 0 is reserved to indicate no dictionary is needed.
Basically SUD2 is composed of the following items: an obfuscation scheme (in the specification it is AES in CTR mode), an authenticated encryption with authenticated data scheme (in this case AES in SIV mode), if desired a compression scheme (in this case zlib), and also if desired a dictionary. I think than instead of just bumping the FOURCC version every time we need/want to update one of these, for example somebody may suggest we replace zlib with lzop or lz4 or come up with a better dictionary or even suggest using OFB mode when the patents expire, we should announce the supported schemes through INF fields so other clients can know and act in consequence.
As such I was thinking of the following named parameters:
SO: a coma separated list of the obfuscation modes supported by the client, 128 bit AES in CTR mode is number 0. In general we should avoid changing these as much as possible since each different obfuscation mode requires at least one decryption for key in order to know whether it is the correct one or not.
SE: a coma separated list of the authenticated encryption modes supported by the client, 128 bit AES in SIV mode is number 0.
SC: A field in the format mode,dictionary1, dictionary2,...:mode,dictionary1,dictionary2 ... (for example 0:1,1,2:2,3:5,1,2,4 would mean that mode 0 is supported (and no dictionaries can be used), 1 is supported with dictionaries 1 and 2, mode two is supported with the dictionary 3 and mode 5 is supported with the dictionaries 1,2 and 4) where mode 0 is no compression (where obviously no dictionaries are used) and mode 1 is DEFLATE (where 0 means no dictionary and 1 is the SUD2 dictionary). The dictionaries vary between compression modes, but in all of them the dictionary 0 is reserved to indicate no dictionary is needed.