d8-contrib-modules / encrypt Goto Github PK

Exceptions are thrown when no key exists or requirements for encryption are not met.

This shouldn't throw a PHP fatal. This should log a message and possibly throw a site message.

-Look at Key module for example

https://github.com/nerdstein/encrypt/blob/master/src/Controller/EncryptController.php

What is the purpose?

1. Move repo code
2. Remove Key functionality

While this is fairly standard, some PHP versions may not have this

-Should categorize to "security", like other modules (e.g. Password Policy). /admin/config/security/encryption for SettingsForm
-Need to expose the route from within the admin/config page

Default cannot be used as a key's machine name

When the user is presented with the list of available keys to use for encryption, it should be filtered so that only keys that match their encryption method are shown. As a first step, we can just filter by key type group ("encryption") and make further adjustments later to improve the behavior. Implementing this means that we will not be able to use the Key Select Form API element yet, since it's not currently possible to filter the key list by key type group.

https://github.com/nerdstein/encrypt/blob/master/help/encrypt.help.ini

Not sure this is to be used. Is this correct?

It is generally recommended not to use MCrypt in modern web applications and the implementation that currently exists in Encrypt is not secure, so we should remove the MCrypt encryption method from the module. Tests are using this method, so we will need to add some sort of method to the tests. I will create a separate issue for that.

Exception Warning McryptAES256Encry 47 Drupal\encrypt\Plugin\EncryptionMet
mcrypt_encrypt(): Key of size 17 not supported by this algorithm. Only keys
of sizes 16, 24 or 32 supportedmcrypt_encrypt('rijndael-256', 'test this
key out', 'S|9/>&Ysu', 'ecb', '')
Drupal\encrypt\Plugin\EncryptionMethod\McryptAES256Encryption->encrypt('S|9/>&Ysu',
'test this key out')
Drupal\encrypt\EncryptService->encrypt('S|9/_>&Ysu')
Drupal\encrypt\Tests\EncryptEncryptDecryptTest->testDefaultEncryptDecrypt()
Drupal\simpletest\TestBase->run(Array)
simpletest_script_run_one_test('1',
'Drupal\encrypt\Tests\EncryptEncryptDecryptTest')

Need to do two things:

1. Enforce key lengths for mcrypt via UI
2. Update tests to ensure the fake keys used are 16, 24, or 32 chars

Ties to Encryption entity. Entity should have settings. Settings should be pulled in from the EntityMethod plugin.

The encryption profile configuration entity should take advantage of the benefits of plugin collections by adding a plugin collection for the encryption method plugin type. Key already does this for its three plugin types, so the code can largely be copied from Key.

In this PR, OpenSSL / Defuse is mentioned and I second this motion. Has there been any effort to making this happen and what can I do to help?

I have standardized on using Real AES for D7 but as far as I know, there is no D8 port yet. This should be the recommended default for D8 Encrypt and not require a separate module.

We may want to wrap the test in if (!function_exists('mcrypt_encrypt')) {} and output a message that the php module isn't installed if it fails.

I dont understand why it's there

I've previously expressed the opinion that we shouldn't create a profile automatically when Encrypt is installed. I still think that's the case and I'd like to be clear about my arguments:

• Ideally, all encryption methods will be created by a submodule, so that site administrators can specifically choose what sorts of encryption methods are available on their site by enabling or disabling submodules. If there's an automatically-created profile, there will need to be a method that is always available, so it can be used for the profile, which prevents admins from having that control. They could alter the form, but that feels like a less desirable solution.
• Creating a profile automatically is likely to leave the profile in an unusable state, since it's possible that a default key will not have been set. The user still would need to go the Encrypt profile edit page and select a key. So why not just require them to create the profile themselves to begin with? It's not very helpful to have one created for you if it's not fully functional.
• It's important when dealing with something as critical as encryption that site administrators are aware of, and fully understand, every aspect of how their data is being encrypted, where the key is, etc. Each part of the process should be completely intentional and thought out. Having anything happen automatically undermines that goal.
• The Drupal 7 version of Encrypt has an automatically-created default profile, but it's only necessary to stay backward compatible with modules that originally integrated with Encrypt before profiles were introduced in version 2.0. Thankfully, we don't need to worry about that for the Drupal 8 version.

Can copy the current AES plugin and refactor AES

TBD

More info found here: https://docs.google.com/document/d/1cKWZbeHdDSMD4eOJeGp8lrJ-im0VtlWoM-hKv_LNteE/edit

1. Change encrypt settings UI to support creation of multiple instances (open to CMI)
2. Ability to set "default" global encryption instance for the service
3. Extend the service to be able to specify an instance and not just the default
   ->encryptWithInstance($inst, $string), ->decryptWithInstance($inst, $string)
4. Validate that machine names/IDs are unique to each encrypt service

LICENSE.txt gets added automatically by the Drupal.org packaging script, so it shouldn't be included in the Git repository.

https://github.com/nerdstein/encrypt/tree/master/includes

These look like D7 artifacts

See password policy code, which does this

https://github.com/nerdstein/encrypt/blob/master/help/key_providers.html

$->encrypt($text, $encryptionMethod, $keyType);

The "Basic" encryption method is being deprecated in the Drupal 7 version of Encrypt, and it does not need to be included at all in the Drupal 8 version.

Since Encrypt will not include any bundled encryption methods, we will need to have some sort of simple method for tests to use. It doesn't even need to actually involve encryption; it just needs to modify a plaintext value in a reversible way. I propose a basic Rot13 method, because it will fulfill that need and will be easy to write.

Doesn't look like there is much worth keeping in there.

There are two really important scenarios to consider.

1. If a key value changes
2. If a default key changes

Key is naive - it assumes someone knows how to invoke its service.

Encrypt is less naive - it references a key instance within it's Encryption Profiles. We may need to store or reference a specific revision of a Key entity.

We also should consider a "key change" service that decrypts a string with one Encryption Profile and encrypts the string with a second Encryption Profile.

Not needed

We are not going to be bundling any encryption methods with Encrypt (for more information, see #60), so the PHPSecLib method should be removed from the project.

Use case: mcrypt. Consider either separate plugin types or one plugin type with the settings below.

-Separate submodule of Encrypt
-mcrypt plugin type
-look at cyphers (aes, rjindal, blowfish)
-look at mode (cbc)

https://github.com/nerdstein/encrypt/blob/master/config/schema/encrypt.schema.yml

This will be replaced by entity

Ensure that Encryption method dependencies are met before they can be used. This should probably take place on the settings form when the item is selected or on the form validate.

Page just has a text field to encrypt and decrypt text. Let you easily test out your key and encryption method configuration.

The same would apply for the drush comand just without the UI drush encryption encrypt "Test" and drush encryption decrypt "avv9wervwen!d"

https://github.com/nerdstein/encrypt/blob/master/src/Form/EncryptAddConfigurationForm.php

1. Need to select a system key, remove key functionality in form
2. Needs to be a config form for entity, currently not
3. Need to integrate entity type settings, this is commented out from D7 version

I'd recommend removing this and refactoring.

https://github.com/nerdstein/encrypt/blob/master/src/Annotation/KeyProvider.php

-Create actual entity
-Remove database logic
-Integrate with Key entity / plugin system

Looks like a possible D7 artifact

https://github.com/nerdstein/encrypt/tree/master/tests/plugins/key_providers

https://github.com/nerdstein/encrypt/blob/master/config/install/encrypt.settings.yml

Refactor https://github.com/nerdstein/encrypt/tree/master/src/Tests

Drupal.org's packaging script automatically adds lines for project and datestamp, so they should be removed from our .info.yml files.

Lines 47 and 67 of https://github.com/nerdstein/encrypt/blob/master/src/Plugin/EncryptionMethod/McryptAES256Encryption.php

When I originally wrote the existing system for managing bundles of encryption settings, I used the label "configuration" to refer to them. Since that term has a specific meaning within Drupal 8, we should consider changing it to "profile."

https://github.com/nerdstein/encrypt/blob/master/encrypt.install

-File
-File Path

This then restricts the use of configuration based key types (e.g. SimpleKey) which are not advantageous for security