I threw in Win32 API-based Base64 encoder & decoder wrappers for the benchmark. However, the library is cross-platform.
The numbers in the image are with C++ optimizations turned on. However, even with optimizations turned off MODP_B64 runs circles around Win32 and my earlier implementation.
EDIT: Hmm, very slow, also fails to decode the text from LOREM_IPSUM. Very odd. Never had any problems before and it worked with other Base64 strings that I had in the past. Was also a direct copy of a Rosetta task, so the algorithm might not be good. It fails on the "b4" line of the decode$ function.
2nd EDIT: Nice. If I dig up my Win32 version, it is super fast on my PC.
Samuel's algo:
Win32:
Code: (Select All)
Option_Explicit
Const ITERATIONS = 100000
Const LOREM_IPSUM = "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum."
Dim encTxt AsString, decTxt AsString, i AsLong, t AsDouble
Below are some benchmarks. I've included the benchmark code in libbase64.zip\demos\base64\base64_demi.bas. Find the final zip in the first post. Cheers!
A quarter of a century ago I wrote my own encryption for office data. It worked great but by today's standards would be considered obsolete. My question is how involved would this be using this new QB64 encryption function to get even something simple like a password encrypted?
How would I encrypt that with this new feature so, unlike the example in the wiki, someone can't just decode it with _BASE64DECODE$? I would think there should be a key involved.
A quarter of a century ago I wrote my own encryption for office data. It worked great but by today's standards would be considered obsolete. My question is how involved would this be using this new QB64 encryption function to get even something simple like a password encrypted?
How would I encrypt that with this new feature so, unlike the example in the wiki, someone can't just decode it with _BASE64DECODE$? I would think there should be a key involved.
A quarter of a century ago I wrote my own encryption for office data. It worked great but by today's standards would be considered obsolete. My question is how involved would this be using this new QB64 encryption function to get even something simple like a password encrypted?
How would I encrypt that with this new feature so, unlike the example in the wiki, someone can't just decode it with _BASE64DECODE$? I would think there should be a key involved.
Pete
Well, you should not use _BASE64ENCODE$ or even _DEFLATE$ for encrypting sensitive data because these are not encryption methods. Anyone can trivially reverse them using _BASE64DECODE$ and _INFLATE$.
_MD5$, _ADLER32, and _CRC32 are not encryption but hashing/checksum functions and the results are not reversible.
As you rightly pointed out, you would need something that takes a key and then encrypts the data using the key. To reverse the process and get back the original data, you would have to use the same key. I think something like AES should do the job quite well.
I'll try to put together something over the weekend.