Executables can be masked. PGP is great when the other user is already on it.

My counterparty will read a message but not install anything. They also trust me to run an executable. It can be a script (batch file) that runs an executable, so long there's no password and anything it runs doesn't have to be installed by the user.

Say, for example, we're using a Windows .zip utility.

I can include the utility with the message to run on files in the same folder.

Here's an example that might work:

https://www.computerhope.com/software/pkutil.htm

I think pk is commercial, but I might find an alternative with the same switch.

This is the kind of solution I'm looking for. It should be easier.

You need to build your own. You feel it will be easier. What have you done to try to build it? You asked about reference code to start this and have been offered suggestions. You seem to persist with claiming this should be simple and haven't apparently done any attempts to solve it.

I quoted a description of a function which demonstrates a lack of real world understanding of secure password handling.

If you care enough about security to not want even a temporary file created, you should heed that warning and focus on identifying existing tools that can be packaged/wrapped as needed.


To continue that analogy, just because you've used a screwdriver doesn't mean someone can't gain access using pliers, a thick piece of card, or even their fingers if the screwdriver wasn't used properly.

Sodium is a library that can be used to create secure software, if used correctly, but might only provide the illusion of security if the concepts involved are not understood.

I still do not understand what is it all about. But returning back to the very first post:
it looks like [for me] you want to send encrypted messages. I don't understand how is it related to windows, but anyway it is already solved, so you only need to pick a suitable solution: you can use [for example] gmail, or also you can create a password protected zip file. But do not try to reinvent the wheel.
Also you can use a [shared] cloud drive to store sensitive information and you only need to inform your friend to check it.

The overlaying premise is that you're trying to help answer my question. That's the structural goal of the forum and I personally appreciate it. In a public dialog there's also the issue of demonstrating and growing knowledge, and that's useful too.

Alas, it's burdensome to figure out exactly what I'm trying to do without appealing to conventions and the way the world appears from your seat, so the issue is more about communication than password security.

A quarter century ago this problem would have seemed technical, but today it's pedestrian. It simply presents unusual constraints.

No one would bother with this if there were a canned solution.

The level of encryption required is modest. What makes it modest is a lack of motive for anyone to intercept the data or coincidentally dig for it. But a completely unencrypted message in an e-mail or file container is too likely to be read by a third-party.

If I say I'm Telegram or Signal or WhatsApp and I'm offering security, I'm waving a "TARGET" flag.

Secondly, there's the burden of utilizing new services, and thirdly there's the issue of trusting the service itself.

The goal is simply transferring a scrambled message over the Internet that doesn't require skeptical work on the part of the receiver or involve 3rd parties, and I'm imagining how that can be done.

The advice about seeing text in compiled C ended this option, though I've come up with an alternative involving sending the deciphering executable, the message itself, and a script (batch) to execute it in an archive.

There are several ways (already working solutions):
S (sender) encrypts the message, R (receiver) will decrypt. Both need a tool to do the job. Usually mail programs have this feature.
S encrypts the message and creates a password protected self-extracting package, R only need to execute it (and need to know that password).
S and R use a common protected storage somewhere (in the cloud?).
S can create a web server (or some kind of service) and only R can access the data.

You can select which encryption tool do you want to use, but there are standards (and for example plugins for mail programs) which will work very well - and you will not be able to implement anything similar.
https://en.wikipedia.org/wiki/Email_encryption

This whole thread is moot.

You are focusing on just one aspect of security. However, security has many facets and there is more than one way to breach security. You sound like a beginner who is not aware of the vast depths of this subject and you only have a vague vision of an abstract solution which you are now trying to pull into reality. I do not mean this in an offensive way, it is just an observation. Alas, it is not that easy. There is a reason why IT security people have to study this subject for many years and there is a reason why those people proudly sprout their first grey hair at the ripe ol' age of 25.

From what you have described in your initial posts, you want a standalone application that embeds a message, i.e., every message is its own application! Nerdwise, it is interesting, it tickles the "nerd-bone". From a security standpoint it is garbage. Sorry for being blunt but it is. Every 3rd party that stores the "message" can switch it for an arbitray application, i.e., with every message the recipient has to execute an arbitrary binary. This is a huge security hole.

So this leaves us only with the "fun" option where (almost) anything goes. However, we cannot help you with that because

a) it would spoil all the fun for you

and

b) basic input/output are relatively "simple" concepts. If you cannot figure this out by yourself then you are most certainly NOT a nerd and you do not have a "nerd-bone" that needs to be tickled every now and then.

Which brings me back to my initial statement: This whole thread is moot.

Q.e.d.


PS:

Security - Brainwork = False sense of security!

So, what you are saying is that the recipient needs some kind of 3rd party software that is capable of extracting the archive?

There is a smorgasbord of encrypted messaging options. Quality is there. Constraints thwart them:

1. Mail readers and browser add-ons both require the recipient to install and learn plug-ins/apps and trust.
2. A self-extracting package needs to decipher without creating an output file and display it to screen. How?
3. Only encrypted document files are allowed in the cloud (e.g., last sentence of my last post solution). Otherwise this provides the transfer means.
4. Serves are useful but not required with the #3 cloud option.

I'm not trying to compete but fulfill a niche need which could be an opportunity for others.

Yes, but that's a Windows problem, not Linux.

I've noticed Windows now supports tar, which still doesn't support passwords. There's .zip functionality but not for this use.

OpenSSL could do this easily, but it has to be installed in Windows. Constraints.

If you want to use a non-existent feature you need to install something to make it available.

If you insist on sending the user a file via e-mail, at least use a format/language the recipient can easily read.

Send an .html file with a decryption routine written in JavaScript. Anyone with a browser can open that. Problem solved?

I went fishing (not phishing) just to learn what's in Windows. This is a Windows 10 machine though I almost always boot Linux. I didn't find command line zip, but tar yes and zip is gui available. If something were there, I could use it. Maybe there's another part of Windows 10 os that could be useful, but since it's not there or I haven't found it, I have to send the recipient the utility with the message.

It's less of a recipient burden to give them a utility with the message then to ask them to install something.

It's a lot different messaging Linux user to Linux user, both for the options available, and for the kind of people who are inclined to use it.

Sounds neat but I'm not that advanced, just a user, and I generally don't trust browsers. I do aesthetics more than most techs, but the message is what's important.

Oh. I guess the guy who started this thread asking for a "password template routine in C" must have been someone else.

How on earth is a few lines of JavaScript and HTML more "advanced" than C?
What?? But you do trust everything else on some user's Windows computer, to the point where you're suggesting sending them executable files via e-mail?

Have you just been wasting everybody's time?

1 members found this post helpful.

One of the main reasons I'm not technical is negative introductions, including Pascal instead of C.

Pascal's case was limited applicability. Everything I look at today is derived from C. It built a mountain.

So a semester in a class of Pascal with zero JavaScript experience gives me more C confidence. I've written HTML pages but I don't remember thinking about JS.

If you can put a JS password routine in a few lines, post it.

Understand after being smart, the next stage is a macro perspective, excluding chauvinism where it's not warranted.

Be a busy person with a close associate and while intelligent not in the frame of mind to start learning asymetric key encryption (my first suggestion) or new apps.

Easy with no technical thinking. There's no way I would infect their computer and everybody's brother uses the tool.

The other way to be smart is to achieve this same goal by different means adhering to the constraints.

password encrypted message - no deciphered files - no services/app installs/plug-ins/advanced command lines

If something should be possible, it's o-kay to wish for it.