TurboMagic

Somebody found out, that DEC only compiled in XE7 or newer due to the use of new array syntax. Development branch contains a version now which should be fixed. I have no old Delphi installed, so this is not testest yet.

Somebody else found that out meanwhile as well and Development branch contains fixes for most known issues already. And yes I agreed: we shouldn't try to support every old Delphi version. I had rised this to D2009 with V6.0. I am not sure what the minimum version was before I took over. Maybe D5. I will raise it further in the future.

The compilation incompatibility issue was fixed with a new release 6.1.1 now: https://github.com/MHumm/DelphiEncryptionCompendium/releases/tag/V6.1.1 So users of older compilers may enjoy this library as well, but I'd still suggest to them to upgrade their Delphi version where possible to enjoy the benefits of newer Delphi versions... 😉

Hello, there is a new release 6.1 of DEC available . It is located here: https://github.com/MHumm/DelphiEncryptionCompendium/releases/tag/V6.1 WHat's new since V6.0? * x64 compilation works out of the box now, some unit had not been properly listed for x64 * fixed the following cipher algorithms which were broken on x64: Blowfish, RC6 and Q128 * the Sapphire cipher did work with the unit test vectors but failed for some others * added SHA2-224 hash algorithm * added HMAC and pbkdf2 algorithms * somebody provided a build batch file * there is a command line application included now for setting the IDE's library path * progress even got changed and a VCL demo for that one was added * version history is a separate document in docs folder now Cheers TurboMagic

Hello, this is the report of yes another bug a user has found (interestingly the unit tests for the cipher run flawlessly): Sapphire cipher didn't work properly for some data at least. The user thankfully did some investigation and I checked in his proposed fixes in the development branch. Note that the documentation got a small change: version history is a separate document now. So have fun using it TurboMagic

He didn't state what those files contain in terms of formatting or charts etc. Maybe the xls only contains values?

Sorry, but I have to report a few bugs/regressions which have crept into DEC: These led for the following cipher algorithms failing their unit tests on x64: Blowfish RC6 Q128 In addition there was a bug which prevented compilation on x64 completely. Good news is: these are all fixed and available in development branch on GitHub (see above link). Have a nice evening TurboMagic

In photo editors you usually have a histogram function which gives a distribution of the brightnes levels as a curve. With that you could find out whether more of the image is dark or bright. Most such photo editors can calculate this really quicky. So histogram might be a keyword to look for.

Hello, just a small note that I released a generic circular buffer library under open source license (Apache 2.0) here: https://github.com/MHumm/CircularBuffer Feel free to use it or to contribute to it. Cheers TubroMagic

Today I fixed a few bugs regarding use for storing objects in the buffer in the Remove and Delete methods and I fixed all memory leaks in the unit tests. The GitHub repository is up to date. Does anybody spot any bugs I have missed? Or is the source now "ok" so that the public should be "safe" when using it?

Hello, I do not have an Android 11 capable Android device yet but need to test some things on Android 11 (scoped storage). Now I had the idea to test in an emulator, even if that's quite slow. I started SDK manager to install an emulator image and set one up, but cannot find anything related to Android 11 there. SDK manager is version 25.2.5 and displays the list shown in the attachment. Android 11 is SDK level 30, but nowhere to be seen. How to get this?

Hello, since Android 10 we've got this nasty problem of no longer having direct file access to such folders like TPath.GetSharedDownloadsDir. Now I have managed via some intent call to either ACTION_OPEN_DOCUMENT or ACTION_GET_CONTENT to display some file chooser and when the user selects one I get the Uri of the selected file. With that I can get at an JInputStream and could read out the individual bytes of that stream. But: how to get at the file size properly to know when to stop reading? The Available method should, as per Android's documentation https://developer.android.com/reference/java/io/InputStream#available() rather not be used. Is there any "wraper" available which properly/nicely wrapt this in a TFileStream or something similar? A quick search didn't turn up anything yet. TurboMagic

I have a hard time with this as well, as my app up to now just lists all files with my specific suffix stored in downloads folder in a list view and the user can pick one. In addition if he selects one he gets 3 buttons on that entry shown. One for actually opening the file, one for displaying file meta data in a popup and one for sharing it. I'm not sure yet how I can replace all this in an Android 10/11 compatible way. For Android 10 I could use a compatibility setting in the manifest, but for Android 11 this is no longer allowed/doesn't do anything anymore and Android 11 compatibility support is as far as I know required some time in 2021 for Google Play distribution...

This might be an alternative: https://developer.android.com/reference/android/content/Intent#ACTION_OPEN_DOCUMENT

I'm not sure whether you can access this TPath.GetDocumentsPath folder in Android 10/11 anymore without issues. I tried to access TPath.GetSharedDownloadsPath which had worked up to now but throws an permission error of some sort on Android 10 even after requesting READ_EXTERNAL_STORAGE permission from user...

Have you made sure these files are in release config of 64 bit platform in deployment manager as well?

I'm currently storing binary files generated by my app or uploaded to the device by the user (e.g. via Windows Explorer) in the public downloads path returned by TPath.GetSharedDownloadsPath. Using such a path which is not within the installed app itself is only possible in Android 10 when requestLegavyExternalStorage is being declared in the AndroidManifest.template.xml. But that is a solution only viable when targeting Android 10, but not when targeting Android 11, which will be a requirement somewhere in 2021. Now I'm looking for possible alternatives which come as close to what I currently have as possible. I have written a dialog listing all the files of my file type and when the user taps one he gets options to open it, display file meta data in a popup or share it via share sheet. I'm a bit lost about which route to go. I don't think MediaFramework would be the right approach as my file type is no media file. I've seen this one: https://developer.android.com/training/data-storage/use-cases#handle-non-media-files startActivityForResult( Intent(Intent.ACTION_OPEN_DOCUMENT).apply { addCategory(Intent.CATEGORY_OPENABLE) type = "*/*" putExtra(Intent.EXTRA_MIME_TYPES, arrayOf( "application/pdf", // .pdf "application/vnd.oasis.opendocument.text", // .odt "text/plain" // .txt )) }, REQUEST_CODE ) But I'm not really sure what it does. Ok, it calls some activity to select a file, but since my file type is binary with some specific suffix I'd like to list only files with that suffix and the other thing is: what do I get back? How do I get at my file's contents? And the other issue is, that the same dialog s used for saving files as well. They might be saved in some app package specific directory if share sheet can work for that, but it still would be more cumbersome for users having the device directly connected via Windows Explorer. They most likely couldn't get at the file anymore. Any ideas?

I implemented this now and renamed Protect in CipherBase class to SecureErase for naming consistency.

That sounds sensible: move it to free as the other common option init should overwrite it. But I need to check this first. If init just frees and allocates memory nothing might be overwritten if the memory is not allocated at the same place. But you're right: if done, it should be done intelligently.

Another small info: I implemented your PBKDF2 implementation along with the unit tests meanwhile. I also toy with the idea to create a new descendend class from TDECHashBase where I move all KDF, MGF, HMAC and PBKDF2 implementations into and all other classes inherit from that one. That might introduce a new unit to keep the individual parts a bit shorter.

While coding I didn't see you already answered. As I'm finishing coding for now I made a note about your suggestion of a modified HMAC implementation which doesn't trigger overflows. And yes, turning of the checks should always be a last ressort! That's why I was asking. About your protect buffer points: I did sort of inherit this DEC library and thought it's too good to let it die, but I'm no really expert in these things. I learned quite a few things along already though. I will look at removing those, you might be right. I just didn't want to remove something not causing me real trouble from an inherited library when I don't completely understand the implications/effects this creates. That's also the thing with ReallocMemory. I never really understood its purpose and when I asked a few months ago in German DP because of some C++ Builder compatibility issues I didn't get really useful pointers why this might be used here. I only got some vague C++ Builder compatibility information as answers. So I left as is. But we can remove this as well. Just clearing the memory somehow at some point might reduce attack surface a bit. Yes, if the attacker can slow down that process well enough to be able to have enough time to read out memory while it runs that protection will not help. It just helps not having possibly sensible information lying around for longer than necessary.

I get a crash when implementing HMAC unit tests for your other test vectors! When performing the first test (using MD5) for long key/data test vectors from https://tools.ietf.org/html/rfc2202 I get a crash ERangeError on the first assignment in this part of the HMAC method: while I <= KeyLength - SizeOf(NativeUInt) do begin PNativeUInt(@InnerKeyPad[I])^ := PNativeUInt(@Result[I])^ xor CONST_UINT_OF_0x36; PNativeUInt(@OuterKeyPad[I])^ := PNativeUInt(@Result[I])^ xor CONST_UINT_OF_0x5C; Inc(I, SizeOf(NativeUInt)); end; The right hand side of the first assignment results, according to the debugger in this: 3906369333279686841 Size of native UInt in Win32 is 4 byte thus maximum number is this: 4294967296. Turning off range/index/ E/A compiler checking would fix this, but is this a good idea? If so I'd do this locally in the method. What's your opinion?

I implemented first unit tests for the HMAC implementation you contributed the basis for now and set the array length of the two internal arrays dynamically now. It's in the development branch. Further unit tests and implementation of your other code donation later.

Thanks for sharing this, but I don't see what this provides compared to what the other mentioned solutions here already provide.

I just implemented your HMAC code. It is in the development branch now. Unit tests still need to follow. If you look at my solution you can see how I was able to spare the hash class parameter...