flat assembler
Message board for the users of flat assembler.

 Index > Main > String & Proc Encrypting Goto page Previous  1, 2, 3, 4, 5, 6  Next
Author
daniel.lewis

Joined: 28 Jan 2008
Posts: 92
daniel.lewis 23 Apr 2008, 08:21
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?

_________________
dd 0x90909090 ; problem solved.
23 Apr 2008, 08:21
revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20289
revolution 23 Apr 2008, 08:29
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.
23 Apr 2008, 08:29
r22

Joined: 27 Dec 2004
Posts: 805
r22 23 Apr 2008, 23:09
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.
23 Apr 2008, 23:09
edfed

Joined: 20 Feb 2006
Posts: 4330
Location: Now
edfed 23 Apr 2008, 23:56
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.

Last edited by edfed on 23 Apr 2008, 23:58; edited 1 time in total
23 Apr 2008, 23:56
daniel.lewis

Joined: 28 Jan 2008
Posts: 92
daniel.lewis 23 Apr 2008, 23:57
Yeah, I guess we are getting a ways off topic and there's no real point to this discussion.

_________________
dd 0x90909090 ; problem solved.
23 Apr 2008, 23:57
edfed

Joined: 20 Feb 2006
Posts: 4330
Location: Now
edfed 24 Apr 2008, 00:01
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.
24 Apr 2008, 00:01
revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20289
revolution 24 Apr 2008, 02:02
r22 wrote:
TRUE STATEMENT
"A secret algorithm can improve security"
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.

daniel.lewis wrote:
there's no real point to this discussion.
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.

edfed wrote:
no body can hack a dirty code.
That is a FALSE STATEMENT. I raise the Vista DRM sillyness as an example of how easily code is hacked.
24 Apr 2008, 02:02
r22

Joined: 27 Dec 2004
Posts: 805
r22 24 Apr 2008, 03:56
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.
24 Apr 2008, 03:56
revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20289
revolution 24 Apr 2008, 04:04
r22 wrote:
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.
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?
r22 wrote:
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.
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.
24 Apr 2008, 04:04
AlexP

Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP 24 Apr 2008, 12:53
< 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.
24 Apr 2008, 12:53
daniel.lewis

Joined: 28 Jan 2008
Posts: 92
daniel.lewis 24 Apr 2008, 23:55
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.

_________________
dd 0x90909090 ; problem solved.
24 Apr 2008, 23:55
AlexP

Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP 25 Apr 2008, 01:58
Quote:
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?
25 Apr 2008, 01:58
revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20289
revolution 25 Apr 2008, 02:06
AlexP wrote:
What could be better?
Pancakes!
25 Apr 2008, 02:06
edfed

Joined: 20 Feb 2006
Posts: 4330
Location: Now
edfed 25 Apr 2008, 02:09
revolution wrote:
AlexP wrote:
What could be better?
Pancakes!

home made pizzas! and bolognese pastas!
25 Apr 2008, 02:09
Azu

Joined: 16 Dec 2008
Posts: 1159
Azu 23 May 2009, 01:17
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?
23 May 2009, 01:17
revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20289
revolution 23 May 2009, 02:58
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.
23 May 2009, 02:58
Azu

Joined: 16 Dec 2008
Posts: 1159
Azu 23 May 2009, 03:01
revolution wrote:
You would probably want to ensure that any potential reverser will be forced to have to go through your ugly, weird and obfuscated code.
In other words your own weird private implementation of it

Not the one that was reviewed.
23 May 2009, 03:01
revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20289
revolution 23 May 2009, 03:06
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.
23 May 2009, 03:06
Azu

Joined: 16 Dec 2008
Posts: 1159
Azu 23 May 2009, 04:04
revolution wrote:
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.
23 May 2009, 04:04
revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20289
revolution 23 May 2009, 05:18
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.
23 May 2009, 05:18
 Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First

 Jump to: Select a forum Official----------------AssemblyPeripheria General----------------MainTutorials and ExamplesDOSWindowsLinuxUnixMenuetOS Specific----------------MacroinstructionsOS ConstructionIDE DevelopmentProjects and IdeasNon-x86 architecturesHigh Level LanguagesProgramming Language DesignCompiler Internals Other----------------FeedbackHeapTest Area
Goto page Previous  1, 2, 3, 4, 5, 6  Next

Forum Rules:
 You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum