Add new option to use \Defuse\Crypto\Key as encryption key #812 #814

[SunMar]

Update documentation with changes in #814 (also see #812).

Is there a way I can see the end result of the changes? I was able to view the .md formatting but some things are custom so I couldn't verify how it's going to look on the web page.

[Sephster]

@SunMar I think we could use the included script /vendor/bin/generate-defuse-key here. I haven't tested it but I believe something like the following would suffice:

vendor/bin/generate-defuse-key > "mykey.txt"

It would be good to state Mac/Linux/Windows derivations of this if possible but I think this method would be easier than the one that is currently listed.

[Sephster]

I think this change can probably be left out. This file is for the version 5 security improvements. I also don't think the Key file is necessarily a security improvement, just a more efficient method. Thanks

[Sephster]

Thanks for this @SunMar - I've merged in the main changes. Would it be possible you update this branch and modify the notes I've made? Once this has been done I will get this merged in too and get a version 7.1 released. Many thanks.

[SunMar]

@Sephster I've updated the branch. What I'm not sure however about is the text for generating a string password, from the previous documentation I've left this command:

php -r 'echo base64_encode(random_bytes(32)), PHP_EOL;'

However the funny thing is, because random_bytes(32) is used this actually already is a secure key, it's not a potentially unsafe password. If you generate a "password" like that, it's much better to use the Key object and eliminate the performance hit. But I don't really know what to write there or what kind of use case you'd have with an "unknown" password.

What I guess my suggestion would be is to completely remove the string part from the documentation and just tell people use generate a secure Key instead. That the code also accepts a string for backwards compatibility can then be added as minor note instead.

What do you think?

[Sephster]

I see what you mean @SunMar - I think that we should leave the string information in for now as the way we have suggested generating a password is more a recommendation than a requirement. People might not have used this method to generate their password.

I've updated the text to say that the password might be of varying strength which I think will cover us. I will merge this in and we will get it out in the next release which should hopefully be this weekend!

Thanks for making the changes and adding this feature.

[Sephster]

Sorry, I will merge this in when the new release is put out :)