The encryption of a file requires secrets about the encryption. The more secrets exist the more secure is the encryption.
I appreciate your response so far. However, with all due respect to your moderation efforts on this forum, this view about encryption is flawed and dangerous (ed:
potentially dangerous if it's used to mask a weakness instead of fixing it).
As far as I recall the file encrypt mechanism has been in UltraEdit for a very long time, and in the absence of any information provided, how can I know whether insecure options are in use? I certainly can't say whether this function of the software meets minimum standards when checked against various infosec specifications.
(I.e. out of that list in my prior link, many of the combinations are no longer recommended due to significant weakness or having already been broken - how can we know whether one of these is in use? ... Ed: having said that, we've assumed here that a cryptography library reported by the ldd tool is even in use for the file encrypt function.)
UltraEdit should publish the details of the protocol in full, including the uenc format - there's no benefit to keeping this secret - the only secret relied upon should be the key (in this case: the input key material in the form of the user's secret password), and if the user willingly chooses a weak password then that is their own choice.
Every secure protocol that relies on modern cryptography also relies on this principle, having survived exposure to light of day, while countless others have perished or exist only on life-support (through mechanisms such as vpn or tunneling, wrapping, etc.)
