This is from Grok here wrt the following content:
On 7/6/2025 11:41 AM, Stefan Claas wrote:
Chris M. Thomasson wrote:
This is from Grok here wrt the following content:
[...]
Let's face it, nobody in the world would use your
webpage ciper in production, because security aware
people use encryption offline.
Keep in mind that it's client only. You can download the page, turn the internet off and use it fine. I just thought it would be fun to be able
to create links with ciphertext payloads.
So why are you still
promoting your cipher here, instead of using minicrypt,
which I asked you to test on Windows?
Do you realize how busy I have been lately? Check out this 3d field, fly around when you get bored:
https://skfb.ly/pyP9E
Promoting it? Well yeah in a sense. For a certain reason... I just want
it to be heavily attacked and broken by some clever person. That would
be neat to me! Why would I use minicrypt? Has it went through proper and extensive crypt analysis? Btw, I never used GO.
Basically, I like several properties of my experimental cipher. No
ciphertext has any data sent in the clear. Aka, no IV, no sequence
numbers, ect... A ciphertext is also bit sensitive. Any alteration to
the ciphertext will make it decrypt into random garbage. Each encryption
of a plaintext will be radically different.
Actually, it would be fun if they tried to crack it, akin to what was
done to AOB's ciphers. They got completely ripped apart!
On 7/7/2025 7:18 AM, Stefan Claas wrote:
Chris M. Thomasson wrote:
On 7/6/2025 11:41 AM, Stefan Claas wrote:
Chris M. Thomasson wrote:
This is from Grok here wrt the following content:
[...]
Let's face it, nobody in the world would use your
webpage ciper in production, because security aware
people use encryption offline.
Keep in mind that it's client only. You can download the page, turn the internet off and use it fine. I just thought it would be fun to be able to create links with ciphertext payloads.
So why are you still
promoting your cipher here, instead of using minicrypt,
which I asked you to test on Windows?
Do you realize how busy I have been lately? Check out this 3d field, fly around when you get bored:
https://skfb.ly/pyP9E
Promoting it? Well yeah in a sense. For a certain reason... I just want it to be heavily attacked and broken by some clever person. That would
be neat to me! Why would I use minicrypt? Has it went through proper and extensive crypt analysis? Btw, I never used GO.
Basically, I like several properties of my experimental cipher. No ciphertext has any data sent in the clear. Aka, no IV, no sequence numbers, ect... A ciphertext is also bit sensitive. Any alteration to
the ciphertext will make it decrypt into random garbage. Each encryption of a plaintext will be radically different.
It's a bottomless insolence the way you treat me, always being busy with your constant excuses.
Slowly but surely I'm realizing why the bitmessage community calls you an idiot.
EOD.
Actually, what about this for starters? Just something to get my mind
around go and how it works:
https://go.dev/play
https://go.dev/doc/install
I have never used Go.
?
On 7/7/2025 2:17 PM, Stefan Claas wrote:
Chris M. Thomasson wrote:
On 7/7/2025 7:18 AM, Stefan Claas wrote:
Chris M. Thomasson wrote:
On 7/6/2025 11:41 AM, Stefan Claas wrote:
Chris M. Thomasson wrote:
This is from Grok here wrt the following content:
[...]
Let's face it, nobody in the world would use your
webpage ciper in production, because security aware
people use encryption offline.
Keep in mind that it's client only. You can download the page, turn the
internet off and use it fine. I just thought it would be fun to be able
to create links with ciphertext payloads.
So why are you still
promoting your cipher here, instead of using minicrypt,
which I asked you to test on Windows?
Do you realize how busy I have been lately? Check out this 3d field, fly
around when you get bored:
https://skfb.ly/pyP9E
Promoting it? Well yeah in a sense. For a certain reason... I just want
it to be heavily attacked and broken by some clever person. That would
be neat to me! Why would I use minicrypt? Has it went through proper and
extensive crypt analysis? Btw, I never used GO.
Basically, I like several properties of my experimental cipher. No ciphertext has any data sent in the clear. Aka, no IV, no sequence numbers, ect... A ciphertext is also bit sensitive. Any alteration to the ciphertext will make it decrypt into random garbage. Each encryption
of a plaintext will be radically different.
It's a bottomless insolence the way you treat me, always being busy with
your constant excuses.
Slowly but surely I'm realizing why the bitmessage community calls you an idiot.
EOD.
Actually, what about this for starters? Just something to get my mind around go and how it works:
https://go.dev/play
https://go.dev/doc/install
I have never used Go.
?
https://github.com/Ch1ffr3punk/minicrypt/releases/tag/v0.1.0 https://github.com/Ch1ffr3punk/minicrypt-CLI/releases/tag/v0.1.0
Downloaded GO and your source code. The non-CLI version:
https://i.ibb.co/rRwxJgx8/image.png
https://i.ibb.co/C5W63ffy/image.png
Now, when I get some more time today, I will learn how to compile your
code. Readme? ;^)
Apparently the go compiler works with my command line as is. It already
seem to set/mutate some environment variables.
https://i.ibb.co/Jjw02DjN/image.png
On 7/7/2025 2:41 PM, Chris M. Thomasson wrote:
For instance:
https://github.com/nicksnyder/go-i18n
I see, but it scares me a little for all of this other code to be in there.
On 7/7/2025 2:57 PM, Stefan Claas wrote:
And for the CLI version just cd into the folder and then
do: go build -ldflags "-s -w" which then produces an .exe of the
CLI version of minicrypt.
So, the CLI version is the way to go. I just need to download it. I got
the non-cli version.
On 7/7/2025 3:16 PM, Stefan Claas wrote:
Chris M. Thomasson wrote:
On 7/7/2025 2:57 PM, Stefan Claas wrote:
And for the CLI version just cd into the folder and then
do: go build -ldflags "-s -w" which then produces an .exe of the
CLI version of minicrypt.
So, the CLI version is the way to go. I just need to download it. I got the non-cli version.
https://github.com/Ch1ffr3punk/minicrypt-CLI
I got an exe... :^)
https://i.ibb.co/4Z3yf3gV/image.png
Here is my public key, import him as stefan.pem:
-----BEGIN PUBLIC KEY-----
wP/uWjblgesQ9gsoMbPNuVXS5+9oDdKCqNQ62LhLNXo=
-----END PUBLIC KEY-----
On 7/7/2025 3:34 PM, Stefan Claas wrote:
Chris M. Thomasson wrote:
On 7/7/2025 3:16 PM, Stefan Claas wrote:
Chris M. Thomasson wrote:
On 7/7/2025 2:57 PM, Stefan Claas wrote:
And for the CLI version just cd into the folder and then
do: go build -ldflags "-s -w" which then produces an .exe of the CLI version of minicrypt.
So, the CLI version is the way to go. I just need to download it. I got
the non-cli version.
https://github.com/Ch1ffr3punk/minicrypt-CLI
I got an exe... :^)
https://i.ibb.co/4Z3yf3gV/image.png
:-)
Now, even though I have your CLI version up and running, I still need to
try to properly compile your non-CLI version just to see if I can do it
on my end. Also, I need to learn how to your program. README! ;^D
Humm... I made some hello world programs in go, and they all work.
Humm... Who knows! I should be able to port my cipher to Go... ;^)
Time to cook dinner, but that is in the back of my mind for sure. I need
to setup the proper keys and such for your program.
The GUI version it aimed at elderly people, with no experience in
public key cryptography and it should be easy to understand.
I made this version for a german regular especially, because he had difficulty to understand the old CLI version, with just two commands.
On 7/8/2025 2:06 PM, Stefan Claas wrote:
Chris M. Thomasson wrote:
On 7/7/2025 3:34 PM, Stefan Claas wrote:
Chris M. Thomasson wrote:
On 7/7/2025 3:16 PM, Stefan Claas wrote:
Chris M. Thomasson wrote:
On 7/7/2025 2:57 PM, Stefan Claas wrote:
And for the CLI version just cd into the folder and then
do: go build -ldflags "-s -w" which then produces an .exe of the
CLI version of minicrypt.
So, the CLI version is the way to go. I just need to download it. I got
the non-cli version.
https://github.com/Ch1ffr3punk/minicrypt-CLI
I got an exe... :^)
https://i.ibb.co/4Z3yf3gV/image.png
:-)
Now, even though I have your CLI version up and running, I still need to try to properly compile your non-CLI version just to see if I can do it on my end. Also, I need to learn how to your program. README! ;^D
The GUI version it aimed at elderly people, with no experience in
public key cryptography and it should be easy to understand. I made
this version for a german regular especially, because he had difficulty
to understand the old CLI version, with just two commands.
This is kind of one reason why I created the experimental online version
of my cipher. No need to download anything, and its client only. No
server side code involved. Just thought it would be fun to send a
ciphertext as a link. ;^)
Using the CLI is fine with me. But, it would still be fun to see if I
can build the GUI version.
go install fyne.io/tools/cmd/fyne@latest
seems to be the key. Keep in mind that I am a newb at go and how it
works. ;^o
I am also with the GUI version in the second round for sponsorship,
because a professional audit is pretty expensive, which I like to have.
Hope I can get the sponsorship. I plan to release the GUI version also
in the Microsoft Store. For that I payed already, to get a Microsoft Developer account.
Actually, I have a developer account with Microsoft, but iirc, did not
have to pay for it, yet. There might of been a small one time fee, for
some reason cannot exactly remember right now. It was just so I could interact with my xbox in developer mode. Connect to it and upload
programs. MSVC is pretty nice in the way it can just deploy my directx programs to it.
Humm... I made some hello world programs in go, and they all work. Humm... Who knows! I should be able to port my cipher to Go... ;^)
Good idea.
Yeah. But I might have a problem in the way the HMAC is implemented.
Taking a digest should not mutate the current state. Python 3 is like
that, so, I might have to create my own HMAC from the std. That would
suck, but oh well.
Time to cook dinner, but that is in the back of my mind for sure. I need to setup the proper keys and such for your program.
Here is my public key, import him as stefan.pem:
-----BEGIN PUBLIC KEY-----
wP/uWjblgesQ9gsoMbPNuVXS5+9oDdKCqNQ62LhLNXo=
-----END PUBLIC KEY-----
Okay. Will do, just try to be a bit patient with me... Unfortunately, I
need to try to program one my bone rigs to automatically add in all of
my keyframes and shit from my python 3 code right now in blender. I
should be able to create all of my animation frames directly from my
code and not have to manually alter my armatures. Uggg!
Starting small here:
https://i.ibb.co/1f0tgN9m/image.png
:^)
On 7/9/2025 12:53 PM, Stefan Claas wrote:
How does it work if A encrypts on local host and B should decrypt on his local host, with that given link from A
Wrt the online version:
A needs to send/give B the ciphertext somehow, email, snail mail,
somehow, hand signals, ect... ;^) Then B, assuming that A and B have the
same secret key, can use said ciphertext to decrypt it. So, if you
notice the online program has a ciphertext only, without a link prefix.
Say this example: I am encrypting the message on my local host using the default key:
On 10/07/2025 18:19, Stefan Claas wrote:
Chris M. Thomasson wrote:
On 7/9/2025 12:53 PM, Stefan Claas wrote:
How does it work if A encrypts on local host and B should decrypt on his
local host, with that given link from A
Wrt the online version:
A needs to send/give B the ciphertext somehow, email, snail mail, somehow, hand signals, ect... ;^) Then B, assuming that A and B have the same secret key, can use said ciphertext to decrypt it. So, if you
notice the online program has a ciphertext only, without a link prefix. Say this example: I am encrypting the message on my local host using the default key:
But how, for example, would you give me the secret key, from the USA to Germany, without meeting in person?
Diffie-Hellman can establish a secret key in public. Then authenticate
over an encrypted channel.
Chris M. Thomasson wrote:
On 7/9/2025 12:53 PM, Stefan Claas wrote:
How does it work if A encrypts on local host and B should decrypt on his >>> local host, with that given link from A
Wrt the online version:
A needs to send/give B the ciphertext somehow, email, snail mail,
somehow, hand signals, ect... ;^) Then B, assuming that A and B have the
same secret key, can use said ciphertext to decrypt it. So, if you
notice the online program has a ciphertext only, without a link prefix.
Say this example: I am encrypting the message on my local host using the
default key:
But how, for example, would you give me the secret key, from the USA to Germany, without meeting in person?
Richard Heathfield wrote:<snip>
On 10/07/2025 18:19, Stefan Claas wrote:
But how, for example, would you give me the secret key, from the USA to
Germany, without meeting in person?
Diffie-Hellman can establish a secret key in public. Then authenticate
over an encrypted channel.
I know, but how do you protect the key on your online device against
Pegasus or FinSpy?
On 11/07/2025 15:56, Stefan Claas wrote:
Richard Heathfield wrote:<snip>
On 10/07/2025 18:19, Stefan Claas wrote:
But how, for example, would you give me the secret key, from the USA to Germany, without meeting in person?
Diffie-Hellman can establish a secret key in public. Then authenticate over an encrypted channel.
I know, but how do you protect the key on your online device against Pegasus or FinSpy?
Why would you bother? You've got the cart before the horse. First secure
your computing device against spyware. /Then/ think about keeping
secrets on it.
Stefan Claas <stefan@mailchuck.com> wrote:
Richard Heathfield wrote:
On 10/07/2025 18:19, Stefan Claas wrote:
Chris M. Thomasson wrote:
On 7/9/2025 12:53 PM, Stefan Claas wrote:
How does it work if A encrypts on local host and B should
decrypt on his local host, with that given link from A
Wrt the online version:
A needs to send/give B the ciphertext somehow, email, snail
mail, somehow, hand signals, ect... ;^) Then B, assuming that A
and B have the same secret key, can use said ciphertext to
decrypt it. So, if you notice the online program has a
ciphertext only, without a link prefix. Say this example: I am encrypting the message on my local host using the default key:
But how, for example, would you give me the secret key, from the
USA to Germany, without meeting in person?
Diffie-Hellman can establish a secret key in public. Then
authenticate over an encrypted channel.
I know, but how do you protect the key on your online device against Pegasus or FinSpy? For proper encryption two parties have to do it offline, but GnuPG users could never learn it, because it was never explained to them.
Nor will anyone else who falls into the "average computer user
category" and thinks the "I have nothing to hide" excuse is valid.
You are not fighting "encryption" here, you are fighting the fact that
few care enough and are motivated to learn. And that battle will not
be won by better cryptography, nor by better user interfaces. The only
way those folks will use "secure means" is if the secure means happens
all automatically, by default, without their knowledge, for them.
Richard Heathfield wrote:
On 10/07/2025 18:19, Stefan Claas wrote:
Chris M. Thomasson wrote:
On 7/9/2025 12:53 PM, Stefan Claas wrote:
How does it work if A encrypts on local host and B should
decrypt on his local host, with that given link from A
Wrt the online version:
A needs to send/give B the ciphertext somehow, email, snail
mail, somehow, hand signals, ect... ;^) Then B, assuming that A
and B have the same secret key, can use said ciphertext to
decrypt it. So, if you notice the online program has a
ciphertext only, without a link prefix. Say this example: I am
encrypting the message on my local host using the default key:
But how, for example, would you give me the secret key, from the
USA to Germany, without meeting in person?
Diffie-Hellman can establish a secret key in public. Then
authenticate over an encrypted channel.
I know, but how do you protect the key on your online device against
Pegasus or FinSpy? For proper encryption two parties have to do it
offline, but GnuPG users could never learn it, because it was never
explained to them.
On 7/12/2025 12:59 PM, Stefan Claas wrote:
Rich wrote:
You are not fighting "encryption" here, you are fighting the fact that few care enough and are motivated to learn. And that battle will not
be won by better cryptography, nor by better user interfaces. The only way those folks will use "secure means" is if the secure means happens all automatically, by default, without their knowledge, for them.
And you know very well that this will not happen, because companies are
not willing to defeat this known issue and only offline encryption and decryption is the way to go, for secure communications.
Think of an offline encrypt with say, my symmetric HMAC cipher thing.
You save the ciphertext to a usb drive. Oh shit, say the offline
computer is infected with a virus, and the USB is now highly suspect.
Sigh... Alice gives the USB to Bob, key/viral exchange, say a new key is encrypted in the ciphertext... ;^). Bob just infected his computer with
the virus before decrypt even occurs. Now, if this is all offline, then
the virus should not be able to use the net to infect. However, it might
have a keylogger and alter your encrypted messages right after you click encrypt or something? So, you think you encrypt the message attack at
dawn. The keylogger changes dawn to dusk -before- it gets passed into
the cipher to do its thing, so to speak...
So, offline encrypting Alice and Bob would need to be _sure_ that their devices are _secure_, aka, no malware, ect... and for this aspect, no internet access, wifi, bluetooth, ect, signals,... Its in a, say a
fractal cloak, so to speak. Check this out: fractenna.com. They have
them.
Think of an offline encrypt with say, my symmetric HMAC cipher thing.
You save the ciphertext to a usb drive. Oh shit, say the offline
computer is infected with a virus, and the USB is now highly suspect.
Sigh... Alice gives the USB to Bob, key/viral exchange, say a new key is encrypted in the ciphertext... ;^). Bob just infected his computer with
the virus before decrypt even occurs.
Rich wrote:
Stefan Claas <stefan@mailchuck.com> wrote:
Richard Heathfield wrote:
On 10/07/2025 18:19, Stefan Claas wrote:
Chris M. Thomasson wrote:
On 7/9/2025 12:53 PM, Stefan Claas wrote:
How does it work if A encrypts on local host and B should
decrypt on his local host, with that given link from A
Wrt the online version:
A needs to send/give B the ciphertext somehow, email, snail
mail, somehow, hand signals, ect... ;^) Then B, assuming that A
and B have the same secret key, can use said ciphertext to
decrypt it. So, if you notice the online program has a
ciphertext only, without a link prefix. Say this example: I am
encrypting the message on my local host using the default key:
But how, for example, would you give me the secret key, from the
USA to Germany, without meeting in person?
Diffie-Hellman can establish a secret key in public. Then
authenticate over an encrypted channel.
I know, but how do you protect the key on your online device against
Pegasus or FinSpy? For proper encryption two parties have to do it
offline, but GnuPG users could never learn it, because it was never
explained to them.
Nor will anyone else who falls into the "average computer user
category" and thinks the "I have nothing to hide" excuse is valid.
You are not fighting "encryption" here, you are fighting the fact that
few care enough and are motivated to learn. And that battle will not
be won by better cryptography, nor by better user interfaces. The only
way those folks will use "secure means" is if the secure means happens
all automatically, by default, without their knowledge, for them.
And you know very well that this will not happen, because companies are
not willing to defeat this known issue
and only offline encryption and decryption is the way to go, for
secure communications.
Chris M. Thomasson wrote:
Think of an offline encrypt with say, my symmetric HMAC cipher
thing. You save the ciphertext to a usb drive. Oh shit, say the
offline computer is infected with a virus, and the USB is now highly
suspect. Sigh... Alice gives the USB to Bob, key/viral exchange,
say a new key is encrypted in the ciphertext... ;^). Bob just
infected his computer with the virus before decrypt even occurs.
Now, if this is all offline, then the virus should not be able to
use the net to infect. However, it might have a keylogger and alter
your encrypted messages right after you click encrypt or something?
So, you think you encrypt the message attack at dawn. The keylogger
changes dawn to dusk -before- it gets passed into the cipher to do
its thing, so to speak...
So, offline encrypting Alice and Bob would need to be _sure_ that
their devices are _secure_, aka, no malware, ect... and for this
aspect, no internet access, wifi, bluetooth, ect, signals,... Its
in a, say a fractal cloak, so to speak. Check this out:
fractenna.com. They have them.
You see, this topic is always left out by security experts, when discussing encryption.
For an initial set-up of an offline device it can be used once online and
to install the required programs.
Later you send/receive files with a 3,5 inch drive and disks. Their
are so loud that you can here read/write access and only have 1.4 MB
storage capacity which you can easily inspect with a disk monitor.
But you must hurry to get disks and a drive at Amazon, because when
stocks run out, I am not sure if they are re-filling.
On 7/12/2025 12:59 PM, Stefan Claas wrote:
Rich wrote:
Stefan Claas <stefan@mailchuck.com> wrote:
Richard Heathfield wrote:
On 10/07/2025 18:19, Stefan Claas wrote:
Chris M. Thomasson wrote:
On 7/9/2025 12:53 PM, Stefan Claas wrote:
How does it work if A encrypts on local host and B should
decrypt on his local host, with that given link from A
Wrt the online version:
A needs to send/give B the ciphertext somehow, email, snail
mail, somehow, hand signals, ect... ;^) Then B, assuming that A >>>>>>> and B have the same secret key, can use said ciphertext to
decrypt it. So, if you notice the online program has a
ciphertext only, without a link prefix. Say this example: I am
encrypting the message on my local host using the default key:
But how, for example, would you give me the secret key, from the
USA to Germany, without meeting in person?
Diffie-Hellman can establish a secret key in public. Then
authenticate over an encrypted channel.
I know, but how do you protect the key on your online device against
Pegasus or FinSpy? For proper encryption two parties have to do it
offline, but GnuPG users could never learn it, because it was never
explained to them.
Nor will anyone else who falls into the "average computer user
category" and thinks the "I have nothing to hide" excuse is valid.
You are not fighting "encryption" here, you are fighting the fact that
few care enough and are motivated to learn. And that battle will not
be won by better cryptography, nor by better user interfaces. The only
way those folks will use "secure means" is if the secure means happens
all automatically, by default, without their knowledge, for them.
And you know very well that this will not happen, because companies are
not willing to defeat this known issue and only offline encryption and
decryption is the way to go, for secure communications.
Think of an offline encrypt with say, my symmetric HMAC cipher thing.
You save the ciphertext to a usb drive. Oh shit, say the offline
computer is infected with a virus, and the USB is now highly suspect.
Chris M. Thomasson wrote:
Think of an offline encrypt with say, my symmetric HMAC cipher thing.
You save the ciphertext to a usb drive. Oh shit, say the offline
computer is infected with a virus, and the USB is now highly suspect.
Sigh... Alice gives the USB to Bob, key/viral exchange, say a new key is
encrypted in the ciphertext... ;^). Bob just infected his computer with
the virus before decrypt even occurs.
Don't you have a Kanguru Defender 3000? I have one since many years,
with 3 years AV license.
<https://www.kanguru.com/products/kanguru-defender-3000-superspeed-usb-3-0-fips-140-2-level-3-certified-hardware-encrypted-flash-drive>
Rich wrote:
And, how accurately do you think the average person who wants to send
an encrypted message will be at typing this:
KqHtqbSca2hvI02pCMHtdKQLfHhW6OeN7iK1Fg45nMpoT+to8XpwpvARkW6UziY0iyZWUEgP/gol
gz5p3XpGCe0hZbYV2IYYLDvvRjGWj1k5IHkDX4WshBZvI5fhVssJOqVI3bzqdEW3XLD4NoGKVQg3
ZeNaSJs2hBySnkBoKGI=
That's 128 random bytes, base64 encoded. 128 bytes is right about the original "tweet length" of tweets on shitter, so there is a severe
limit of the amount of information that can be transferred.
That why I have my az and ug program for people available, but it uses 2 bytes, which should be no problem.
$ openssl rand 128 | az | ug -g
ZMAXT OPNWC LZWIF OQIMR PNNQV BFQLC BRZDA RUFBT ROLQS GOLKA
KKNJF ULBLO WINNL IIVVK FWTEE XRGBS UJCYS DCMWH JUMAA VLLNX
MJMYS LHSKG ENKLL LUGBN YNDSP AJYMO OXUBC YQNOY QMFYW ABOPH
NUVCJ KMFCM XKDVM EEXYL LVUKO VVGAU UACYV OHKUG GTVAA MWDLO
KCPYN HOWVM DPNHA ZMGHV MFIKW DILNO FYQHK VQELK OMFNL EOLTL
ETMPL S
And, how accurately do you think the average person who wants to send
an encrypted message will be at typing this:
KqHtqbSca2hvI02pCMHtdKQLfHhW6OeN7iK1Fg45nMpoT+to8XpwpvARkW6UziY0iyZWUEgP/gol gz5p3XpGCe0hZbYV2IYYLDvvRjGWj1k5IHkDX4WshBZvI5fhVssJOqVI3bzqdEW3XLD4NoGKVQg3 ZeNaSJs2hBySnkBoKGI=
That's 128 random bytes, base64 encoded. 128 bytes is right about the original "tweet length" of tweets on shitter, so there is a severe
limit of the amount of information that can be transferred.
Rich wrote:
And, how accurately do you think the average person who wants to send
an encrypted message will be at typing this:
KqHtqbSca2hvI02pCMHtdKQLfHhW6OeN7iK1Fg45nMpoT+to8XpwpvARkW6UziY0iyZWUEgP/gol >> gz5p3XpGCe0hZbYV2IYYLDvvRjGWj1k5IHkDX4WshBZvI5fhVssJOqVI3bzqdEW3XLD4NoGKVQg3 >> ZeNaSJs2hBySnkBoKGI=
That's 128 random bytes, base64 encoded. 128 bytes is right about the
original "tweet length" of tweets on shitter, so there is a severe
limit of the amount of information that can be transferred.
That why I have my az and ug program for people available, but it uses 2 bytes, which should be no problem.
$ openssl rand 128 | az | ug -g
ZMAXT OPNWC LZWIF OQIMR PNNQV BFQLC BRZDA RUFBT ROLQS GOLKA
KKNJF ULBLO WINNL IIVVK FWTEE XRGBS UJCYS DCMWH JUMAA VLLNX
MJMYS LHSKG ENKLL LUGBN YNDSP AJYMO OXUBC YQNOY QMFYW ABOPH
NUVCJ KMFCM XKDVM EEXYL LVUKO VVGAU UACYV OHKUG GTVAA MWDLO
KCPYN HOWVM DPNHA ZMGHV MFIKW DILNO FYQHK VQELK OMFNL EOLTL
ETMPL S
Rich wrote:
Stefan Claas <stefan@mailchuck.com> wrote:
Rich wrote:
And, how accurately do you think the average person who wants to send an encrypted message will be at typing this:
KqHtqbSca2hvI02pCMHtdKQLfHhW6OeN7iK1Fg45nMpoT+to8XpwpvARkW6UziY0iyZWUEgP/gol
gz5p3XpGCe0hZbYV2IYYLDvvRjGWj1k5IHkDX4WshBZvI5fhVssJOqVI3bzqdEW3XLD4NoGKVQg3
ZeNaSJs2hBySnkBoKGI=
That's 128 random bytes, base64 encoded. 128 bytes is right about the original "tweet length" of tweets on shitter, so there is a severe limit of the amount of information that can be transferred.
That why I have my az and ug program for people available, but it uses 2 bytes, which should be no problem.
$ openssl rand 128 | az | ug -g
ZMAXT OPNWC LZWIF OQIMR PNNQV BFQLC BRZDA RUFBT ROLQS GOLKA
KKNJF ULBLO WINNL IIVVK FWTEE XRGBS UJCYS DCMWH JUMAA VLLNX
MJMYS LHSKG ENKLL LUGBN YNDSP AJYMO OXUBC YQNOY QMFYW ABOPH
NUVCJ KMFCM XKDVM EEXYL LVUKO VVGAU UACYV OHKUG GTVAA MWDLO
KCPYN HOWVM DPNHA ZMGHV MFIKW DILNO FYQHK VQELK OMFNL EOLTL
ETMPL S
Yes, easier to enter than raw base64. But in this case this "easier"
is like the fact that it is "easier" to move 10,000kg of sand 1km by
hand than it is to move one single 10,000kg rock 1km by hand. "Easier?" Yes,
but no one will actually want to do so either by hand if they have
other alternatives.
No one, except for the very very truly determined (a tiny sized population), will want to hand type that to maintain proper
air-gapping. So they will use USB sticks or other methods to "move"
the data, opening up the possibility of transfer of an exploit via that same USB stick.
A 3.5 ich disk drive and disk for it come in handy, because you hear
every read/write process and can quickly examine the sectors with a
disk editor.
Stefan Claas <stefan@mailchuck.com> wrote:
Rich wrote:
And, how accurately do you think the average person who wants to send
an encrypted message will be at typing this:
KqHtqbSca2hvI02pCMHtdKQLfHhW6OeN7iK1Fg45nMpoT+to8XpwpvARkW6UziY0iyZWUEgP/gol
gz5p3XpGCe0hZbYV2IYYLDvvRjGWj1k5IHkDX4WshBZvI5fhVssJOqVI3bzqdEW3XLD4NoGKVQg3
ZeNaSJs2hBySnkBoKGI=
That's 128 random bytes, base64 encoded. 128 bytes is right about the original "tweet length" of tweets on shitter, so there is a severe
limit of the amount of information that can be transferred.
That why I have my az and ug program for people available, but it uses 2 bytes, which should be no problem.
$ openssl rand 128 | az | ug -g
ZMAXT OPNWC LZWIF OQIMR PNNQV BFQLC BRZDA RUFBT ROLQS GOLKA
KKNJF ULBLO WINNL IIVVK FWTEE XRGBS UJCYS DCMWH JUMAA VLLNX
MJMYS LHSKG ENKLL LUGBN YNDSP AJYMO OXUBC YQNOY QMFYW ABOPH
NUVCJ KMFCM XKDVM EEXYL LVUKO VVGAU UACYV OHKUG GTVAA MWDLO
KCPYN HOWVM DPNHA ZMGHV MFIKW DILNO FYQHK VQELK OMFNL EOLTL
ETMPL S
Yes, easier to enter than raw base64. But in this case this "easier"
is like the fact that it is "easier" to move 10,000kg of sand 1km by
hand than it is to move one single 10,000kg rock 1km by hand. "Easier?" Yes, but no one will actually want to do so either by hand if they have
other alternatives.
No one, except for the very very truly determined (a tiny sized
population), will want to hand type that to maintain proper
air-gapping. So they will use USB sticks or other methods to "move"
the data, opening up the possibility of transfer of an exploit via that
same USB stick.
Stefan Claas wrote:
Rich wrote:
Stefan Claas <stefan@mailchuck.com> wrote:
Rich wrote:
And, how accurately do you think the average person who wants to send >> > > > an encrypted message will be at typing this:
KqHtqbSca2hvI02pCMHtdKQLfHhW6OeN7iK1Fg45nMpoT+to8XpwpvARkW6UziY0iyZWUEgP/gol
gz5p3XpGCe0hZbYV2IYYLDvvRjGWj1k5IHkDX4WshBZvI5fhVssJOqVI3bzqdEW3XLD4NoGKVQg3
ZeNaSJs2hBySnkBoKGI=
That's 128 random bytes, base64 encoded. 128 bytes is right about the >> > > > original "tweet length" of tweets on shitter, so there is a severe
limit of the amount of information that can be transferred.
That why I have my az and ug program for people available, but it uses 2 >> > > bytes, which should be no problem.
$ openssl rand 128 | az | ug -g
ZMAXT OPNWC LZWIF OQIMR PNNQV BFQLC BRZDA RUFBT ROLQS GOLKA
KKNJF ULBLO WINNL IIVVK FWTEE XRGBS UJCYS DCMWH JUMAA VLLNX
MJMYS LHSKG ENKLL LUGBN YNDSP AJYMO OXUBC YQNOY QMFYW ABOPH
NUVCJ KMFCM XKDVM EEXYL LVUKO VVGAU UACYV OHKUG GTVAA MWDLO
KCPYN HOWVM DPNHA ZMGHV MFIKW DILNO FYQHK VQELK OMFNL EOLTL
ETMPL S
Yes, easier to enter than raw base64. But in this case this "easier"
is like the fact that it is "easier" to move 10,000kg of sand 1km by
hand than it is to move one single 10,000kg rock 1km by hand. "Easier?" Yes,
but no one will actually want to do so either by hand if they have
other alternatives.
No one, except for the very very truly determined (a tiny sized
population), will want to hand type that to maintain proper
air-gapping. So they will use USB sticks or other methods to "move"
the data, opening up the possibility of transfer of an exploit via that
same USB stick.
A 3.5 ich disk drive and disk for it come in handy, because you hear
every read/write process and can quickly examine the sectors with a
disk editor.
Or better yet, a Telefax and mulitunction offline printer with scan
option for OCR and the offline PC. With a 16 point mono font you get
2000 chars with my az encoder and under Windows OCR is 100% reliably
scanned from an A4 page.
Rich wrote:
Stefan Claas <stefan@mailchuck.com> wrote:
Rich wrote:
And, how accurately do you think the average person who wants to send
an encrypted message will be at typing this:
KqHtqbSca2hvI02pCMHtdKQLfHhW6OeN7iK1Fg45nMpoT+to8XpwpvARkW6UziY0iyZWUEgP/gol
gz5p3XpGCe0hZbYV2IYYLDvvRjGWj1k5IHkDX4WshBZvI5fhVssJOqVI3bzqdEW3XLD4NoGKVQg3
ZeNaSJs2hBySnkBoKGI=
That's 128 random bytes, base64 encoded. 128 bytes is right about the >> > > original "tweet length" of tweets on shitter, so there is a severe
limit of the amount of information that can be transferred.
That why I have my az and ug program for people available, but it uses 2 >> > bytes, which should be no problem.
$ openssl rand 128 | az | ug -g
ZMAXT OPNWC LZWIF OQIMR PNNQV BFQLC BRZDA RUFBT ROLQS GOLKA
KKNJF ULBLO WINNL IIVVK FWTEE XRGBS UJCYS DCMWH JUMAA VLLNX
MJMYS LHSKG ENKLL LUGBN YNDSP AJYMO OXUBC YQNOY QMFYW ABOPH
NUVCJ KMFCM XKDVM EEXYL LVUKO VVGAU UACYV OHKUG GTVAA MWDLO
KCPYN HOWVM DPNHA ZMGHV MFIKW DILNO FYQHK VQELK OMFNL EOLTL
ETMPL S
Yes, easier to enter than raw base64. But in this case this "easier"
is like the fact that it is "easier" to move 10,000kg of sand 1km by
hand than it is to move one single 10,000kg rock 1km by hand. "Easier?" Yes,
but no one will actually want to do so either by hand if they have
other alternatives.
No one, except for the very very truly determined (a tiny sized
population), will want to hand type that to maintain proper
air-gapping. So they will use USB sticks or other methods to "move"
the data, opening up the possibility of transfer of an exploit via that
same USB stick.
A 3.5 ich disk drive and disk for it come in handy, because you hear
every read/write process
and can quickly examine the sectors with a disk editor.
Stefan Claas <stefan@mailchuck.com> wrote:
Stefan Claas wrote:
Rich wrote:
Stefan Claas <stefan@mailchuck.com> wrote:
Rich wrote:
And, how accurately do you think the average person who wants to send
an encrypted message will be at typing this:
KqHtqbSca2hvI02pCMHtdKQLfHhW6OeN7iK1Fg45nMpoT+to8XpwpvARkW6UziY0iyZWUEgP/gol
gz5p3XpGCe0hZbYV2IYYLDvvRjGWj1k5IHkDX4WshBZvI5fhVssJOqVI3bzqdEW3XLD4NoGKVQg3
ZeNaSJs2hBySnkBoKGI=
That's 128 random bytes, base64 encoded. 128 bytes is right about the
original "tweet length" of tweets on shitter, so there is a severe limit of the amount of information that can be transferred.
That why I have my az and ug program for people available, but it uses 2
bytes, which should be no problem.
$ openssl rand 128 | az | ug -g
ZMAXT OPNWC LZWIF OQIMR PNNQV BFQLC BRZDA RUFBT ROLQS GOLKA
KKNJF ULBLO WINNL IIVVK FWTEE XRGBS UJCYS DCMWH JUMAA VLLNX
MJMYS LHSKG ENKLL LUGBN YNDSP AJYMO OXUBC YQNOY QMFYW ABOPH
NUVCJ KMFCM XKDVM EEXYL LVUKO VVGAU UACYV OHKUG GTVAA MWDLO
KCPYN HOWVM DPNHA ZMGHV MFIKW DILNO FYQHK VQELK OMFNL EOLTL
ETMPL S
Yes, easier to enter than raw base64. But in this case this "easier" is like the fact that it is "easier" to move 10,000kg of sand 1km by hand than it is to move one single 10,000kg rock 1km by hand. "Easier?" Yes,
but no one will actually want to do so either by hand if they have other alternatives.
No one, except for the very very truly determined (a tiny sized population), will want to hand type that to maintain proper air-gapping. So they will use USB sticks or other methods to "move" the data, opening up the possibility of transfer of an exploit via that same USB stick.
A 3.5 ich disk drive and disk for it come in handy, because you hear every read/write process and can quickly examine the sectors with a
disk editor.
Or better yet, a Telefax and mulitunction offline printer with scan
option for OCR and the offline PC. With a 16 point mono font you get
2000 chars with my az encoder and under Windows OCR is 100% reliably scanned from an A4 page.
This is your best bet for making it such that all but the most
determined are possibly likely to use the system.
The air-gap machine has to have an integrated scanner and printer, and
OCR software (or else you need to use barcodes for input -- which might
be more reliable for input). The user would print the "code",
scan/read it on the airgap machine, decrypt, create return, encrypt,
and then print the encrypted version for input to the networked machine
for sending. You might at this point also want scan/ocr capability on
the network machine to read the printout and convert to digital data.
Stefan Claas <stefan@mailchuck.com> wrote:
Rich wrote:
Stefan Claas <stefan@mailchuck.com> wrote:
Rich wrote:
And, how accurately do you think the average person who wants to send an encrypted message will be at typing this:
KqHtqbSca2hvI02pCMHtdKQLfHhW6OeN7iK1Fg45nMpoT+to8XpwpvARkW6UziY0iyZWUEgP/gol
gz5p3XpGCe0hZbYV2IYYLDvvRjGWj1k5IHkDX4WshBZvI5fhVssJOqVI3bzqdEW3XLD4NoGKVQg3
ZeNaSJs2hBySnkBoKGI=
That's 128 random bytes, base64 encoded. 128 bytes is right about the
original "tweet length" of tweets on shitter, so there is a severe limit of the amount of information that can be transferred.
That why I have my az and ug program for people available, but it uses 2
bytes, which should be no problem.
$ openssl rand 128 | az | ug -g
ZMAXT OPNWC LZWIF OQIMR PNNQV BFQLC BRZDA RUFBT ROLQS GOLKA
KKNJF ULBLO WINNL IIVVK FWTEE XRGBS UJCYS DCMWH JUMAA VLLNX
MJMYS LHSKG ENKLL LUGBN YNDSP AJYMO OXUBC YQNOY QMFYW ABOPH
NUVCJ KMFCM XKDVM EEXYL LVUKO VVGAU UACYV OHKUG GTVAA MWDLO
KCPYN HOWVM DPNHA ZMGHV MFIKW DILNO FYQHK VQELK OMFNL EOLTL
ETMPL S
Yes, easier to enter than raw base64. But in this case this "easier"
is like the fact that it is "easier" to move 10,000kg of sand 1km by
hand than it is to move one single 10,000kg rock 1km by hand. "Easier?" Yes,
but no one will actually want to do so either by hand if they have
other alternatives.
No one, except for the very very truly determined (a tiny sized population), will want to hand type that to maintain proper
air-gapping. So they will use USB sticks or other methods to "move"
the data, opening up the possibility of transfer of an exploit via that same USB stick.
A 3.5 ich disk drive and disk for it come in handy, because you hear
every read/write process
You hope. A NSA level attack could hide a microcontroller and several
GB of non-volatile memory on an otherwise normal looking interface
board. Some of the read/writes could then be redirected to/from that non-volatile memory.
Far fetched -- certianly not when such CPU's can be had from Amazon for $10.00.
Likely to happen to any individual - well, very unlikely, unless they
happen to also be in the NSA's crosshairs.
and can quickly examine the sectors with a disk editor.
The same exploited drive could perform a VW Dieselgate detection to
detect likely access by a disk editor (the access patterns will differ
vs. filesystem accesses) and return alternate contents or modify the
actual return from the disk surface to make you believe anything was
written to the sectors. So you'd have to disk edit read on another
machine that itself was not compromised in some way (and hope the NSA
didn't swap the drive in that machine for another comprimised one).
And -- I'm ignoring the fact that buying a newly manufactured in 2025
3.5" drive mechanism is all but impossible today.
Rich wrote:
Stefan Claas <stefan@mailchuck.com> wrote:
Stefan Claas wrote:
Rich wrote:
Stefan Claas <stefan@mailchuck.com> wrote:
Rich wrote:
And, how accurately do you think the average person who wants to send
an encrypted message will be at typing this:
KqHtqbSca2hvI02pCMHtdKQLfHhW6OeN7iK1Fg45nMpoT+to8XpwpvARkW6UziY0iyZWUEgP/gol
gz5p3XpGCe0hZbYV2IYYLDvvRjGWj1k5IHkDX4WshBZvI5fhVssJOqVI3bzqdEW3XLD4NoGKVQg3
ZeNaSJs2hBySnkBoKGI=
That's 128 random bytes, base64 encoded. 128 bytes is right about the
original "tweet length" of tweets on shitter, so there is a severe >> > > > > > limit of the amount of information that can be transferred.
That why I have my az and ug program for people available, but it uses 2
bytes, which should be no problem.
$ openssl rand 128 | az | ug -g
ZMAXT OPNWC LZWIF OQIMR PNNQV BFQLC BRZDA RUFBT ROLQS GOLKA
KKNJF ULBLO WINNL IIVVK FWTEE XRGBS UJCYS DCMWH JUMAA VLLNX
MJMYS LHSKG ENKLL LUGBN YNDSP AJYMO OXUBC YQNOY QMFYW ABOPH
NUVCJ KMFCM XKDVM EEXYL LVUKO VVGAU UACYV OHKUG GTVAA MWDLO
KCPYN HOWVM DPNHA ZMGHV MFIKW DILNO FYQHK VQELK OMFNL EOLTL
ETMPL S
Yes, easier to enter than raw base64. But in this case this "easier" >> > > > is like the fact that it is "easier" to move 10,000kg of sand 1km by >> > > > hand than it is to move one single 10,000kg rock 1km by hand. "Easier?" Yes,
but no one will actually want to do so either by hand if they have
other alternatives.
No one, except for the very very truly determined (a tiny sized
population), will want to hand type that to maintain proper
air-gapping. So they will use USB sticks or other methods to "move" >> > > > the data, opening up the possibility of transfer of an exploit via that
same USB stick.
A 3.5 ich disk drive and disk for it come in handy, because you hear
every read/write process and can quickly examine the sectors with a
disk editor.
Or better yet, a Telefax and mulitunction offline printer with scan
option for OCR and the offline PC. With a 16 point mono font you get
2000 chars with my az encoder and under Windows OCR is 100% reliably
scanned from an A4 page.
This is your best bet for making it such that all but the most
determined are possibly likely to use the system.
The air-gap machine has to have an integrated scanner and printer, and
OCR software (or else you need to use barcodes for input -- which might
be more reliable for input). The user would print the "code",
scan/read it on the airgap machine, decrypt, create return, encrypt,
and then print the encrypted version for input to the networked machine
for sending. You might at this point also want scan/ocr capability on
the network machine to read the printout and convert to digital data.
You often think to complicated or pessimisitc. Everyone can do it when
having a monthly income to purchase those devices. They are easier to
use than you think and it does not neet to been integrated, nor with a network machine.
Rich wrote:
Stefan Claas <stefan@mailchuck.com> wrote:
Rich wrote:
Stefan Claas <stefan@mailchuck.com> wrote:
Rich wrote:
And, how accurately do you think the average person who wants to send
an encrypted message will be at typing this:
KqHtqbSca2hvI02pCMHtdKQLfHhW6OeN7iK1Fg45nMpoT+to8XpwpvARkW6UziY0iyZWUEgP/gol
gz5p3XpGCe0hZbYV2IYYLDvvRjGWj1k5IHkDX4WshBZvI5fhVssJOqVI3bzqdEW3XLD4NoGKVQg3
ZeNaSJs2hBySnkBoKGI=
That's 128 random bytes, base64 encoded. 128 bytes is right about the
original "tweet length" of tweets on shitter, so there is a severe >> > > > > limit of the amount of information that can be transferred.
That why I have my az and ug program for people available, but it uses 2
bytes, which should be no problem.
$ openssl rand 128 | az | ug -g
ZMAXT OPNWC LZWIF OQIMR PNNQV BFQLC BRZDA RUFBT ROLQS GOLKA
KKNJF ULBLO WINNL IIVVK FWTEE XRGBS UJCYS DCMWH JUMAA VLLNX
MJMYS LHSKG ENKLL LUGBN YNDSP AJYMO OXUBC YQNOY QMFYW ABOPH
NUVCJ KMFCM XKDVM EEXYL LVUKO VVGAU UACYV OHKUG GTVAA MWDLO
KCPYN HOWVM DPNHA ZMGHV MFIKW DILNO FYQHK VQELK OMFNL EOLTL
ETMPL S
Yes, easier to enter than raw base64. But in this case this "easier"
is like the fact that it is "easier" to move 10,000kg of sand 1km by
hand than it is to move one single 10,000kg rock 1km by hand. "Easier?" Yes,
but no one will actually want to do so either by hand if they have
other alternatives.
No one, except for the very very truly determined (a tiny sized
population), will want to hand type that to maintain proper
air-gapping. So they will use USB sticks or other methods to "move"
the data, opening up the possibility of transfer of an exploit via that >> > > same USB stick.
A 3.5 ich disk drive and disk for it come in handy, because you hear
every read/write process
You hope. A NSA level attack could hide a microcontroller and several
GB of non-volatile memory on an otherwise normal looking interface
board. Some of the read/writes could then be redirected to/from that
non-volatile memory.
Far fetched -- certianly not when such CPU's can be had from Amazon for
$10.00.
Likely to happen to any individual - well, very unlikely, unless they
happen to also be in the NSA's crosshairs.
and can quickly examine the sectors with a disk editor.
The same exploited drive could perform a VW Dieselgate detection to
detect likely access by a disk editor (the access patterns will differ
vs. filesystem accesses) and return alternate contents or modify the
actual return from the disk surface to make you believe anything was
written to the sectors. So you'd have to disk edit read on another
machine that itself was not compromised in some way (and hope the NSA
didn't swap the drive in that machine for another comprimised one).
And -- I'm ignoring the fact that buying a newly manufactured in 2025
3.5" drive mechanism is all but impossible today.
What you always forget. the NSA can't snoop on onffline devices in Eurasia.
They can do that with US citizens in the US.
Chris M. Thomasson wrote:
On 7/7/2025 2:41 PM, Chris M. Thomasson wrote:
For instance:
https://github.com/nicksnyder/go-i18n
I see, but it scares me a little for all of this other code to be in there.
Try to compile (at a later date) with Go's fyne toolkit[1] and for now
use the provided Windows binary, I posted in the URL before.
And for the CLI version just cd into the folder and then
do: go build -ldflags "-s -w" which then produces an .exe of the
CLI version of minicrypt.
[1] https://apps.fyne.io/apps/oc2mx.net.minicrypt.html
Stefan Claas wrote:
Chris M. Thomasson wrote:
On 7/7/2025 2:41 PM, Chris M. Thomasson wrote:
For instance:
https://github.com/nicksnyder/go-i18n
I see, but it scares me a little for all of this other code to be in there.
Try to compile (at a later date) with Go's fyne toolkit[1] and for now
use the provided Windows binary, I posted in the URL before.
And for the CLI version just cd into the folder and then
do: go build -ldflags "-s -w" which then produces an .exe of the
CLI version of minicrypt.
[1] https://apps.fyne.io/apps/oc2mx.net.minicrypt.html
I have updated the GUI version, by shortining the error messages,
so that they do not stretch the GUI horizontally, in some cases.
You should re-download the code and compile again.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 146:15:30 |
| Calls: | 10,383 |
| Calls today: | 8 |
| Files: | 14,054 |
| D/L today: |
2 files (1,861K bytes) |
| Messages: | 6,417,699 |
