nostr:npub15fkerqqyp9mlh7n8xd6d5k9s27etuvaarvnp2vqed83dw9c603pqs5j9gr there aren't that many schemes available so not knowing it would increase the complexity by maybe 20, so not as secure then knowing the scheme and just adding another character.
I am not entirely sure but I think that most encryption schemas just say what they are up front. The ones that don't are called Deniable. The only product I know that hides this is veracrypt.
You mean at the front of the byte stream? Like how keys in a key file will have prefix and postfix data saying what they are and who made them, or whatever.
I don't really know if individual encrypted files have that sort of thing, I've never inspected one. It seems like a bad idea if they do.
Otherwise if they just find an encrypted file lying around, something you're expected to explicitly run back through a decryption program and that can't decrypt itself, that would be hard to approach.
But speaking of the number of characters, how could they know at all? I see this implicit assumption made a lot in password discussions, and of course a longer password is more secure all else being equal. But if you just have an empty field to enter the password, and it can accept an arbitrary number of characters, how could you possibly know how many characters to try? You'd just have to start at 1 character and keep increasing, and so logically, the brute force would simply take longer to solve the longer password. But at a certain point of not-that-many-characters the amount of time required approaches the heat death of the universe.
