Change IV

[EdAdvokat]

The literature describes that the initial vector (IV) should not be constant.
I have therefore changed the code so that the IV is also changed each time the key is changed.
I realized this with the help of a hash of the key in truncated length (12).
Then I set OnChange and OnTyping of the editKey.
I hope that I have communicated this correctly.

procedure TFormMain.EditInitVectorChange(Sender: TObject);
var InitV : string; //vom Key wird ein Hash genutzt, um den InitVector zu bestimmen (OnChange und OnTyping von editKey setzen)
begin
InitV := THashSHA2.GetHashString(EditKey.Text, THashSHA2.TSHA2Version.SHA224).ToLower;
EditInitVector.text:=Copy (InitV,0,12);
end;

[MHumm]

I'm not 100% sure yet what you want me to tell with this. Yes, IV shoudl always be anew one, that's something the samples don't really describe/convey yet. But what do you want me to tell with the code above? Is this a proposed modification of one of the samples?

[EdAdvokat]

I thought that every time the key input is changed, the IV also changes automatically.
the IV also changes automatically.
This was meant as a suggestion for Cipher_FMX.
Yes, you can also assume that the demo has no entry for the key and the IV and therefore
the user has to enter the key and IV himself.
However, if he then continues to work and only redefines the key, the IV always remains the same and
that should not be the case.
That was the idea behind my proposed change.

[MHumm]

Ok, somebody else has done some modifications of this demo and provided a new button to create some random IV. Would that be good enough for you so we can close this issue? I have now found out that the filler byte was meant for something else and thus the demo didn't really handle it well. I changed this. Commit is in the development branch.

[EdAdvokat]

In my proposal of 09.05.2024, I was concerned with preventing the IV from remaining unchanged.
The IV should not be used more than once.
I don't understand why the user is given the option of entering an IV in a separate field themselves
or even to forget to re-enter it.
I think this variant is wrong and error-prone.
The creation of the IV could be linked to the respective key generation, as I suggested.
If desired, the result can then also be displayed in a field.
Whether a hash function, as I suggested, or another option is chosen is irrelevant.
What remains important is the requirement that the IV should not remain the same.
I refer to Klaus Schmeh in “Kryptografie” 6th edition and other publications on IV on the Internet.
https://support.computop.com/hc/en-gb/articles/8473215477788-AES-encryption-What-is-the-sende-behind-the-Initialization-Vector-if-he-is-openly-transmitted

[MHumm]

Yes the IV should not remain the same. But there are scenarios where the key won't change but the IV should. Tying the IV to the key won't work for those. For instance if some application stores data in encrypted files, where the user never has to enter any key (as the file is fully managed by the application), the IV should be a different one each time a new encrypted file is generated but that IV might then be stored at the beginnign of the file. That would still be safe, as the key would be kept secret.

[EdAdvokat]

Let us note that the IV should not remain the same, nor should it be up to the user to change the IV or forget about it! The binding of the IV to the key input was just a suggestion of mine. Other possibilities are certainly also conceivable. For example, hashing via the plain text or whatever. My only concern is that the IV must not remain the same.

[MHumm]

I fully understand your concern!
As I see this this demo app should get further comments explaining things anyway.
I already made a mental note about that and try to find the time to add something to the IV as well!

[EdAdvokat]

It would also be conceivable to link IV formation to the creation time of the plain text

[EdAdvokat]

To supplement my previous comments, I would like to draw your attention to the technical guideline published by the BSI Kryptographische Verfahren: Recommendations and Key Length (as pdf file)

https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.pdf?__blob=publicationFile&v=10

hier especially pages 41 43 and 44 as well as section B2 on page 77 Generation of unpredictable initialization vectorsThis current document of the BSI describes the requirements for the formation of IV.

[MHumm]

While not being complete for all parts yet, I just improved and added comments for this demo. You might want to check if that's good enough for the IV now. I want to keep manual entering of the IV to keep the demo useful for comparing encrypted stuff encrypted using some different library.