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

Refactoring of modules and updating of documentation #197

Closed
mahmudsudo opened this issue Jan 29, 2025 · 6 comments
Closed

Refactoring of modules and updating of documentation #197

mahmudsudo opened this issue Jan 29, 2025 · 6 comments
Assignees
Labels
priority-high 🔥 High priority tasks structure 🧱 Structure refactors or changes tech debt 🏗️ Technical debt and cleanup tasks

Comments

@mahmudsudo
Copy link
Contributor

The present documentation does not fully cover the codebase and some modules need refactoring

@Autoparallel
Copy link
Contributor

@mahmudsudo want to get assigned?

If so, can you present a bit of a plan for specifics you want to accomplish?

Agreed on this direction though! Thanks for making the issue 👍

@Autoparallel Autoparallel added priority-high 🔥 High priority tasks structure 🧱 Structure refactors or changes tech debt 🏗️ Technical debt and cleanup tasks labels Jan 29, 2025
@mahmudsudo
Copy link
Contributor Author

/// Core encryption trait that defines basic encryption/decryption operations
pub trait Encryption {
    /// The key type used by this encryption algorithm
    type Key;
    /// The error type returned by encryption operations
    type Error;

    /// Encrypt data using the provided key
    fn encrypt(&self, key: &Self::Key, data: &[u8]) -> Result<Vec<u8>, Self::Error>;
    
    /// Decrypt data using the provided key
    fn decrypt(&self, key: &Self::Key, data: &[u8]) -> Result<Vec<u8>, Self::Error>;
}

/// Trait for block ciphers specifically
pub trait BlockCipher: Encryption {
    /// The block size in bytes
    const BLOCK_SIZE: usize;
    
    /// Encrypt a single block
    fn encrypt_block(&self, key: &Self::Key, block: &[u8; Self::BLOCK_SIZE]) -> Result<[u8; Self::BLOCK_SIZE], Self::Error>;
    
    /// Decrypt a single block
    fn decrypt_block(&self, key: &Self::Key, block: &[u8; Self::BLOCK_SIZE]) -> Result<[u8; Self::BLOCK_SIZE], Self::Error>;
}

/// Trait for stream ciphers
pub trait StreamCipher: Encryption {
    /// The nonce type used by this cipher
    type Nonce;
    
    /// Initialize cipher state with key and nonce
    fn init(&mut self, key: &Self::Key, nonce: &Self::Nonce) -> Result<(), Self::Error>;
    
    /// Process data stream
    fn process(&mut self, data: &[u8]) -> Result<Vec<u8>, Self::Error>;
}

so aes and others would implement all these seperately:

pub struct Aes256 {
    // Internal state
}

impl Encryption for Aes256 {
    type Key = [u8; 32];  // 256-bit key
    type Error = AesError;

    fn encrypt(&self, key: &Self::Key, data: &[u8]) -> Result<Vec<u8>, Self::Error> {
        // Implement padding and block mode handling
    }

    fn decrypt(&self, key: &Self::Key, data: &[u8]) -> Result<Vec<u8>, Self::Error> {
        // Implement padding and block mode handling
    }
}

@Autoparallel
Copy link
Contributor

Autoparallel commented Jan 29, 2025

Do you think we need to have the StreamCipher and BlockCipher traits? What if we just had associated types for the Encryption trait such as this:

pub trait Encryption {
    /// The key type used by this encryption algorithm
    type Key;
    /// The error type returned by encryption operations
    type Error;
    /// The data that is input into this scheme for encryption (e.g., blocks, streams, etc.)
    type Plaintext;
    /// The encrypted form of the data
    type Ciphertext;

    /// Encrypt data using the provided key
    fn encrypt(&self, key: &Self::Key, data: &Self::Plaintext) -> Result<Self::Ciphertext, Self::Error>;
    
    /// Decrypt data using the provided key
    fn decrypt(&self, key: &Self::Key, data: &Self::Ciphertext) -> Result<Self::Plaintext, Self::Error>;
}

In the case of symmetric encryption, you fundamentally have an equality of these types Plaintext === Ciphertext but in asymmetric encryption, you won't. So this interface would allow for a single trait that handles more cases. Is there anything that doesn't fit in?

What do you think?

Potentially as well you could imply that the self contains the key. Then we'd have:

    /// Encrypt data using the provided key
    fn encrypt(&self, data: &Self::Plaintext) -> Result<Self::Ciphertext, Self::Error>;
    
    /// Decrypt data using the provided key
    fn decrypt(&self, data: &Self::Ciphertext) -> Result<Self::Plaintext, Self::Error>;

@mahmudsudo
Copy link
Contributor Author

Nice , would take this approach

@Autoparallel
Copy link
Contributor

It's all yours sudo :)

@mahmudsudo
Copy link
Contributor Author

mahmudsudo commented Jan 30, 2025

i took this approach :

/// Core encryption trait that defines basic encryption/decryption operations
pub trait Encryption {
    /// The key type used by this encryption algorithm
    type Key;
    /// The error type returned by encryption operations
    type Error;
    /// The data that is input into this scheme for encryption
    type Plaintext;
    /// The encrypted form of the data
    type Ciphertext;

    /// Create a new instance with the given key
    fn new(key: Self::Key) -> Result<Self, Self::Error> 
    where Self: Sized;

    /// Encrypt data
    fn encrypt(&self, data: &Self::Plaintext) -> Result<Self::Ciphertext, Self::Error>;
    
    /// Decrypt data
    fn decrypt(&self, data: &Self::Ciphertext) -> Result<Self::Plaintext, Self::Error>;
}


is it something satisfactory or do i need to tweak a little bit

All optional functions on both stream and block ciphers would be added to their specific impl bodies , instead of having 3 traits , we now have one general trait

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority-high 🔥 High priority tasks structure 🧱 Structure refactors or changes tech debt 🏗️ Technical debt and cleanup tasks
Projects
None yet
Development

No branches or pull requests

3 participants