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...

Hello, thanks for this implementation and your effort doing it! I have saved the stuff locally so I will include, this as soon as time permits, into the development branch in some form. I need to look at this HMAC stuff myself first (today I've got lack of time) and then decide where to put it. Your test will have to be changed into a DUnit test. And I would put your name Kas Ob. into the list of contributors contained in the project if you don't object. Thanks TurboMagic

Not sure, but the hash classes support KDF2. After fixing bugs even KDF1 and 3.

Another solution would be DEC: Delphi Encryption Compendium. Freely available in GitHub. https://github.com/MHumm/DelphiEncryptionCompendium Two FMX based demos are even in Google Play: DEC Cipher Demo and DEC Hash Demo. A Lite version containing the hashes only is in GetIt now as well. EMBT doesn't want Crypto there due to export rules...

Hello, here's a small Christmas present for you: There is a new release 6.0 of DEC - Delphi Encryption Compendium available, or put otherwise: DEC is back on track! 😉 The release can be found here: https://github.com/MHumm/DelphiEncry...eases/tag/V6.0 What is DEC? DEC is the Delphi Encryption Compendium open source library, a library containing cryptographic algorithms of the following categories: hash algorithms encryption algorithms key deviation functions CRC cryptographic pseudo random number generator format conversion classes What's new in V6.0 compared with the 5 year old V5.2 release? A complete list can be found in the last chapter of the included documentation. Supports D2009 - 10.4.1 Sydney Cross platform compatible if you turn off use of ASM in DECOptions.inc the hard to understand test program got reworked into unit tests test coverage got increased some bugfixes, like fixing the XTEA encryption algorithm or the included KDF2 turned out to be KDF1 instead implementation of the newest Whirlpool hash algorithm version implementation of KDF1, KDF2 and KDF3 key deviation algorithms changed unit structure to be more modular and better maintainable added some demo applications. The two FMX based ones are even available from Google Play (stemming from an earlier commit) added a 40+ A4 sized pages documentation most methods contain XMLDOC comments now So is it all over now, or are there plans for the future? Of course I know that this release didn't bring much new algorithms. But as far as my time allowes development shall continue (further project members are welcome!) I do have some plans for V6.1: Add the SHA224 hash, this is still missing Add SHA3 Add GCM block chaining mode for ciphers Add a first pasword hash algorithm, most likely bcrypt So much for today 😉 Cheers TurboMagic

By the way: a lite version of it is available via GetIt meanwhile. What's lite? The ciphers had to be removed due to export control regulations EMBT didn't want to mess around with... It contains all the rest: the hashes, CRCs, formattings and the random number generator

Sorry, no CPU acceleration yet. On x86 and at least in parts on x64 you can enable use of ASM for some of those which is notably faster than a Delphi only implementation.

So have you looked at my newest commit? Did you find any failure in it? I'm asking because I'm tempted to "do a release"...