flat assembler
Message board for the users of flat assembler.

Index > Heap > simple auth server-client

Author
Thread Post new topic Reply to topic
b1528932



Joined: 21 May 2010
Posts: 287
b1528932
I need to verify if both endpoints of a connection are trusted (nobody is pretending to be on the other side).
So i came up with solution, using asymetric cipher, create 1 pair of keys for server, and 1 for each client.
Server will hold its secret key to sign data (encrypt it), and client decryption keys to decrypt client data and identify client.
Each client will get servers public key, just to encrypt data using it.
Each client also gets his own encryption key used to encrypt data.


Also each client would get pair of keys just to send normal data, after auth.
When someone crack one client he will be able to decrypt all traffic from server. This is not critical to auth itself, but when i send encryption key through cracked channel it would lose sense.

So client would know keys, 2 for auth, and 2 for data.
Server would also know 4 keys, 1 his own global, 3 per each client (auth + 2 data)

Or i could just make server encrypt data using clients key after auth.
Then after compromising only 1 client, others are secure since each has their own keys.

and the actual validation would look liek this:

1. client connects to a server
2. server send some random data to client in plain text
3. client encrypt this data with his own key, and add his own plain text data, then send
4. server using each clients key tries to decrypt first part of data, if it succeed, he trust the client
5. server encrypt second part of data client sent him, and send to client
6. if client successfully decrypt this data - it trust server
7. at this point communication is safe and secret

does it have some flaws?
when someone will hijack lower level session (for example tcp), the only thing he could do is gather all possible combinations of handshake packets (2^(8*key_length)), and then use them to fake each side. And this still would require him to crack servers or clients encryption key in order to view data.

Is it possible from mathematical and practical point of view to crack this?
Would you do it better?
Post 19 Dec 2010, 06:07
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
You can also just use the standard D-H exchange.

No need to reinvent the wheel here. The existing crypto is strong, well proven and vetted by experts.
Post 19 Dec 2010, 15:51
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Exactly. Either prove what's wrong with the normal way, or use it. "Custom" always means "bad" in security area. Thousands reviewers of open-source security invariably do better job than dozen paid experts.
Post 19 Dec 2010, 18:56
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
vid wrote:
Exactly. Either prove what's wrong with the normal way, or use it. "Custom" always means "bad" in security area. Thousands reviewers of open-source security invariably do better job than dozen paid experts.
This covers two aspects, which you seem to have mixed somewhat:

1) The underlying crypto: This is solved. There is no need for amateurs to try and create new unproven algos. Creating a new algo is something to be done very cautiously. Posting a new algo here on this board is completely pointless. It proves nothing about the security of the algo.

and,

2) The implementation: This is the really hard part. While anyone with a computer and a compiler can create their own implementation of a known strong algo, that does not automatically make your implementation strong. There are so many pitfalls and things that can go wrong.

Summary: Use the industry standard algos and implement them very very carefully. Where possible use code that is already established and widely regarded as good.

My post number 2^13
Post 20 Dec 2010, 01:45
View user's profile Send private message Visit poster's website Reply with quote
b1528932



Joined: 21 May 2010
Posts: 287
b1528932
so how should i do it?
what is the proven way?


i modyfied this:


- connection
- server send plain text
- client encrypt it with his key
- client send encrypted msg + his data
- server decrypt client half msg with all keys, when he finds client key, he trust him
- server encrypt 2nd half of data with his key and send to client
- client decrypt and check
- client now trust (or not) the server
- client generate pair of keys, and send server encryption eky
- server generate pair of keys, and send client encryption key

fully working secure communication, data exchange is done by using dynamicly generated keys


now i have a qurstion:
when i hijack a packet and i know whats in it (100% of dat i know), i can try encrypting it using diffrent keys untill it match. Is it ok? Can someone outside be aware of contwents of a packet, or should i always mix it with random data. Even if i do so, some parts of packet may be known, and attacker just filter out rest. So whast the safe key exchange algo?

Sorry for typos but its soo cold my fingers are frozen.
Post 20 Dec 2010, 09:06
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
b1528932 wrote:
so how should i do it?
what is the proven way?
D-H exchange protocol. It is simple and well documented.
Post 20 Dec 2010, 12:59
View user's profile Send private message Visit poster's website Reply with quote
b1528932



Joined: 21 May 2010
Posts: 287
b1528932
Ok i will look into it, but it has no auth wich i want to do.
I have to learn much about cryptograpfy, i dont understand how does it work.
I dont get the math behind it, especialy if its long text in english.


Maybe i change the subject:
i would like to create a asymetric cipher.
What math can i use to ensure that knowing public key someone wont find secret key?
What is there to prevent it? How does it work?
Post 20 Dec 2010, 13:39
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
b1528932 wrote:
i would like to create a asymetric cipher.
What math can i use to ensure that knowing public key someone wont find secret key?
What is there to prevent it? How does it work?
RSA is the simplest to understand. Plus there are lots of other schemes if for some reason RSA doesn't suit you. But for pretty much everyone RSA is the most widely used and the most studied.
Post 20 Dec 2010, 13:46
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
I guess this could be stated more clearly:

Use RSA for the authentication.
Use DH for the key exchange.
Use AES for the data encryption.
Post 20 Dec 2010, 20:15
View user's profile Send private message Visit poster's website Reply with quote
b1528932



Joined: 21 May 2010
Posts: 287
b1528932
When i use rsa for auth, there is no reason for using DH, i guess.
Because just after auth, i side lets say server can generate symmetric key, and send it to client (AES).

RSA is simple from math point of view. However implementation is impossible for me. I did it some time ago, and i remember that key must be greater than data im about to encrypt. How can i ensure, that my rsa key will always be greater, should i compare data about to be encrypted with key, and if data > key, when shrink data, compare again, and do it untill key is bigger?
What if key is very small, i know that it shouldnt, but what if. I access data as bytes, so for example if key would be 255, and data would be 1 byte 255, there is o way i send it.

So in RSA, when key is smaller than data, should i return error and drop connection? In my opinion connection drop shouldnt have happen in this case, because it will happen at 100%, key generation is random, sooner or later i hit small value and then what.
There is also possibility, that i setup minimum key length, and add frame tomy packet ensureing that its lower than key all the times. Worst case scenarion - infinite loop while trying to generate a key. Also bad.

So how do i manage it when i decide to go rsa?
What are other alternatives, wich do not care about data, just its ammount?
Post 21 Dec 2010, 04:15
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
b1528932 wrote:
When i use rsa for auth, there is no reason for using DH, i guess.
Because just after auth, i side lets say server can generate symmetric key, and send it to client (AES).
No you can't (unless you are not concerned about eavesdropping Confused).
b1528932 wrote:
RSA is simple from math point of view. However implementation is impossible for me. I did it some time ago, and i remember that key must be greater than data im about to encrypt. How can i ensure, that my rsa key will always be greater, should i compare data about to be encrypted with key, and if data > key, when shrink data, compare again, and do it untill key is bigger?
What if key is very small, i know that it shouldnt, but what if. I access data as bytes, so for example if key would be 255, and data would be 1 byte 255, there is o way i send it.

So in RSA, when key is smaller than data, should i return error and drop connection? In my opinion connection drop shouldnt have happen in this case, because it will happen at 100%, key generation is random, sooner or later i hit small value and then what.
There is also possibility, that i setup minimum key length, and add frame tomy packet ensureing that its lower than key all the times. Worst case scenarion - infinite loop while trying to generate a key. Also bad.

So how do i manage it when i decide to go rsa?
What are other alternatives, wich do not care about data, just its ammount?
No. All of that is a very bad idea. You have to use something like DH to transfer a key safely else you set yourself up for all sorts of serious security holes. Don't try to shortcut all the established protocols, they are there for very good reasons. Although the reasons why are far beyond the scope of this forum, but you can search for all the security analysis if you are interested.
Post 21 Dec 2010, 06:22
View user's profile Send private message Visit poster's website Reply with quote
b1528932



Joined: 21 May 2010
Posts: 287
b1528932
Quote:
No you can't (unless you are not concerned about eavesdropping ).

could you be more specyfic?

step 1: connection, nothing to evesdrop, attacker might add some tcp or ip options, change ips/ports, and so on

step 2: server send plain text, much of data, 1 MB for example, attacker might remember this data. If he change it, he will also have to change the response from client or server will fail to auth client.

step 3: client send this data encrypted using his key (asymetric). Attacker may now bruteforce plain text untill he get excat match. Is it security hole? I dont know, guess not. Client also send plain text in this step.
Server now tries all his decryption keys untill he find one that gives correct result, client is trusted. Server send encrypted data to client using his key. Attacker might again bruteforce agnist server encryption key.

step 4: client receive encrypted data, decrypt it and check if it match plain text it sent.

step 5: server generate pair of asymetric keys, send decryption to lient
client do the same in one time. Attacker might intercept those packets, but they are encrypted, and keys will be destroyed at the end of session anyway.

step 6: both sides destroy keys after session is finished

where its possible to evesdrop, actively or passivly?
When attacker receive plain text challenge from 1 side, he will have to know encryption key to deal with it. No key = wrong answer, disconnect.
All he could do is:
- bruteforce plain text packets (or any other packet that he know will ocntain specyfied data)
- capture all possible packets (2 to key_length_in_bits power), so if i use 1 MB challenge data, he will need 2^(1*1024*1024*Cool packets, each 1 MB. And thats just to pass auth, he will need key to exchange data, or much more packets, for each combination.

As i said, please be more specyfic about flaws in my algo. I cant find any bug other than cipher weaknesses (if any).
Post 21 Dec 2010, 08:09
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
b1528932 wrote:
could you be more specyfic?
No.
b1528932 wrote:
As i said, please be more specyfic about flaws in my algo. I cant find any bug other than cipher weaknesses (if any).
I am not an expert in crypto, and it seems neither are you, so either of us saying "it looks okay" means nothing. AFAIK no one else on this board is an expert either. But regardless, even if no one here can point out a problem that does not mean your algo is safe. You would have to have it analysed by a genuine recognised expert before you can know what might go wrong. There are very many things that can go wrong. Take some time to study previous breaks to give yourself an idea on how even subtle changes in a crypto scheme can render it trivial to break.

There is no sense in wasting your mental effort on creating new algos unless you are a true crypto expert (or want to become one). If you are only dong this to protect some communications data then just use the proven and industry standard algos. They are easy to code up and represent the best available crypto currently known. At least that way you won't have to worry about someone breaking the crypto, and you can concentrate upon the implementation details instead.
Post 21 Dec 2010, 08:28
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2915
Location: [RSP+8*5]
bitRAKE
There are many flaws in your algo (or, it is very hard to understand in the present form). How does the client get the key used in #3? The server only uses a static array of client key? Sound like both the encrypted (#4) and decrypted text (#2) is sent by server - not a good idea.

Please make a detailed list of what is secrete to server and what is secrete to client -- at each step. Only from there can we begin to determine the calculations required by an eavesdropper or man-in-middle.

The DH exchange page on Wikipedia is quite good - one concise example displayed in several ways.
Post 21 Dec 2010, 16:59
View user's profile Send private message Visit poster's website Reply with quote
b1528932



Joined: 21 May 2010
Posts: 287
b1528932
terminology for the sake of clarity:
CEK - Held by client, encrypt data.
CDK - Held by server, decrypt data.
SEK - Held by server, encrypt data.
SDK - Held by client, decrypt data.
pairs: CEK/CDK, SEK/SDK

Quote:
How does the client get the key used in #3?

step 3 is about providing authentyfication by client. Client use CEK1.


Quote:
Please make a detailed list of what is secrete to server and what is secrete to client -- at each step.

At the beggining, server knows only SEK1, and CDK1. Client knows only SDK1, and CEK1.
After auth ic complete, server generate CEK2/CDK2, and client SEK2/SDK2.
CEK2 and SDK2 are exchanged.

Quote:
The server only uses a static array of client key?

Not only. Static array CDK1/CDK2/CDK3/.../CDKn are used only to identify client, and after auth, SEK1 is used to send CEK2 key, and CDKn is used to decrypt SEK2 key.

Quote:
Sound like both the encrypted (#4) and decrypted text (#2) is sent by server

What do you mean? Server is sending only 1 portion of data in plain text, client is encrypting it using CEK1.
Post 22 Dec 2010, 08:21
View user's profile Send private message Reply with quote
b1528932



Joined: 21 May 2010
Posts: 287
b1528932
Lets assumg SDK1 is publicly know. Attacker might decrypt server auth sent to client in replay to plaintext, but he wont be able to forge one.
Also attacker will know CEK2 send to client, he might replace it with his own key (CEK3). When client encrypt data, he will use attackers key, meaning that attacker will be able to decrypt this data, encrypt using real CEK2 and send to server. Ok i admit its a flaw. Unless all sides are private, i guess.

Then im out of ideas for now, how can i safely transmit key. Dont point me to those DH thing just explain step by step general theory behind it, im having hard time understanding what wiki has about it.
Post 22 Dec 2010, 08:26
View user's profile Send private message Reply with quote
b1528932



Joined: 21 May 2010
Posts: 287
b1528932
Wait, how he would replace CEK2 without knowing SEK1? To protect anist replay attack, packet might hold for example data sent previously by client, or even combine those 2.

Well, client send plain text data for auth purpose, but he append encrypted SEK2 using CEK1. CEK1 is of course used 1 timwe on whole data.
Server do the same, when auth is done, both sides know each keys and there is no way someone can hack it.
When hacker send packet from previous session, 'plain' data wuldnt match, and the other side would reject side. Note that attacker has no way of encrypting data with his victims key, each client - unique key. When he will know clients key, he simple becomes him and no security is needed.
Post 22 Dec 2010, 08:40
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
I think this link is relevant. But beware, there be dragons within ...

http://www.schneier.com/crypto-gram-9810.html#cipherdesign
Post 24 Dec 2010, 09:54
View user's profile Send private message Visit poster's website Reply with quote
b1528932



Joined: 21 May 2010
Posts: 287
b1528932
Im not creating my own cipher, not now anyway, i know its hard to make unbreakable one. My goal for now is yo create library of same data exchange, using existent ciphers.
Post 24 Dec 2010, 11:13
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.