Proof isn't always possible

I can remember suggesting a theoretical Operating System that requires object code to be compiled in such a way that a decryption key is required for a program object to execute. The program object itself would execute unencrypted in RAM.  I cannot find the entry at the moment, but I have also suggested an OS that uses an RSA key for program installation. Separately, I have contemplated a Linux user, organized such that the encrypted home folder appeared as an UNMOUNTED container over IP, while operating as a MOUNTED container locally, for the profile user. This would defeat some purposes of SSH, but would harden the installation against data theft over IP.  Now, with the development of an offline username/password for a program, I am asking myself if I cannot effectively suggest a practical (as opposed to theoretical) arrangement, whereby the program presents a credential (or two - username/password) to the OS, for permission to execute. Clearly, multiple program objects w...

We log in online and are accustomed to being refused service if we supply an incorrect username/password combination.  We persecute "plain-text offenders" and rightly expect to benefit from comparing a hash fingerprint of the credential presented online to a list of hash fingerprints, each paired with a username. Even better if the username is hashed as well. The knowledge gained from online handshakes can benefit us in digital rights management.  It has long been the case that we could obfuscate a password literal in source code by compiling it into object code. However, decompilers provide assembler code that can reconstruct the source code without descriptive variable names and make string values stand out. Now, we can construct a creative solution. We can designate a username/password combination to COMPILE SOURCE UNIQUELY FOR EACH USER. To hide it in the object code, we hash the username and password with a published hash algorithm and use the hash-fingerprint literal in...

 The cloud is not secure for entry-level users.   My personal security has been pwnd, leaving open questions about my competency, by criminal hackers who employ their creativity to enable malice and occasionally spite, such as revenge porn.  This blog once reflected the language "with grim determination," alluding to my motives for implementing Erasthmus's sieve on an odd number line. Now it says "mad cap experiment," instead. I cannot even correct an error on blogger dot com once published. Caching takes over and the update never populates. But in a new development, my book "The Devil's Hangover," has been updated for me. When I first wrote it, I had the original bad guys named "Rurek" and "Harold York." However, this reflects offline preparatory drafts, and the only cloud interaction it might have seen was as a zip file to my Google Drive as a backup. At the time of publishing, I labored to correct every occurrence of Rurek th...

There are a finite number of compression algorithms. One strategy is to catalog differences in consecutive values and compress a dictionary of the differences. A simple experiment to perform in Rust or C++20, is as follows. 1. Read the file as an array of unsigned int (16 bits each.) To do this, it is important to understand encoding. I avoid Microsoft's Unicode encoding. An alternative is to read the file in 8-bit bytes, and concatenate every two-byte pair into an array of unsigned int. The numeric value represented is not the purpose. Declare a large enough array space in RAM to accommodate some max_size value. 2. delta_encode the array. There is standardized code to do this. Python3 has a function in module numpy. 3. Golomb-encode the resulting dictionary or array. There is standardized code to do this. This falls into the category of run-length encoding. Viewing pixels from a raw photo format or an mp3 as unsigned int is the innovation suggested.   4. Write the result in a file...

Red Pill; White Hat; Blue Team! Source Code uses only printable characters. Unicode provides for fonts, control codes and many other bells and whistles. However, Unicode does not expand the vocabulary of source code. As such, source code that is tampered with control codes introduced to the text file or the editor (by a bad actor or automaton,) can be scrubbed by a format stripper. One notable "virus," introduces hidden control codes to combine the direction the processor "parses," from left to right v right to left. Based upon a foundation of tampering direction codes, the file or editor is directed to corrupt the program logic by tampering indentation. This is of less concern with c++20 and other semi-colon delimited languages, but Black Hat has devised improvements, inspired by success against Python using the older method. The strategy to compile a source-code scrubber would be to read the file in 8-bit bytes, assessing which are ASCII and which are not. Only a ...

 If I want to certify object code but don't want to share the source, ONE idea would be to provide an interpretive script that duplicates it. Encryption would be an example. My idea was: if I can write C++ code that decrypts text enciphered by my python3 implementation, that would certify it while capitalizing on faster execution, yet defeating efforts to brute force cryptograms.  Specifically in encryption, the rule is: nothing secret except the message and the password. Ethically, derived key material represents a grey area. If I use a C++ object from an unknown source, and this object decrypts what Python has enciphered AND Python decrypts what the object has enciphered, then the object is valid - as long as I check EVERY message. A back door treats some passwords (or messages) differently. As a learned rule, this helps me think more clearly about it.