This project deals with some ideas about strong(er) passwords.

With quantum computing so close (or already here...) the FUD sounding instant password cracking is growing. So given that material will continue to need to be protected, the issue of how to build effectively strong passwords goes up a few notches.

This is about risk management, not risk elimination.

So how do you work with the static variables you have to address an increasing risk. The static variable include the fact that 'people' have to use passwords of some sort, they have to remember them without creating holes like writing passwords onto scraps of paper etc.

You also need to recognize there are other probable risks such as keyloggers, other malware observing the process, Van Eck Freaking, code artifacts, and physical torchier. Not much I can do about the torcher stuff, but I'll give the rest a shot.

#!/bin/bash
# Script: noyb.sh
# Developer: William Ben Bellamy Jr. Copyright 2022
# Updated: 1/21/22 4:58 PM

# This is a prototype of a script that will pull binary material from a
#given file and then process that material for use as the encryption key
#for encrypting things. This is a loose mimicking of a one-time-pad. The
#point is to keep the file from which the password material is parsed
#unknown - it functions as a password in a similar way that the specific
#material on a specific page of a given book can be used as the key.

# Best practices would be to;
    # select a file with a relatively short path/filename.
    # keep a backup copy of the said file offline with a different name,
    # and even a different size.
    # Create a bogus 'lib' file that contains material from urandom, but
    # a valid header. This can be done with dd. This might make the file
    # standout under inspection, even with a valid header and keeping the
    # original filesize.
    # increase the number of blocks and/or the blocksize to use more
    # material. Change the blocksize and skip value.

# Question: would soft/hard links work? Are they even a good idea.

# Randomly select a binary system file. Randomly select start and end points
#within the file. Parse that substring of binary material.

# Select a binary system file. One that will always be there. Then select
#a start point and an end point of some length.

# Within the shell script prompt for the file path and name. This is not
#coded anywhere and takes the place of a traditional password.

# Note that the order is intended to keep material in memory for the shortest
#time possible.

# Hardcoded is the offset of the substring. Use dd to parse that substring
#and feed it to an encrypting tool as the encryption/decryption password.

echo Please enter your path/filename;
read FILENAME
#echo The filename is ${FILENAME}

# An issue is that these vars are in RAM and could be sniffed by another
#process or something. So, rather than simply hope that this material is
#not sniffed, I am going to try to use hashing to make sure that only it
#is in RAM. The deeper issue is that you need the filename, its offset in
#order to generate the material that will be used as the encryption key.
#So, all of the material used by this script needs to be protected so
#that it cannot be recovered or captured. There is always the issue of
#keyloggers. But, this is all about risk management, not risk elimination.

# This prototype is to demonstrate the technique. I suspect that this
#would be done better with C++, if I knew that language (and yes, I am
#ashamed I do not know it...) where you could have more control over
#memory. You would have to then rely on libraries that do what the
#external tools do here.

# Things to consider;
    # Consider adding a decrypt option
    # Consider repeat encryption or hashing using the same key
    # Consider an option to srm the unencrypted version

# Slice a block of 512 from the file
# Production line: MATERIAL=$(dd if=${FILENAME} bs=512 skip=16 count=1)

# Using sed to remove the last 3 characters leaving only hex values
MATERIAL=$(dd if=${FILENAME} bs=512 skip=16 count=1 status=none| /
    sha512sum | sed -r 's/.{3}$//')
# export the var so it is available to openssl shortly
export MATERIAL
#echo The MATERIAL is;
#echo ${MATERIAL};echo

# Purge the FILENAME value as soon as it has been used
# Overwrite the var with random material. Then unset the var.
FILENAME=$(dd if=/dev/urandom bs=512 count=1 status=none | sha512sum /
    | sed -r 's/.{3}$//')
unset FILENAME

# Here the file to be encrypted is hardcoded. Better to prompt for it.
openssl enc -aes-256-cbc -a -A -md sha512 -pbkdf2 -iter 250000 -salt /
   -pass env:MATERIAL -in ~/test.txt -out ~/test.txt.aes

# Now overwrite the key in memory just used. This is the same as FILENAME above
MATERIAL=$(dd if=/dev/urandom bs=512 count=1 status=none | sha512sum /
    | sed -r 's/.{3}$//')
unset MATERIAL
#echo;echo MATERIAL;echo

# Now I need to pause this script at every point and check all RAM for any instance of the MATERIAL

echo;echo The process has completed;echo

#---[End of script]---