dkushche/crypto

Crypto's a learning project that contains the realization of all my university cryptology labs.

Hi there, I am Dimka

About me

• 👨‍🔬 I'm a Master of Science in Cybersecurity.

• 🥼 I'm currently working on the private kuberenetes lab hosted in Yggdrasil network and accessed using Alfis domain.

• More about me:

  • 
  • 

GitHub Stats

crypto's Issues

Update documentation

It's deprecated, we need to deal with it.

Processing function shouldn't contain UI calls

The processing function should be able to be used by other software. This software won't need to init interface which is part of crypto UI, so all cterm calls shouldn't be in the processing function.

Example:

def cryptoapi_aes_processing(data, key_length, key,
                            mode, provider, encrypt):

    if platform.system() != "Windows":
        return f"Unsupported on your platform {platform.system()}"

    cryptoapi_aes_pre_processing(key, key_length)

    if provider == "standard":
        result = crypto_native.ms_cryptoapi_standard_aes(
            data, key, encrypt
        )
    else:
        result = crypto_native.ms_cryptoapi_nextgen_aes(
            data, key, mode, encrypt
        )

    crypto_tools.cterm("output", f"Hashed key: {result['hashed_key']}", "inf")
    crypto_tools.cterm("output", f"Session key: {result['session_key']}", "inf")

    return result["result"]

If I try to import cryptoapy_aes and call just its processor I will get an Exception because the color palette for cterm is not defined.

Investigate output coloring libs to make Crypto look pretty on windows

Help padding drifted

How to reproduce:

• Install crypto
• Run crypto
• Run help command

How I want it to look like:

dsa                         ->              dsa_little_doc
dummy_rsa                   ->              dummy_rsa it's super dummy rsa for easier analysis
elgamal                     ->              encrypt/decrypt using elgamal algo
elliptic                    ->              encrypt/decrypt using elliptic algo
generate_ca                 ->              generate_ca_little_doc
generate_client_cert        ->              generate_client_cert_little_doc
hash                        ->             generate hash from data

How it looks now:

dsa                         ->              dsa_little_doc
dummy_rsa                   ->              dummy_rsa it's super dummy rsa for easier analysis
elgamal                     ->              encrypt/decrypt using elgamal algo
elliptic                    ->              encrypt/decrypt using elliptic algo
generate_ca                 ->              generate_ca_little_doc
generate_client_cert   ->              generate_client_cert_little_doc
hash                        ->             generate hash from data

Hint: issue in crypto_commands/help.py

Generate CA: add the ability to have more than one CA

For now, when we generate CA it creates in crypto CA. It's not good for testing and can interfere with user workflow. Also during improving this module, we need to improve the issued cert and add the ability to choose CA.

Add module.processor for all modules

For now, not all modules have a defined processor function that could be used for running them without UI. Let's fix it.
Example:
This is good, it's how it should be:

caesar.little_doc = caesar_little_doc
caesar.full_doc = caesar_full_doc
caesar.processor = caesar_processing

This is bad and needs to be fixed:

diffie_hellman.little_doc = diffie_hellman_little_doc
diffie_hellman.full_doc = diffie_hellman_full_doc

Actually, this issue will be fixed after writing the test for all of the modules, but let's fix it now. I already improved modules creator to add processor automatically. So this issue won't happen in the future.

Get rid of the crypto native

It was a hack, but actually, it's looks bad and should be rewritten in clean python

Add typization for all processing functions

What we have now:
def issue_cert_processing(cert_info, cert_exts, username):

What I want to see(or something like this):
def issue_cert_processing(cert_info: list, cert_exts: list, username: string) -> None:

Add fancy dependency check mechanism

Sometimes we explicitly run the processor functions of modules we depend on, but for example, with issue cert, it doesn't happen and we have implicitly dependency which is bad and should be fixed and made explicit by some interface

Add 2 revokes 1 refund test for refund_cert

I added a basic test that check does the functionality works well, but we need more. On the list, let's create 2 certs, revoke both of them, and then refund one of them. As the result, you should get CRL with 1 cert inside of it.