rev, to even begin to perform a Running Key Cipher crypto-analysis, you would need all but one of the keys and ciphertext, and either the shuffle or the transformations used.

What that means, is you need all but two of the secrets to even do crypto analysis to get a whiff of what's going on. You need all but one secret to laboriously decrypt.

With a 128-bit number, you have 2^128 possibilities, which are also quite prone to statistical analysis. For example, I can guarantee you that that key will never be 0. I understand it typically has something to do with prime factoring?

With a single 128 bit number I can keep it in my head (in the form of a password), it can't be stolen, I choose when to reveal it or not. With a secret in the algo and some reference text (and other whatnot) it is stored on your computer (or somewhere) and it can be stolen, you can't choose not to reveal it, the thief has it.

Ask yourself this question: "If my computer is stolen now, will I lose control of my data?". If you answer yes then you are at risk.

I challenge you to tell me why my password cannot be zero? All numbers are equally likely there is no pre-selection process. Zero has the same probability as all other numbers, 1/2^128. No system is fast enough to even count 2^128 numbers, let alone trying 2^128 decryptions.

How many possibilities do you have with your algo? Even if you have 1000000 algorithms to choose from and 1000000 texts to choose from you still fall way short of 2^128 possible selections.

This thread is bordering on rediculous.

TRUE STATEMENT
"A secret algorithm can improve security"

FALSE STATEMENT
"A secret algorithm is cryptographically more secure, than a documented/proven algorithm"


Saying my encrypted message is "asdfawfwvddzxvasd34g45j348jv"
Bet you'll never be able to figure out the original text IS ASININE. There's a difference between SECRECY and SECURITY.

some secutrity is not very important you know. cryptography and all with passwords is not a good mentality. it maens that people are bad, they have evil ideas in their little heads.

it is always possible to find a key, as it is a number / ??? then, if someone find the good one in 10 tries...
th eproblem is not cryptography, it is always possible to find a better algoryhtm, with many keys etc...
the problem is the people and mainly the business mentality, the one who govern our civilisation.

there is no country nowadays, one proof, we are all from various countries, and we act as if we was in the same land. fasm board

meaning what? meaning that we dont separate humans by religions or nationality, but by interrest.
we are not french, polish, american, but Assemblers, ourt country is this fuckin processor concept.

then, all is possible, and cryptography is only usefull in "war" context. economic war, social war, civil war, mondial war. when there are reason to be affraid of the opponent reaction.

cryptography today is used by who?

army, enemy reason ==> the opponent should not know what we say because it is a danger
states, confidence reasons ==> the people should not know what we say because he can become very angry and dangerous.
peoples, laws reasons ==> state should not know what we say because some laws forbit that and we risk some penalties.

cryptography is mainly a conscequence of misconfidence and insecurity.

Yeah, I guess we are getting a ways off topic and there's no real point to this discussion.

if you want in topic it is very easy.

the theory of cryptography is not very hard to understand. the hackers should not know what is our source code.
then, lets go for a lot of waste full functions inside the code. some layers, and some dirtycode.
no body can hack a dirty code.

If part of your security is reliant on keeping the algorithm secret then that is a FALSE STATEMENT. It becomes difficult to keep the algorithm a secret. The more places you keep the algorithm (in source code, in binaries, in backups etc.) the more chance there is of it being revealed. If you mean to keep it secret only to frustrate a hacker, but revelation won't have any major impact your security, then perhaps it can improve security a little.

On the contrary, there is a good point to trying to help people understand that putting secrets in an algorithm is NOT a way to improve security. It is too easy to lose the secrecy of that algorithm, by accident, misfortune, subterfuge, deception, theft, mistake, etc.

That is a FALSE STATEMENT. I raise the Vista DRM sillyness as an example of how easily code is hacked.

rev, I think you missed the point or key word "CAN".

Obviously using proprietary/secret encryption algorithms isn't a 'good' way to secure data (through secrecy), but it most certainly CAN improve security while the algorithm is still a secret.

Following hypothetical:
Think about an ATM (automated teller machine) it's illegal to tamper with them, they have cameras watching them, the encryption algorithm inside COULD be some proprietary toy without any validation by the cryptographic community. BUT by the virtue that it's a black box (secrecy) it can maintain SOME level of security/protection.

There's the right way and the wrong way to implement encryption. THe wrong way CAN work SOME of the time, but the right way will work MOST/ALL of the time. If you take your programming skill seriously learning the right way (validated, tested, publicly scrutinized algorithms) would behoove you.

Goals of a good cryptographic algorithm:
- Known answer resistant: if you know part of the message being encrypted it should still be difficult to decipher the remainder.
- State compromise resistant: if the current state of your algorithm is revealed, going in reverse to decrypt the ciphered message that has already been encrypted should not be any easier.
- Low weakness probability: the algorithm should have few keys that will produce weaker than normal results, and if keys are expanded, or a state is updated collisions should be avoided.

Okay, but it feels like a time bomb waiting to go off. "While it is a secret" makes me uncomfortable. What happens afterwards when it is no longer a secret? I think not actually. Because some people do know what is inside. Then you have to monitor those people to make sure they do not reveal the secrets. Plus, it only takes one fork-lift to remove an ATM and reverse whatever you want. The chain of installation and repair must also be monitored to make sure that no one there is copying out the algorithms for later inspection. It becomes very hard to keep that secret.

< my two cents worth > I think it's better to use a nice, secure algorithm that has been tested by the communities like the AES. Then, instead of lugging around so much information such as the algorithm used, the 'book' for the beale ciphers (or books, nonetheless), it wouold better to just have a small (sry Rev) key like 128-256 bits. Or an RSA of ~2048 bits, or a smaller ECC . There are endless possibilities for security.

I concede, however, I'd like to point out some flaws in your argument.

The point to this though was that you don't need additional data to use as a key. If your purpose is simply to obfuscate a program, you can readily use multiple sources of existing data.

The algorithm for transformation is simply a duff's device. It's not prime factoring, doesn't look complicated, doesn't draw attention, and in code it's small. It could easily be smaller than 256 bytes.

I also would like to state that I enjoy waffles. Especially with blackberries.

I say that everyone in the FASM community takes a day off, to have the world's largest ASSEMBLY WAFFLE TIME!!!! .

Think of it, hundreds of FASM coders all timing their efforts into engorging themselves of syruppy waffle goodness at perfect intervals accross the day. What could be better?

Pancakes!

home made pizzas! and bolognese pastas!

Rev, why does it matter how cryptographically secure the algorithm is? The algorithm and any keys it uses must be right there unencrypted so that they can run and unencrypt the program..


All that matters is how hard it is for crackers to understand it, no?

If it is not cryptographically secure then it can be broken without need to look at the decoding code. So all your efforts to obfuscate your decoder will be wasted if the main code can be decoded by some easier other method. You would probably want to ensure that any potential reverser will be forced to have to go through your ugly, weird and obfuscated code.

But, of course, this only slows people down. It is a fait accompli that it CAN be broken, so your only hope is to maximise the effort required by the reverser.

In other words your own weird private implementation of it

Not the one that was reviewed.

I don't get where some code "was reviewed"?

Are you talking about self-decoding .exe's? Because I replied based upon that assumption. If you are talking about general encryption, the what I said above does not apply because the key is not in the code.

I thought you were saying that the important thing is that lots of people have tested/reviewed it to make sure it's near impossible to decrypt without the key, so I was saying that this doesn't make sense for this since the key has to be there in the file, so whatever algo is more obscure is best.

The algo should be secure. But the implementation can be anything you like. You are free to make your implementation as obfuscated as you please. But obscurity is not real security, just a delay tactic. don't be tempted to fool yourself thinking an unknown algo is better simply because it is obscure and secret.