search

GaloisInc / cryptol-specs

A central repository for specifications of cryptographic algorithms in Cryptol
BSD 3-Clause "New" or "Revised" License
30 stars 6 forks source link

Module hierarchy is too deep #4

Open brianhuffman opened 5 years ago

brianhuffman commented 5 years ago

Our Cryptol spec for the AES block cipher is defined in a file buried four directory levels deep, with a full module name of Primitive::Symmetric::Cipher::Block::AES. This is ridiculous. The full module names are too long. It's hard to browse the collection to get an idea of what's in there. Users who want to copy a single spec from the collection for local use have to either change the module name in the file, or make four nested directories to put it in.

Also most of the subdirectory names are redundant: If something's a block cipher, of course it's a symmetric crypto primitive.

I propose that we should organize the code with only one level of directories. One directory for block ciphers, one for stream ciphers, one for hash functions, one for signature algorithms, etc.

atomb commented 5 years ago

To make this more specific, what about the following set of top-level directories:

This doesn't include block cipher modes that aren't authenticated (e.g. CTR, CBC, etc.). Should those go together with block ciphers? It also doesn't include the full public key encryption schemes such as OAEP or PKCS 1.5 used with RSA. Should those just go together with public key ciphers?

kiniry commented 5 years ago

I had originally built a hierarchy that conformed to the domain model we had written, which was wholly based upon the literature’s conceptualization of the domain of cryptography. I would hope that it isn’t “too deep” in some technical sense, since it is quite shallow from a conceptual sense.

Flattening can help with conceptualization, but really won’t solve the underlying issues we have with Cryptol’s module system.

Alternatives: I have sometimes used a sister directory with a flat filesystem soft linked structure. Alternatively, ls -R works for me.

On Mar 26, 2019, at 09:06, Aaron Tomb notifications@github.com wrote:

To make this more specific, what about the following set of top-level directories:

Widely-shared utility code (Common or Utils?), potentially destined for the prelude eventually? Block ciphers (BlockCipher?) Stream ciphers (StreamCipher?) Hash functions (Hash?) Authenticated encryption schemes (AuthEnc?) Public key signatures (Signature?) Public key encryption and key encapsulation (PKCipher?) Random number generators (Random?) Message authentication codes (shared key signatures) (MAC?) This doesn't include block cipher modes that aren't authenticated (e.g. CTR, CBC, etc.). Should those go together with block ciphers? It also doesn't include the full public key encryption schemes such as OAEP or PKCS 1.5 used with RSA. Should those just go together with public key ciphers?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/GaloisInc/cryptol-specs/issues/4#issuecomment-476721788, or mute the thread https://github.com/notifications/unsubscribe-auth/AAdOvx9orLo2A4g2BBNxUdbsHtSziehQks5vakV7gaJpZM4bXjKD.