|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Socket Server with Encryption helpI've started to develop a server and client socket classes with encryption. The main communication/transport classes is working fine and now I will write some encryption process. After reading a lot of papers about Symmetric, Asymmetric, Hash, Envelope and Signature I still have somes doubts and I will explain what I calling the "Authenticate Flow" in client/server socket communication: 1. Client connects into Server and Server accepts the connection. 2. Server send his encryption public-key to Client. 3. Client creates a new symetric session-key, encrypt it using the Server encryption public-key and send it to Server plus the Client sign public-key. 4. Server decrypt Client symetric session-key and simply replies to Client, telling "Ok, I have the symetric session-key and your sign public-key". Now, every time Client need send some data, it does the following: 5. Client encrypts data with symetric session-key, sign (hash) the result with sign private-key. Client then sends the hash result and the encrypted data to server. 6. Server sign (hash) the encrypted data with the same Client hash algoritm and save it in Hash1. After, it decrypt the sign (hash) sended by client using Client sign public-key to obtain the Hash2. If Hash1 and Hash2 are the same, then is the correct Client. Otherwise, closes the connection. 7. If ok, Server then decrypt data with symetric session-key. Well, que questions now: A - The hash algoritm is know by the Client and Server since it's my implementation of both and I don't need to send the hash algoritm information. Is this acceptable? B - Sendind the Client sign public-key to Server is ok. But, after that, I'm sending some data using Client sign private-key to Server. Is this secure? Is a normal way to do it? C - Do I need to do the 5, 6 and 7 steps every time Client needs send some data to Server and vice-versa? Or these steps it's executed only once only certify the Client and, after that, both sides can send messages encrypted only with symetric session-key? Sorry for the long post. Any help will be apreciated TIA, -- Andre Azevedo You are trying to reinvent SSL. Why? SslStream is your friend.
Joe K. Show quoteHide quote "Andre Azevedo" <x***@xpto.com> wrote in message news:%23U1j2DtQGHA.3192@TK2MSFTNGP09.phx.gbl... > Hi all, > > I've started to develop a server and client socket classes with > encryption. The main communication/transport classes is working fine and > now I will write some encryption process. > After reading a lot of papers about Symmetric, Asymmetric, Hash, Envelope > and Signature I still have somes doubts and I will explain what I calling > the "Authenticate Flow" in client/server socket communication: > > 1. Client connects into Server and Server accepts the connection. > 2. Server send his encryption public-key to Client. > 3. Client creates a new symetric session-key, encrypt it using the Server > encryption public-key and send it to Server plus the Client sign > public-key. > 4. Server decrypt Client symetric session-key and simply replies to > Client, telling "Ok, I have the symetric session-key and your sign > public-key". > > Now, every time Client need send some data, it does the following: > > 5. Client encrypts data with symetric session-key, sign (hash) the result > with sign private-key. Client then sends the hash result and the encrypted > data to server. > 6. Server sign (hash) the encrypted data with the same Client hash > algoritm and save it in Hash1. After, it decrypt the sign (hash) sended by > client using Client sign public-key to obtain the Hash2. If Hash1 and > Hash2 are the same, then is the correct Client. Otherwise, closes the > connection. > 7. If ok, Server then decrypt data with symetric session-key. > > Well, que questions now: > > A - The hash algoritm is know by the Client and Server since it's my > implementation of both and I don't need to send the hash algoritm > information. Is this acceptable? > B - Sendind the Client sign public-key to Server is ok. But, after that, > I'm sending some data using Client sign private-key to Server. Is this > secure? Is a normal way to do it? > C - Do I need to do the 5, 6 and 7 steps every time Client needs send some > data to Server and vice-versa? Or these steps it's executed only once only > certify the Client and, after that, both sides can send messages encrypted > only with symetric session-key? > > Sorry for the long post. Any help will be apreciated > > TIA, > > -- > Andre Azevedo > > > > > Hi Mr Kaplan
No, I don't. But Can I generate RSA keys for each session and let the SslStream do the job? SslStream can be my friend but it's dumb. I don't know how to initiate a conversation it her. Is Vs2005 help enough? Show quoteHide quote "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> wrote in message news:%23akHDHtQGHA.4344@TK2MSFTNGP12.phx.gbl... > You are trying to reinvent SSL. Why? SslStream is your friend. > > Joe K. > > "Andre Azevedo" <x***@xpto.com> wrote in message > news:%23U1j2DtQGHA.3192@TK2MSFTNGP09.phx.gbl... >> Hi all, >> >> I've started to develop a server and client socket classes with >> encryption. The main communication/transport classes is working fine and >> now I will write some encryption process. >> After reading a lot of papers about Symmetric, Asymmetric, Hash, Envelope >> and Signature I still have somes doubts and I will explain what I calling >> the "Authenticate Flow" in client/server socket communication: >> >> 1. Client connects into Server and Server accepts the connection. >> 2. Server send his encryption public-key to Client. >> 3. Client creates a new symetric session-key, encrypt it using the Server >> encryption public-key and send it to Server plus the Client sign >> public-key. >> 4. Server decrypt Client symetric session-key and simply replies to >> Client, telling "Ok, I have the symetric session-key and your sign >> public-key". >> >> Now, every time Client need send some data, it does the following: >> >> 5. Client encrypts data with symetric session-key, sign (hash) the result >> with sign private-key. Client then sends the hash result and the >> encrypted data to server. >> 6. Server sign (hash) the encrypted data with the same Client hash >> algoritm and save it in Hash1. After, it decrypt the sign (hash) sended >> by client using Client sign public-key to obtain the Hash2. If Hash1 and >> Hash2 are the same, then is the correct Client. Otherwise, closes the >> connection. >> 7. If ok, Server then decrypt data with symetric session-key. >> >> Well, que questions now: >> >> A - The hash algoritm is know by the Client and Server since it's my >> implementation of both and I don't need to send the hash algoritm >> information. Is this acceptable? >> B - Sendind the Client sign public-key to Server is ok. But, after that, >> I'm sending some data using Client sign private-key to Server. Is this >> secure? Is a normal way to do it? >> C - Do I need to do the 5, 6 and 7 steps every time Client needs send >> some data to Server and vice-versa? Or these steps it's executed only >> once only certify the Client and, after that, both sides can send >> messages encrypted only with symetric session-key? >> >> Sorry for the long post. Any help will be apreciated >> >> TIA, >> >> -- >> Andre Azevedo >> >> >> >> >> > > Dominick has samples of using SslStream and NegotiateStream on his blog.
I'd start there. www.leastprivilege.com SslStream is based on the use of certificates. However, that is a good thing. You want a proven mechanism supported by lots of different implementations for doing the key exchange and crypto stuff. SSPI (which is what NegotiateStream and SslStream use under the hood) is quite capable of doing this stuff really well. It works for IIS with tons of different browser clients, right? If you want more background, the book Dominick suggested is very good. I thimk that might be useful for you as you seem to be interested in knowing how this stuff works. That might also give you an understanding as to why these types of problems are hard to solve and convince you that inventing your own protocol is a terrible idea. :) As Dominick also suggested, Valery may also stop by and tell you in great detail what the flaws in your original proposed solution are, but you'll get more depth from a book. Best of luck, Joe K. Show quoteHide quote "Andre Azevedo" <x***@xpto.com> wrote in message news:%23$ny$otQGHA.4908@TK2MSFTNGP10.phx.gbl... > Hi Mr Kaplan > > No, I don't. > But Can I generate RSA keys for each session and let the SslStream do > the job? SslStream can be my friend but it's dumb. I don't know how to > initiate a conversation it her. > Is Vs2005 help enough? > > "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> wrote > in message news:%23akHDHtQGHA.4344@TK2MSFTNGP12.phx.gbl... >> You are trying to reinvent SSL. Why? SslStream is your friend. >> >> Joe K. >> >> "Andre Azevedo" <x***@xpto.com> wrote in message >> news:%23U1j2DtQGHA.3192@TK2MSFTNGP09.phx.gbl... >>> Hi all, >>> >>> I've started to develop a server and client socket classes with >>> encryption. The main communication/transport classes is working fine and >>> now I will write some encryption process. >>> After reading a lot of papers about Symmetric, Asymmetric, Hash, >>> Envelope and Signature I still have somes doubts and I will explain what >>> I calling the "Authenticate Flow" in client/server socket communication: >>> >>> 1. Client connects into Server and Server accepts the connection. >>> 2. Server send his encryption public-key to Client. >>> 3. Client creates a new symetric session-key, encrypt it using the >>> Server encryption public-key and send it to Server plus the Client sign >>> public-key. >>> 4. Server decrypt Client symetric session-key and simply replies to >>> Client, telling "Ok, I have the symetric session-key and your sign >>> public-key". >>> >>> Now, every time Client need send some data, it does the following: >>> >>> 5. Client encrypts data with symetric session-key, sign (hash) the >>> result with sign private-key. Client then sends the hash result and the >>> encrypted data to server. >>> 6. Server sign (hash) the encrypted data with the same Client hash >>> algoritm and save it in Hash1. After, it decrypt the sign (hash) sended >>> by client using Client sign public-key to obtain the Hash2. If Hash1 and >>> Hash2 are the same, then is the correct Client. Otherwise, closes the >>> connection. >>> 7. If ok, Server then decrypt data with symetric session-key. >>> >>> Well, que questions now: >>> >>> A - The hash algoritm is know by the Client and Server since it's my >>> implementation of both and I don't need to send the hash algoritm >>> information. Is this acceptable? >>> B - Sendind the Client sign public-key to Server is ok. But, after that, >>> I'm sending some data using Client sign private-key to Server. Is this >>> secure? Is a normal way to do it? >>> C - Do I need to do the 5, 6 and 7 steps every time Client needs send >>> some data to Server and vice-versa? Or these steps it's executed only >>> once only certify the Client and, after that, both sides can send >>> messages encrypted only with symetric session-key? >>> >>> Sorry for the long post. Any help will be apreciated >>> >>> TIA, >>> >>> -- >>> Andre Azevedo >>> >>> >>> >>> >>> >> >> > > do you know that .NET 2.0 has support for secure channels and the NTLM, Kerberos
and SSL authentication protocols? from your post i can see that you don't have a lot of experience with crypto and secure channels? have you read schneier/ferguson "Practical Cryptography" ? I am sure that Valery will also provide you with more links and pointer than you can ever read :)) in general i would not recommend building your own authentication / secure communication system if you don't really have to. It also depends how secure this protocol should be.... from what i can see you are trying to build something similar to SSL... 2/3/5. public key? so you are planning to use raw keys? how will this be protected against man in the middle attacks? You would have to use some king of trust concept, like in X509 Certificates or some other form of secure key exchange - but you can't guarantee that just with raw keys. I am not really a crypto expert- but i can tell that won't work - again - if valery picks this up, you'll get extra special treatment :) --------------------------------------- Dominick Baier - DevelopMentor http://www.leastprivilege.com Show quoteHide quote > Hi all, > > I've started to develop a server and client socket classes with > encryption. > The main communication/transport classes is working fine and now I > will > write some encryption process. > After reading a lot of papers about Symmetric, Asymmetric, Hash, > Envelope > and Signature I still have somes doubts and I will explain what I > calling > the "Authenticate Flow" in client/server socket communication: > 1. Client connects into Server and Server accepts the connection. > 2. Server send his encryption public-key to Client. > 3. Client creates a new symetric session-key, encrypt it using the > Server > encryption public-key and send it to Server plus the Client sign > public-key. > 4. Server decrypt Client symetric session-key and simply replies to > Client, > telling "Ok, I have the symetric session-key and your sign > public-key". > Now, every time Client need send some data, it does the following: > > 5. Client encrypts data with symetric session-key, sign (hash) the > result > with sign private-key. Client then sends the hash result and the > encrypted > data to server. > 6. Server sign (hash) the encrypted data with the same Client hash > algoritm > and save it in Hash1. After, it decrypt the sign (hash) sended by > client > using Client sign public-key to obtain the Hash2. If Hash1 and Hash2 > are the > same, then is the correct Client. Otherwise, closes the connection. > 7. If ok, Server then decrypt data with symetric session-key. > Well, que questions now: > > A - The hash algoritm is know by the Client and Server since it's my > implementation of both and I don't need to send the hash algoritm > information. Is this acceptable? > B - Sendind the Client sign public-key to Server is ok. But, after > that, I'm > sending some data using Client sign private-key to Server. Is this > secure? > Is a normal way to do it? > C - Do I need to do the 5, 6 and 7 steps every time Client needs send > some > data to Server and vice-versa? Or these steps it's executed only once > only > certify the Client and, after that, both sides can send messages > encrypted > only with symetric session-key? > Sorry for the long post. Any help will be apreciated > > TIA, > > -- > Andre Azevedo Hi Mr Baier,
> do you know that .NET 2.0 has support for secure channels and the NTLM, I don't want remoting.> Kerberos and SSL authentication protocols? > from your post i can see that you don't have a lot of experience with No, never.> crypto and secure channels? > have you read schneier/ferguson "Practical Cryptography" ? No. where?> I am sure that Valery will also provide you with more links and pointer Who's Valery?> than you can ever read :)) > in general i would not recommend building your own authentication / secure Yes. But Can I generate RSA keys for each session and let the SslStream do > communication system if you don't really have to. > It also depends how secure this protocol should be.... > > from what i can see you are trying to build something similar to SSL... the job? Or I need to create a Certificate, put it on Windows, bla bla bla? > 2/3/5. public key? so you are planning to use raw keys? how will this be Public key, Asymmetric, RSA, SSL, X509 Certs....> protected against man in the middle attacks? You would have to use some > king of trust concept, like in X509 Certificates or some other form of > secure key exchange - but you can't guarantee that just with raw keys. > I am not really a crypto expert- but i can tell that won't work - again - Again. who's valery?> if valery picks this up, you'll get extra special treatment :) > Hi Mr Baier, This has nothing to do with Remoting - NegotiateStream implements NTLM and > >> do you know that .NET 2.0 has support for secure channels and the >> NTLM, Kerberos and SSL authentication protocols? >> > I don't want remoting. Kerberos over any Stream (e.g. a Socket) and SslStream does the same for SSL > that's not good. You should use a proven algorithm. go for SSL>> from your post i can see that you don't have a lot of experience with >> crypto and secure channels? >> > No, never. > www.amazon.com>> have you read schneier/ferguson "Practical Cryptography" ? >> > No. where? > A guy that hangs out here - he will tell you EXACTLY why it is a bad idea >> I am sure that Valery will also provide you with more links and >> pointer than you can ever read :)) >> > Who's Valery? to implement this on your own. > Just use SslStream - you don't need your own RSA keys at all - you always >> in general i would not recommend building your own authentication / >> secure >> communication system if you don't really have to. >> It also depends how secure this protocol should be.... >> from what i can see you are trying to build something similar to >> SSL... >> > Yes. But Can I generate RSA keys for each session and let the > SslStream do the job? Or I need to create a Certificate, put it on > Windows, bla bla bla? need Certificates for SSL. > ???>> 2/3/5. public key? so you are planning to use raw keys? how will this >> be protected against man in the middle attacks? You would have to use >> some king of trust concept, like in X509 Certificates or some other >> form of secure key exchange - but you can't guarantee that just with >> raw keys. >> > Public key, Asymmetric, RSA, SSL, X509 Certs.... > --------------------------------------->> I am not really a crypto expert- but i can tell that won't work - >> again - if valery picks this up, you'll get extra special treatment >> :) >> > Again. who's valery? > Dominick Baier - DevelopMentor http://www.leastprivilege.com Show quoteHide quote > Hi Mr Baier, > >> do you know that .NET 2.0 has support for secure channels and the >> NTLM, Kerberos and SSL authentication protocols? >> > I don't want remoting. > >> from your post i can see that you don't have a lot of experience with >> crypto and secure channels? >> > No, never. > >> have you read schneier/ferguson "Practical Cryptography" ? >> > No. where? > >> I am sure that Valery will also provide you with more links and >> pointer than you can ever read :)) >> > Who's Valery? > >> in general i would not recommend building your own authentication / >> secure >> communication system if you don't really have to. >> It also depends how secure this protocol should be.... >> from what i can see you are trying to build something similar to >> SSL... >> > Yes. But Can I generate RSA keys for each session and let the > SslStream do the job? Or I need to create a Certificate, put it on > Windows, bla bla bla? > >> 2/3/5. public key? so you are planning to use raw keys? how will this >> be protected against man in the middle attacks? You would have to use >> some king of trust concept, like in X509 Certificates or some other >> form of secure key exchange - but you can't guarantee that just with >> raw keys. >> > Public key, Asymmetric, RSA, SSL, X509 Certs.... > >> I am not really a crypto expert- but i can tell that won't work - >> again - if valery picks this up, you'll get extra special treatment >> :) >> > Again. who's valery? > Hi,
> This has nothing to do with Remoting - NegotiateStream implements NTLM and That's good! May be I can use NegotiateStream in a LAN/WAN and SSL in a > Kerberos over any Stream (e.g. a Socket) and SslStream does the same for > SSL public network. Thank you! Is a good reading? -- Andre Hi, (I'm valery :-)
After reading your post I got a very strong suspicion that regardless of your saying that you read "a lot of papers about Symmetric, Asymmetric, Hash, Envelope and Signature" you didn't read even distantly enough to be able to implement something even distantly secure. Authentication protocols are fiercely difficult to get right. The classical paper on three party authenticated protocols design was written by Needham and Schroeder "Using encryption for authentication in large networks of computers" in 1978, where they described several protocols, one of witch was modified, strengthened and extended a bit later to become what is now known as Kerberos. At the end of their paper, Needham and Schroeder wrote that "protocols such as those developed here are prone to extremely subtle errors that are unlikely to be detected in normal operations. The need for techniques to verify the correctness of such protocols is great." Since then it was many attempts to develop a formal protocol verification tools. When it concerns authentication protocols, the most successful is BAN logic that stays for the names of their creators Burrows, Abadi, Needham and was first described in their "A logic of authentication" 1990 paper that could be found here http://www.stanford.edu/class/cs259/papers/ban1990.pdf. BAN logic was successfully used for analyzing and detecting errors/redundancies in many authentication protocols such as Kerberos (redundancy), Needham-Shroeder (design problem), Denning-Saco (design problem) and many others (don't recall names from the top of my head, but there was quite a lot). Another well known formal method of analyzing protocol correctness was NRL protocol analyzer (Navy Research Laboratory). Here you can find more details on it: http://chacs.nrl.navy.mil/publications/CHACS/1994/1994meadows-pap.pdf With some extension to address problems of Denial of Service that could be found in another paper by Meadows "Formal Framework and Evaluation Method for Network Denial of Service" http://citeseer.ist.psu.edu/384.html Very good survey of formal methods of protocol analysis you can find here: http://www.csc.liv.ac.uk/~wiebe/pubs/Documents/survey.ps And you can check this my blog post for very quick point on single aspect of authentication protocol: http://www.harper.no/valery/PermaLink,guid,aa88fdd0-ac5c-4315-969a-6954b4e05ad7.aspx But frankly, I think that you really need a lot of cryptographic background before even starting reading papers on development of authentication protocols and think of implementing such protocols yourself! "Practical Cryptography" book, that was suggested to you earlier, could be a good starting point if you only need overall understanding of basic cryptographic problems and don't plan to make cryptography to be your specialty. However if you want cryptography to be your speciality you probably have to start with Bellare-Rogaway's "Introduction to Modern Cryptography" http://www-cse.ucsd.edu/~mihir/cse207/classnotes.html (online) After that, I'd highly recommend you to read Douglas Stinson's "Cryptography Theory and Practice" third edition (second edition doesn't contain chapters on protocols) http://www.amazon.com/gp/product/1584885084 (book) Good alternative (or addition) to Stinson's book is Wenbo Mao's "Modern Cryptography: Theory and Practice" is also a recommended reading at that stage. http://www.amazon.com/gp/product/0130669431 (book) After that you MUST! read Goldwasser-Bellare's "Lecture Notes on Cryptography" http://www.cs.ucsd.edu/users/mihir/papers/gb.html (online) If you want implement algorithms yourself - you should read encyclopedic "Handbook of Applied Cryptography" http://www.cacr.math.uwaterloo.ca/hac/ (available online and as printed book)After you done with it, for hardcore cryptography and protocol design work you'll need to read Goldreich's "Foundations of Cryptography" (draft is available online http://theory.lcs.mit.edu/~oded/frag.html, but I'll highly recommend to buy books http://www.amazon.com/gp/product/0521791723 http://www.amazon.com/gp/product/0521830842) Only after you done reading references above (and reading papers that are most often cited in references section of mentioned books, lections notes and papers), then you may try to implement your own authentication protocols, and I'm sure - you will not be asking the questions that you are asking today. From the other side, I would not recommend reading Schneier's "Applied Cryptography". His non-rigorous discussion of protocols and algorithms makes it very easy to miss (oversee) difficulties of designing them, plus there are a number of conceptual mistakes in some of his descriptions (that was mussed many times in discussions that you can find in Usenet groups and on Internet). Schneier's book was an attempt to create simple exposition to cryptography for developers; however by Schneier's own words it was a mistake. -Valery. http://www.harper.no/valery Show quoteHide quote "Andre Azevedo" <x***@xpto.com> wrote in message news:%23U1j2DtQGHA.3192@TK2MSFTNGP09.phx.gbl... > Hi all, > > I've started to develop a server and client socket classes with > encryption. The main communication/transport classes is working fine and > now I will write some encryption process. > After reading a lot of papers about Symmetric, Asymmetric, Hash, Envelope > and Signature I still have somes doubts and I will explain what I calling > the "Authenticate Flow" in client/server socket communication: > > 1. Client connects into Server and Server accepts the connection. > 2. Server send his encryption public-key to Client. > 3. Client creates a new symetric session-key, encrypt it using the Server > encryption public-key and send it to Server plus the Client sign > public-key. > 4. Server decrypt Client symetric session-key and simply replies to > Client, telling "Ok, I have the symetric session-key and your sign > public-key". > > Now, every time Client need send some data, it does the following: > > 5. Client encrypts data with symetric session-key, sign (hash) the result > with sign private-key. Client then sends the hash result and the encrypted > data to server. > 6. Server sign (hash) the encrypted data with the same Client hash > algoritm and save it in Hash1. After, it decrypt the sign (hash) sended by > client using Client sign public-key to obtain the Hash2. If Hash1 and > Hash2 are the same, then is the correct Client. Otherwise, closes the > connection. > 7. If ok, Server then decrypt data with symetric session-key. > > Well, que questions now: > > A - The hash algoritm is know by the Client and Server since it's my > implementation of both and I don't need to send the hash algoritm > information. Is this acceptable? > B - Sendind the Client sign public-key to Server is ok. But, after that, > I'm sending some data using Client sign private-key to Server. Is this > secure? Is a normal way to do it? > C - Do I need to do the 5, 6 and 7 steps every time Client needs send some > data to Server and vice-versa? Or these steps it's executed only once only > certify the Client and, after that, both sides can send messages encrypted > only with symetric session-key? > > Sorry for the long post. Any help will be apreciated > > TIA, > > -- > Andre Azevedo > > > > > Hi Valery,
Thanks for the post. But, remember, I don't want to create new methods of encrypt, etc. I just want to put some encrypt mechaninsm in my TCP server/client implementation using EXISTING classes from .Net Framework 2.0. I wrote those steps based in a RSACryptoServiceProvider for asymmetric and maybe RijndaelManaged for symmetric keys as my application needs to authenticate a lot of clients in differents networks. Before the client sends data, it authenticate and encrypts the message. If SslStream does the job, ok, I'll use it. Thanks again, -- Show quoteHide quoteAndre "Valery Pryamikov" <val***@harper.no> wrote in message news:%23g0PWFvQGHA.4976@TK2MSFTNGP11.phx.gbl... > Hi, (I'm valery :-) > > > > After reading your post I got a very strong suspicion that regardless of > your saying that you read "a lot of papers about Symmetric, Asymmetric, > Hash, Envelope and Signature" you didn't read even distantly enough to be > able to implement something even distantly secure. > > Authentication protocols are fiercely difficult to get right. The > classical paper on three party authenticated protocols design was written > by Needham and Schroeder "Using encryption for authentication in large > networks of computers" in 1978, where they described several protocols, > one of witch was modified, strengthened and extended a bit later to become > what is now known as Kerberos. At the end of their paper, Needham and > Schroeder wrote that "protocols such as those developed here are prone to > extremely subtle errors that are unlikely to be detected in normal > operations. The need for techniques to verify the correctness of such > protocols is great." Since then it was many attempts to develop a formal > protocol verification tools. When it concerns authentication protocols, > the most successful is BAN logic that stays for the names of their > creators Burrows, Abadi, Needham and was first described in their "A logic > of authentication" 1990 paper that could be found here > http://www.stanford.edu/class/cs259/papers/ban1990.pdf. BAN logic was > successfully used for analyzing and detecting errors/redundancies in many > authentication protocols such as Kerberos (redundancy), Needham-Shroeder > (design problem), Denning-Saco (design problem) and many others (don't > recall names from the top of my head, but there was quite a lot). > > Another well known formal method of analyzing protocol correctness was NRL > protocol analyzer (Navy Research Laboratory). Here you can find more > details on it: > > http://chacs.nrl.navy.mil/publications/CHACS/1994/1994meadows-pap.pdf > > With some extension to address problems of Denial of Service that could be > found in another paper by Meadows "Formal Framework and Evaluation Method > for Network Denial of Service" http://citeseer.ist.psu.edu/384.html > > > > Very good survey of formal methods of protocol analysis you can find here: > http://www.csc.liv.ac.uk/~wiebe/pubs/Documents/survey.ps > > > > And you can check this my blog post for very quick point on single aspect > of authentication protocol: > http://www.harper.no/valery/PermaLink,guid,aa88fdd0-ac5c-4315-969a-6954b4e05ad7.aspx > > > > But frankly, I think that you really need a lot of cryptographic > background before even starting reading papers on development of > authentication protocols and think of implementing such protocols > yourself! > > > > "Practical Cryptography" book, that was suggested to you earlier, could be > a good starting point if you only need overall understanding of basic > cryptographic problems and don't plan to make cryptography to be your > specialty. > > > > However if you want cryptography to be your speciality you probably have > to start with Bellare-Rogaway's "Introduction to Modern Cryptography" > http://www-cse.ucsd.edu/~mihir/cse207/classnotes.html (online) > > After that, I'd highly recommend you to read Douglas Stinson's > "Cryptography Theory and Practice" third edition (second edition doesn't > contain chapters on protocols) http://www.amazon.com/gp/product/1584885084 > (book) > > Good alternative (or addition) to Stinson's book is Wenbo Mao's "Modern > Cryptography: Theory and Practice" is also a recommended reading at that > stage. > > http://www.amazon.com/gp/product/0130669431 (book) > > > > After that you MUST! read Goldwasser-Bellare's "Lecture Notes on > Cryptography" http://www.cs.ucsd.edu/users/mihir/papers/gb.html (online) > > > > If you want implement algorithms yourself - you should read encyclopedic > "Handbook of Applied Cryptography" http://www.cacr.math.uwaterloo.ca/hac/ > (available online and as printed book) > > > > After you done with it, for hardcore cryptography and protocol design work > you'll need to read Goldreich's "Foundations of Cryptography" (draft is > available online http://theory.lcs.mit.edu/~oded/frag.html, but I'll > highly recommend to buy books http://www.amazon.com/gp/product/0521791723 > > http://www.amazon.com/gp/product/0521830842) > > > > Only after you done reading references above (and reading papers that are > most often cited in references section of mentioned books, lections notes > and papers), then you may try to implement your own authentication > protocols, and I'm sure - you will not be asking the questions that you > are asking today. > > > > From the other side, I would not recommend reading Schneier's "Applied > Cryptography". His non-rigorous discussion of protocols and algorithms > makes it very easy to miss (oversee) difficulties of designing them, plus > there are a number of conceptual mistakes in some of his descriptions > (that was mussed many times in discussions that you can find in Usenet > groups and on Internet). Schneier's book was an attempt to create simple > exposition to cryptography for developers; however by Schneier's own words > it was a mistake. > > > > -Valery. > > http://www.harper.no/valery > > > > "Andre Azevedo" <x***@xpto.com> wrote in message > news:%23U1j2DtQGHA.3192@TK2MSFTNGP09.phx.gbl... >> Hi all, >> >> I've started to develop a server and client socket classes with >> encryption. The main communication/transport classes is working fine and >> now I will write some encryption process. >> After reading a lot of papers about Symmetric, Asymmetric, Hash, Envelope >> and Signature I still have somes doubts and I will explain what I calling >> the "Authenticate Flow" in client/server socket communication: >> >> 1. Client connects into Server and Server accepts the connection. >> 2. Server send his encryption public-key to Client. >> 3. Client creates a new symetric session-key, encrypt it using the Server >> encryption public-key and send it to Server plus the Client sign >> public-key. >> 4. Server decrypt Client symetric session-key and simply replies to >> Client, telling "Ok, I have the symetric session-key and your sign >> public-key". >> >> Now, every time Client need send some data, it does the following: >> >> 5. Client encrypts data with symetric session-key, sign (hash) the result >> with sign private-key. Client then sends the hash result and the >> encrypted data to server. >> 6. Server sign (hash) the encrypted data with the same Client hash >> algoritm and save it in Hash1. After, it decrypt the sign (hash) sended >> by client using Client sign public-key to obtain the Hash2. If Hash1 and >> Hash2 are the same, then is the correct Client. Otherwise, closes the >> connection. >> 7. If ok, Server then decrypt data with symetric session-key. >> >> Well, que questions now: >> >> A - The hash algoritm is know by the Client and Server since it's my >> implementation of both and I don't need to send the hash algoritm >> information. Is this acceptable? >> B - Sendind the Client sign public-key to Server is ok. But, after that, >> I'm sending some data using Client sign private-key to Server. Is this >> secure? Is a normal way to do it? >> C - Do I need to do the 5, 6 and 7 steps every time Client needs send >> some data to Server and vice-versa? Or these steps it's executed only >> once only certify the Client and, after that, both sides can send >> messages encrypted only with symetric session-key? >> >> Sorry for the long post. Any help will be apreciated >> >> TIA, >> >> -- >> Andre Azevedo >> >> >> >> >> > > But, remember, I don't want to create new methods of encrypt, etc. The thing is that protocols are more difficult than encryption!Encryption is easy. We know how to do encryption very well! There is well established framework of formal poof of security properties of encryption schemes. That security proof takes care of any kind of attacks (including yet unknown) as long as these attacks don't break related hard problem, such as solving discrete logarithm in a field of points on elliptic curve in poly-time, factoring in poly-time or decoding arbitrary linear error correction codes (which would be a major breakthrough in coding theory and could be used as base of proof that NP!=P - one of the major millennia problems with 1000000 USD bounty from Clay Mathematic institute). Protocols are much more delicate and difficult than encryption. There is no established technology that allows assessing security properties of protocols in a similar way as it could be done with encryption. Reductionist security framework could only be applied to a small subset of simpler protocols, while as formal logic proof doesn't give any assessment of protocol security, but only logical correctness. If you want to test your self - here is one of the simplest, most basic and well known authentication protocols http://www.harper.no/valery/PermaLink,guid,942e4a14-714f-41e9-8f4b-af20782b8b02.aspx. That protocol has a major security problem which was discovered more than 10 years after it was suggested and studied by academic community. You know that there is a major flaw - so it will be much easier for you to spot the flaw than it was before flaw was discovered - but try to find it without reading comments or searching answers on the web and you will see it for yourself. I can give you many other protocols that have major flaws, but these flaws are even more difficult to spot (partially because some of them may require more mathematic background). -Valery http://www.harper.no/valery Andre Azevedo wrote: Show quoteHide quote > Hi Valery, > > Thanks for the post. > But, remember, I don't want to create new methods of encrypt, etc. I just > want to put some encrypt mechaninsm in my TCP server/client implementation > using EXISTING classes from .Net Framework 2.0. > > I wrote those steps based in a RSACryptoServiceProvider for asymmetric and > maybe RijndaelManaged for symmetric keys as my application needs to > authenticate a lot of clients in differents networks. Before the client > sends data, it authenticate and encrypts the message. > > If SslStream does the job, ok, I'll use it. > > Thanks again, > > -- > Andre > > > "Valery Pryamikov" <val***@harper.no> wrote in message > news:%23g0PWFvQGHA.4976@TK2MSFTNGP11.phx.gbl... > > Hi, (I'm valery :-) > > > > > > > > After reading your post I got a very strong suspicion that regardless of > > your saying that you read "a lot of papers about Symmetric, Asymmetric, > > Hash, Envelope and Signature" you didn't read even distantly enough to be > > able to implement something even distantly secure. > > > > Authentication protocols are fiercely difficult to get right. The > > classical paper on three party authenticated protocols design was written > > by Needham and Schroeder "Using encryption for authentication in large > > networks of computers" in 1978, where they described several protocols, > > one of witch was modified, strengthened and extended a bit later to become > > what is now known as Kerberos. At the end of their paper, Needham and > > Schroeder wrote that "protocols such as those developed here are prone to > > extremely subtle errors that are unlikely to be detected in normal > > operations. The need for techniques to verify the correctness of such > > protocols is great." Since then it was many attempts to develop a formal > > protocol verification tools. When it concerns authentication protocols, > > the most successful is BAN logic that stays for the names of their > > creators Burrows, Abadi, Needham and was first described in their "A logic > > of authentication" 1990 paper that could be found here > > http://www.stanford.edu/class/cs259/papers/ban1990.pdf. BAN logic was > > successfully used for analyzing and detecting errors/redundancies in many > > authentication protocols such as Kerberos (redundancy), Needham-Shroeder > > (design problem), Denning-Saco (design problem) and many others (don't > > recall names from the top of my head, but there was quite a lot). > > > > Another well known formal method of analyzing protocol correctness was NRL > > protocol analyzer (Navy Research Laboratory). Here you can find more > > details on it: > > > > http://chacs.nrl.navy.mil/publications/CHACS/1994/1994meadows-pap.pdf > > > > With some extension to address problems of Denial of Service that could be > > found in another paper by Meadows "Formal Framework and Evaluation Method > > for Network Denial of Service" http://citeseer.ist.psu.edu/384.html > > > > > > > > Very good survey of formal methods of protocol analysis you can find here: > > http://www.csc.liv.ac.uk/~wiebe/pubs/Documents/survey.ps > > > > > > > > And you can check this my blog post for very quick point on single aspect > > of authentication protocol: > > http://www.harper.no/valery/PermaLink,guid,aa88fdd0-ac5c-4315-969a-6954b4e05ad7.aspx > > > > > > > > But frankly, I think that you really need a lot of cryptographic > > background before even starting reading papers on development of > > authentication protocols and think of implementing such protocols > > yourself! > > > > > > > > "Practical Cryptography" book, that was suggested to you earlier, could be > > a good starting point if you only need overall understanding of basic > > cryptographic problems and don't plan to make cryptography to be your > > specialty. > > > > > > > > However if you want cryptography to be your speciality you probably have > > to start with Bellare-Rogaway's "Introduction to Modern Cryptography" > > http://www-cse.ucsd.edu/~mihir/cse207/classnotes.html (online) > > > > After that, I'd highly recommend you to read Douglas Stinson's > > "Cryptography Theory and Practice" third edition (second edition doesn't > > contain chapters on protocols) http://www.amazon.com/gp/product/1584885084 > > (book) > > > > Good alternative (or addition) to Stinson's book is Wenbo Mao's "Modern > > Cryptography: Theory and Practice" is also a recommended reading at that > > stage. > > > > http://www.amazon.com/gp/product/0130669431 (book) > > > > > > > > After that you MUST! read Goldwasser-Bellare's "Lecture Notes on > > Cryptography" http://www.cs.ucsd.edu/users/mihir/papers/gb.html (online) > > > > > > > > If you want implement algorithms yourself - you should read encyclopedic > > "Handbook of Applied Cryptography" http://www.cacr.math.uwaterloo.ca/hac/ > > (available online and as printed book) > > > > > > > > After you done with it, for hardcore cryptography and protocol design work > > you'll need to read Goldreich's "Foundations of Cryptography" (draft is > > available online http://theory.lcs.mit.edu/~oded/frag.html, but I'll > > highly recommend to buy books http://www.amazon.com/gp/product/0521791723 > > > > http://www.amazon.com/gp/product/0521830842) > > > > > > > > Only after you done reading references above (and reading papers that are > > most often cited in references section of mentioned books, lections notes > > and papers), then you may try to implement your own authentication > > protocols, and I'm sure - you will not be asking the questions that you > > are asking today. > > > > > > > > From the other side, I would not recommend reading Schneier's "Applied > > Cryptography". His non-rigorous discussion of protocols and algorithms > > makes it very easy to miss (oversee) difficulties of designing them, plus > > there are a number of conceptual mistakes in some of his descriptions > > (that was mussed many times in discussions that you can find in Usenet > > groups and on Internet). Schneier's book was an attempt to create simple > > exposition to cryptography for developers; however by Schneier's own words > > it was a mistake. > > > > > > > > -Valery. > > > > http://www.harper.no/valery > > > > > > > > "Andre Azevedo" <x***@xpto.com> wrote in message > > news:%23U1j2DtQGHA.3192@TK2MSFTNGP09.phx.gbl... > >> Hi all, > >> > >> I've started to develop a server and client socket classes with > >> encryption. The main communication/transport classes is working fine and > >> now I will write some encryption process. > >> After reading a lot of papers about Symmetric, Asymmetric, Hash, Envelope > >> and Signature I still have somes doubts and I will explain what I calling > >> the "Authenticate Flow" in client/server socket communication: > >> > >> 1. Client connects into Server and Server accepts the connection. > >> 2. Server send his encryption public-key to Client. > >> 3. Client creates a new symetric session-key, encrypt it using the Server > >> encryption public-key and send it to Server plus the Client sign > >> public-key. > >> 4. Server decrypt Client symetric session-key and simply replies to > >> Client, telling "Ok, I have the symetric session-key and your sign > >> public-key". > >> > >> Now, every time Client need send some data, it does the following: > >> > >> 5. Client encrypts data with symetric session-key, sign (hash) the result > >> with sign private-key. Client then sends the hash result and the > >> encrypted data to server. > >> 6. Server sign (hash) the encrypted data with the same Client hash > >> algoritm and save it in Hash1. After, it decrypt the sign (hash) sended > >> by client using Client sign public-key to obtain the Hash2. If Hash1 and > >> Hash2 are the same, then is the correct Client. Otherwise, closes the > >> connection. > >> 7. If ok, Server then decrypt data with symetric session-key. > >> > >> Well, que questions now: > >> > >> A - The hash algoritm is know by the Client and Server since it's my > >> implementation of both and I don't need to send the hash algoritm > >> information. Is this acceptable? > >> B - Sendind the Client sign public-key to Server is ok. But, after that, > >> I'm sending some data using Client sign private-key to Server. Is this > >> secure? Is a normal way to do it? > >> C - Do I need to do the 5, 6 and 7 steps every time Client needs send > >> some data to Server and vice-versa? Or these steps it's executed only > >> once only certify the Client and, after that, both sides can send > >> messages encrypted only with symetric session-key? > >> > >> Sorry for the long post. Any help will be apreciated > >> > >> TIA, > >> > >> -- > >> Andre Azevedo > >> > >> > >> > >> > >> > > ...and another thing I forgot.
Nobody answer me the 3 questions! -- Show quoteHide quoteAndre "Valery Pryamikov" <val***@harper.no> wrote in message news:%23g0PWFvQGHA.4976@TK2MSFTNGP11.phx.gbl... > Hi, (I'm valery :-) > > > > After reading your post I got a very strong suspicion that regardless of > your saying that you read "a lot of papers about Symmetric, Asymmetric, > Hash, Envelope and Signature" you didn't read even distantly enough to be > able to implement something even distantly secure. > > Authentication protocols are fiercely difficult to get right. The > classical paper on three party authenticated protocols design was written > by Needham and Schroeder "Using encryption for authentication in large > networks of computers" in 1978, where they described several protocols, > one of witch was modified, strengthened and extended a bit later to become > what is now known as Kerberos. At the end of their paper, Needham and > Schroeder wrote that "protocols such as those developed here are prone to > extremely subtle errors that are unlikely to be detected in normal > operations. The need for techniques to verify the correctness of such > protocols is great." Since then it was many attempts to develop a formal > protocol verification tools. When it concerns authentication protocols, > the most successful is BAN logic that stays for the names of their > creators Burrows, Abadi, Needham and was first described in their "A logic > of authentication" 1990 paper that could be found here > http://www.stanford.edu/class/cs259/papers/ban1990.pdf. BAN logic was > successfully used for analyzing and detecting errors/redundancies in many > authentication protocols such as Kerberos (redundancy), Needham-Shroeder > (design problem), Denning-Saco (design problem) and many others (don't > recall names from the top of my head, but there was quite a lot). > > Another well known formal method of analyzing protocol correctness was NRL > protocol analyzer (Navy Research Laboratory). Here you can find more > details on it: > > http://chacs.nrl.navy.mil/publications/CHACS/1994/1994meadows-pap.pdf > > With some extension to address problems of Denial of Service that could be > found in another paper by Meadows "Formal Framework and Evaluation Method > for Network Denial of Service" http://citeseer.ist.psu.edu/384.html > > > > Very good survey of formal methods of protocol analysis you can find here: > http://www.csc.liv.ac.uk/~wiebe/pubs/Documents/survey.ps > > > > And you can check this my blog post for very quick point on single aspect > of authentication protocol: > http://www.harper.no/valery/PermaLink,guid,aa88fdd0-ac5c-4315-969a-6954b4e05ad7.aspx > > > > But frankly, I think that you really need a lot of cryptographic > background before even starting reading papers on development of > authentication protocols and think of implementing such protocols > yourself! > > > > "Practical Cryptography" book, that was suggested to you earlier, could be > a good starting point if you only need overall understanding of basic > cryptographic problems and don't plan to make cryptography to be your > specialty. > > > > However if you want cryptography to be your speciality you probably have > to start with Bellare-Rogaway's "Introduction to Modern Cryptography" > http://www-cse.ucsd.edu/~mihir/cse207/classnotes.html (online) > > After that, I'd highly recommend you to read Douglas Stinson's > "Cryptography Theory and Practice" third edition (second edition doesn't > contain chapters on protocols) http://www.amazon.com/gp/product/1584885084 > (book) > > Good alternative (or addition) to Stinson's book is Wenbo Mao's "Modern > Cryptography: Theory and Practice" is also a recommended reading at that > stage. > > http://www.amazon.com/gp/product/0130669431 (book) > > > > After that you MUST! read Goldwasser-Bellare's "Lecture Notes on > Cryptography" http://www.cs.ucsd.edu/users/mihir/papers/gb.html (online) > > > > If you want implement algorithms yourself - you should read encyclopedic > "Handbook of Applied Cryptography" http://www.cacr.math.uwaterloo.ca/hac/ > (available online and as printed book) > > > > After you done with it, for hardcore cryptography and protocol design work > you'll need to read Goldreich's "Foundations of Cryptography" (draft is > available online http://theory.lcs.mit.edu/~oded/frag.html, but I'll > highly recommend to buy books http://www.amazon.com/gp/product/0521791723 > > http://www.amazon.com/gp/product/0521830842) > > > > Only after you done reading references above (and reading papers that are > most often cited in references section of mentioned books, lections notes > and papers), then you may try to implement your own authentication > protocols, and I'm sure - you will not be asking the questions that you > are asking today. > > > > From the other side, I would not recommend reading Schneier's "Applied > Cryptography". His non-rigorous discussion of protocols and algorithms > makes it very easy to miss (oversee) difficulties of designing them, plus > there are a number of conceptual mistakes in some of his descriptions > (that was mussed many times in discussions that you can find in Usenet > groups and on Internet). Schneier's book was an attempt to create simple > exposition to cryptography for developers; however by Schneier's own words > it was a mistake. > > > > -Valery. > > http://www.harper.no/valery > > > > "Andre Azevedo" <x***@xpto.com> wrote in message > news:%23U1j2DtQGHA.3192@TK2MSFTNGP09.phx.gbl... >> Hi all, >> >> I've started to develop a server and client socket classes with >> encryption. The main communication/transport classes is working fine and >> now I will write some encryption process. >> After reading a lot of papers about Symmetric, Asymmetric, Hash, Envelope >> and Signature I still have somes doubts and I will explain what I calling >> the "Authenticate Flow" in client/server socket communication: >> >> 1. Client connects into Server and Server accepts the connection. >> 2. Server send his encryption public-key to Client. >> 3. Client creates a new symetric session-key, encrypt it using the Server >> encryption public-key and send it to Server plus the Client sign >> public-key. >> 4. Server decrypt Client symetric session-key and simply replies to >> Client, telling "Ok, I have the symetric session-key and your sign >> public-key". >> >> Now, every time Client need send some data, it does the following: >> >> 5. Client encrypts data with symetric session-key, sign (hash) the result >> with sign private-key. Client then sends the hash result and the >> encrypted data to server. >> 6. Server sign (hash) the encrypted data with the same Client hash >> algoritm and save it in Hash1. After, it decrypt the sign (hash) sended >> by client using Client sign public-key to obtain the Hash2. If Hash1 and >> Hash2 are the same, then is the correct Client. Otherwise, closes the >> connection. >> 7. If ok, Server then decrypt data with symetric session-key. >> >> Well, que questions now: >> >> A - The hash algoritm is know by the Client and Server since it's my >> implementation of both and I don't need to send the hash algoritm >> information. Is this acceptable? >> B - Sendind the Client sign public-key to Server is ok. But, after that, >> I'm sending some data using Client sign private-key to Server. Is this >> secure? Is a normal way to do it? >> C - Do I need to do the 5, 6 and 7 steps every time Client needs send >> some data to Server and vice-versa? Or these steps it's executed only >> once only certify the Client and, after that, both sides can send >> messages encrypted only with symetric session-key? >> >> Sorry for the long post. Any help will be apreciated >> >> TIA, >> >> -- >> Andre Azevedo >> >> >> >> >> > yes, because your design is TOTALLY flawed - it does not makes sense to answer
them without giving you an intro to crypto and secure channels. The usage of raw RSA keys alone would get you in big trouble. I can only recommend reading the Schneier book ("Practical Cryptography") - as Valery says this is a good intro and afterwards you'll know that you don't want to do that on your own - because it is far more complex than what you describe in your "authentication" flow. --------------------------------------- Dominick Baier - DevelopMentor http://www.leastprivilege.com Show quoteHide quote > ..and another thing I forgot. > Nobody answer me the 3 questions! > -- > Andre > "Valery Pryamikov" <val***@harper.no> wrote in message > news:%23g0PWFvQGHA.4976@TK2MSFTNGP11.phx.gbl... > >> Hi, (I'm valery :-) >> >> After reading your post I got a very strong suspicion that regardless >> of your saying that you read "a lot of papers about Symmetric, >> Asymmetric, Hash, Envelope and Signature" you didn't read even >> distantly enough to be able to implement something even distantly >> secure. >> >> Authentication protocols are fiercely difficult to get right. The >> classical paper on three party authenticated protocols design was >> written by Needham and Schroeder "Using encryption for authentication >> in large networks of computers" in 1978, where they described several >> protocols, one of witch was modified, strengthened and extended a bit >> later to become what is now known as Kerberos. At the end of their >> paper, Needham and Schroeder wrote that "protocols such as those >> developed here are prone to extremely subtle errors that are unlikely >> to be detected in normal operations. The need for techniques to >> verify the correctness of such protocols is great." Since then it was >> many attempts to develop a formal protocol verification tools. When >> it concerns authentication protocols, the most successful is BAN >> logic that stays for the names of their creators Burrows, Abadi, >> Needham and was first described in their "A logic of authentication" >> 1990 paper that could be found here >> http://www.stanford.edu/class/cs259/papers/ban1990.pdf. BAN logic was >> successfully used for analyzing and detecting errors/redundancies in >> many authentication protocols such as Kerberos (redundancy), >> Needham-Shroeder (design problem), Denning-Saco (design problem) and >> many others (don't recall names from the top of my head, but there >> was quite a lot). >> >> Another well known formal method of analyzing protocol correctness >> was NRL protocol analyzer (Navy Research Laboratory). Here you can >> find more details on it: >> >> http://chacs.nrl.navy.mil/publications/CHACS/1994/1994meadows-pap.pdf >> >> With some extension to address problems of Denial of Service that >> could be found in another paper by Meadows "Formal Framework and >> Evaluation Method for Network Denial of Service" >> http://citeseer.ist.psu.edu/384.html >> >> Very good survey of formal methods of protocol analysis you can find >> here: http://www.csc.liv.ac.uk/~wiebe/pubs/Documents/survey.ps >> >> And you can check this my blog post for very quick point on single >> aspect of authentication protocol: >> http://www.harper.no/valery/PermaLink,guid,aa88fdd0-ac5c-4315-969a-69 >> 54b4e05ad7.aspx >> >> But frankly, I think that you really need a lot of cryptographic >> background before even starting reading papers on development of >> authentication protocols and think of implementing such protocols >> yourself! >> >> "Practical Cryptography" book, that was suggested to you earlier, >> could be a good starting point if you only need overall understanding >> of basic cryptographic problems and don't plan to make cryptography >> to be your specialty. >> >> However if you want cryptography to be your speciality you probably >> have to start with Bellare-Rogaway's "Introduction to Modern >> Cryptography" http://www-cse.ucsd.edu/~mihir/cse207/classnotes.html >> (online) >> >> After that, I'd highly recommend you to read Douglas Stinson's >> "Cryptography Theory and Practice" third edition (second edition >> doesn't contain chapters on protocols) >> http://www.amazon.com/gp/product/1584885084 (book) >> >> Good alternative (or addition) to Stinson's book is Wenbo Mao's >> "Modern Cryptography: Theory and Practice" is also a recommended >> reading at that stage. >> >> http://www.amazon.com/gp/product/0130669431 (book) >> >> After that you MUST! read Goldwasser-Bellare's "Lecture Notes on >> Cryptography" http://www.cs.ucsd.edu/users/mihir/papers/gb.html >> (online) >> >> If you want implement algorithms yourself - you should read >> encyclopedic "Handbook of Applied Cryptography" >> http://www.cacr.math.uwaterloo.ca/hac/ (available online and as >> printed book) >> >> After you done with it, for hardcore cryptography and protocol design >> work you'll need to read Goldreich's "Foundations of Cryptography" >> (draft is available online http://theory.lcs.mit.edu/~oded/frag.html, >> but I'll highly recommend to buy books >> http://www.amazon.com/gp/product/0521791723 >> >> http://www.amazon.com/gp/product/0521830842) >> >> Only after you done reading references above (and reading papers that >> are most often cited in references section of mentioned books, >> lections notes and papers), then you may try to implement your own >> authentication protocols, and I'm sure - you will not be asking the >> questions that you are asking today. >> >> From the other side, I would not recommend reading Schneier's >> "Applied Cryptography". His non-rigorous discussion of protocols and >> algorithms makes it very easy to miss (oversee) difficulties of >> designing them, plus there are a number of conceptual mistakes in >> some of his descriptions (that was mussed many times in discussions >> that you can find in Usenet groups and on Internet). Schneier's book >> was an attempt to create simple exposition to cryptography for >> developers; however by Schneier's own words it was a mistake. >> >> -Valery. >> >> http://www.harper.no/valery >> >> "Andre Azevedo" <x***@xpto.com> wrote in message >> news:%23U1j2DtQGHA.3192@TK2MSFTNGP09.phx.gbl... >> >>> Hi all, >>> >>> I've started to develop a server and client socket classes with >>> encryption. The main communication/transport classes is working fine >>> and >>> now I will write some encryption process. >>> After reading a lot of papers about Symmetric, Asymmetric, Hash, >>> Envelope >>> and Signature I still have somes doubts and I will explain what I >>> calling >>> the "Authenticate Flow" in client/server socket communication: >>> 1. Client connects into Server and Server accepts the connection. >>> 2. Server send his encryption public-key to Client. >>> 3. Client creates a new symetric session-key, encrypt it using the >>> Server >>> encryption public-key and send it to Server plus the Client sign >>> public-key. >>> 4. Server decrypt Client symetric session-key and simply replies to >>> Client, telling "Ok, I have the symetric session-key and your sign >>> public-key". >>> Now, every time Client need send some data, it does the following: >>> >>> 5. Client encrypts data with symetric session-key, sign (hash) the >>> result >>> with sign private-key. Client then sends the hash result and the >>> encrypted data to server. >>> 6. Server sign (hash) the encrypted data with the same Client hash >>> algoritm and save it in Hash1. After, it decrypt the sign (hash) >>> sended >>> by client using Client sign public-key to obtain the Hash2. If Hash1 >>> and >>> Hash2 are the same, then is the correct Client. Otherwise, closes >>> the >>> connection. >>> 7. If ok, Server then decrypt data with symetric session-key. >>> Well, que questions now: >>> >>> A - The hash algoritm is know by the Client and Server since it's my >>> implementation of both and I don't need to send the hash algoritm >>> information. Is this acceptable? >>> B - Sendind the Client sign public-key to Server is ok. But, after >>> that, >>> I'm sending some data using Client sign private-key to Server. Is >>> this >>> secure? Is a normal way to do it? >>> C - Do I need to do the 5, 6 and 7 steps every time Client needs >>> send >>> some data to Server and vice-versa? Or these steps it's executed >>> only >>> once only certify the Client and, after that, both sides can send >>> messages encrypted only with symetric session-key? >>> Sorry for the long post. Any help will be apreciated >>> >>> TIA, >>> >>> -- >>> Andre Azevedo Well, you are telling me that anyone who wants to do this kind of job needs
to read "Practical Cryptography". I can't do any kind of encrypt because I don't know how it works. I think Microsoft must put an advice on Cryptography namespace sayng: "Please, read the "Practical Cryptography" before continue or you can create a flawed kind of monster." This is a problem since there are a lot of examples in internet and none of them puts an advice about the "Practical Cryptography", and any mortal can read the MSDN and starts to do something. But don't worry. I'm stopping the development and buying some 3rd party product to do the job. Thanks, -- Show quoteHide quoteAndre "Dominick Baier [DevelopMentor]" <dbaier@pleasepleasenospamdevelop.com> wrote in message news:4580be63197e3d8c8119f7da6aeb5@news.microsoft.com... > yes, because your design is TOTALLY flawed - it does not makes sense to > answer them without giving you an intro to crypto and secure channels. The > usage of raw RSA keys alone would get you in big trouble. > > I can only recommend reading the Schneier book ("Practical > Cryptography") - as Valery says this is a good intro and afterwards you'll > know that you don't want to do that on your own - because it is far more > complex than what you describe in your "authentication" flow. > > --------------------------------------- > Dominick Baier - DevelopMentor > http://www.leastprivilege.com > >> ..and another thing I forgot. >> Nobody answer me the 3 questions! >> -- >> Andre >> "Valery Pryamikov" <val***@harper.no> wrote in message >> news:%23g0PWFvQGHA.4976@TK2MSFTNGP11.phx.gbl... >> >>> Hi, (I'm valery :-) >>> >>> After reading your post I got a very strong suspicion that regardless >>> of your saying that you read "a lot of papers about Symmetric, >>> Asymmetric, Hash, Envelope and Signature" you didn't read even >>> distantly enough to be able to implement something even distantly >>> secure. >>> >>> Authentication protocols are fiercely difficult to get right. The >>> classical paper on three party authenticated protocols design was >>> written by Needham and Schroeder "Using encryption for authentication >>> in large networks of computers" in 1978, where they described several >>> protocols, one of witch was modified, strengthened and extended a bit >>> later to become what is now known as Kerberos. At the end of their >>> paper, Needham and Schroeder wrote that "protocols such as those >>> developed here are prone to extremely subtle errors that are unlikely >>> to be detected in normal operations. The need for techniques to >>> verify the correctness of such protocols is great." Since then it was >>> many attempts to develop a formal protocol verification tools. When >>> it concerns authentication protocols, the most successful is BAN >>> logic that stays for the names of their creators Burrows, Abadi, >>> Needham and was first described in their "A logic of authentication" >>> 1990 paper that could be found here >>> http://www.stanford.edu/class/cs259/papers/ban1990.pdf. BAN logic was >>> successfully used for analyzing and detecting errors/redundancies in >>> many authentication protocols such as Kerberos (redundancy), >>> Needham-Shroeder (design problem), Denning-Saco (design problem) and >>> many others (don't recall names from the top of my head, but there >>> was quite a lot). >>> >>> Another well known formal method of analyzing protocol correctness >>> was NRL protocol analyzer (Navy Research Laboratory). Here you can >>> find more details on it: >>> >>> http://chacs.nrl.navy.mil/publications/CHACS/1994/1994meadows-pap.pdf >>> >>> With some extension to address problems of Denial of Service that >>> could be found in another paper by Meadows "Formal Framework and >>> Evaluation Method for Network Denial of Service" >>> http://citeseer.ist.psu.edu/384.html >>> >>> Very good survey of formal methods of protocol analysis you can find >>> here: http://www.csc.liv.ac.uk/~wiebe/pubs/Documents/survey.ps >>> >>> And you can check this my blog post for very quick point on single >>> aspect of authentication protocol: >>> http://www.harper.no/valery/PermaLink,guid,aa88fdd0-ac5c-4315-969a-69 >>> 54b4e05ad7.aspx >>> >>> But frankly, I think that you really need a lot of cryptographic >>> background before even starting reading papers on development of >>> authentication protocols and think of implementing such protocols >>> yourself! >>> >>> "Practical Cryptography" book, that was suggested to you earlier, >>> could be a good starting point if you only need overall understanding >>> of basic cryptographic problems and don't plan to make cryptography >>> to be your specialty. >>> >>> However if you want cryptography to be your speciality you probably >>> have to start with Bellare-Rogaway's "Introduction to Modern >>> Cryptography" http://www-cse.ucsd.edu/~mihir/cse207/classnotes.html >>> (online) >>> >>> After that, I'd highly recommend you to read Douglas Stinson's >>> "Cryptography Theory and Practice" third edition (second edition >>> doesn't contain chapters on protocols) >>> http://www.amazon.com/gp/product/1584885084 (book) >>> >>> Good alternative (or addition) to Stinson's book is Wenbo Mao's >>> "Modern Cryptography: Theory and Practice" is also a recommended >>> reading at that stage. >>> >>> http://www.amazon.com/gp/product/0130669431 (book) >>> >>> After that you MUST! read Goldwasser-Bellare's "Lecture Notes on >>> Cryptography" http://www.cs.ucsd.edu/users/mihir/papers/gb.html >>> (online) >>> >>> If you want implement algorithms yourself - you should read >>> encyclopedic "Handbook of Applied Cryptography" >>> http://www.cacr.math.uwaterloo.ca/hac/ (available online and as >>> printed book) >>> >>> After you done with it, for hardcore cryptography and protocol design >>> work you'll need to read Goldreich's "Foundations of Cryptography" >>> (draft is available online http://theory.lcs.mit.edu/~oded/frag.html, >>> but I'll highly recommend to buy books >>> http://www.amazon.com/gp/product/0521791723 >>> >>> http://www.amazon.com/gp/product/0521830842) >>> >>> Only after you done reading references above (and reading papers that >>> are most often cited in references section of mentioned books, >>> lections notes and papers), then you may try to implement your own >>> authentication protocols, and I'm sure - you will not be asking the >>> questions that you are asking today. >>> >>> From the other side, I would not recommend reading Schneier's >>> "Applied Cryptography". His non-rigorous discussion of protocols and >>> algorithms makes it very easy to miss (oversee) difficulties of >>> designing them, plus there are a number of conceptual mistakes in >>> some of his descriptions (that was mussed many times in discussions >>> that you can find in Usenet groups and on Internet). Schneier's book >>> was an attempt to create simple exposition to cryptography for >>> developers; however by Schneier's own words it was a mistake. >>> >>> -Valery. >>> >>> http://www.harper.no/valery >>> >>> "Andre Azevedo" <x***@xpto.com> wrote in message >>> news:%23U1j2DtQGHA.3192@TK2MSFTNGP09.phx.gbl... >>> >>>> Hi all, >>>> >>>> I've started to develop a server and client socket classes with >>>> encryption. The main communication/transport classes is working fine >>>> and >>>> now I will write some encryption process. >>>> After reading a lot of papers about Symmetric, Asymmetric, Hash, >>>> Envelope >>>> and Signature I still have somes doubts and I will explain what I >>>> calling >>>> the "Authenticate Flow" in client/server socket communication: >>>> 1. Client connects into Server and Server accepts the connection. >>>> 2. Server send his encryption public-key to Client. >>>> 3. Client creates a new symetric session-key, encrypt it using the >>>> Server >>>> encryption public-key and send it to Server plus the Client sign >>>> public-key. >>>> 4. Server decrypt Client symetric session-key and simply replies to >>>> Client, telling "Ok, I have the symetric session-key and your sign >>>> public-key". >>>> Now, every time Client need send some data, it does the following: >>>> >>>> 5. Client encrypts data with symetric session-key, sign (hash) the >>>> result >>>> with sign private-key. Client then sends the hash result and the >>>> encrypted data to server. >>>> 6. Server sign (hash) the encrypted data with the same Client hash >>>> algoritm and save it in Hash1. After, it decrypt the sign (hash) >>>> sended >>>> by client using Client sign public-key to obtain the Hash2. If Hash1 >>>> and >>>> Hash2 are the same, then is the correct Client. Otherwise, closes >>>> the >>>> connection. >>>> 7. If ok, Server then decrypt data with symetric session-key. >>>> Well, que questions now: >>>> >>>> A - The hash algoritm is know by the Client and Server since it's my >>>> implementation of both and I don't need to send the hash algoritm >>>> information. Is this acceptable? >>>> B - Sendind the Client sign public-key to Server is ok. But, after >>>> that, >>>> I'm sending some data using Client sign private-key to Server. Is >>>> this >>>> secure? Is a normal way to do it? >>>> C - Do I need to do the 5, 6 and 7 steps every time Client needs >>>> send >>>> some data to Server and vice-versa? Or these steps it's executed >>>> only >>>> once only certify the Client and, after that, both sides can send >>>> messages encrypted only with symetric session-key? >>>> Sorry for the long post. Any help will be apreciated >>>> >>>> TIA, >>>> >>>> -- >>>> Andre Azevedo > > See my earlier reply to you.
here is the summary is: if you want a protocol - use a standard protocol! You can even implement it yourself as long as you don't change anything in the protocol. if you want to invent your own protocol - "Practical Cryptography" would not be enough! prepare yourself to spend several years reading before you can actually produce something secure. Bottom line: follow Dominick's advice and use SslStream! -Valery http://www.harper.no/valery You don't have to buy a 3rd party product - SslStream is part of .NET 2.0
A Valery said - the crypto classes are easy - combining them to a secure protocol is the hard part. You are of course free to hurt yourself with some home brewn protocol - but you asked us - and we answered. --------------------------------------- Dominick Baier - DevelopMentor http://www.leastprivilege.com Show quoteHide quote > Well, you are telling me that anyone who wants to do this kind of job > needs > to read "Practical Cryptography". > I can't do any kind of encrypt because I don't know how it works. > I think Microsoft must put an advice on Cryptography namespace sayng: > "Please, read the "Practical Cryptography" before continue or you can > create a flawed kind of monster." This is a problem since there are a > lot of examples in internet and none of them puts an advice about the > "Practical Cryptography", and any mortal can read the MSDN and starts > to do something. > > But don't worry. I'm stopping the development and buying some 3rd > party product to do the job. > > Thanks, > > -- > Andre > "Dominick Baier [DevelopMentor]" > <dbaier@pleasepleasenospamdevelop.com> wrote in message > news:4580be63197e3d8c8119f7da6aeb5@news.microsoft.com... > >> yes, because your design is TOTALLY flawed - it does not makes sense >> to answer them without giving you an intro to crypto and secure >> channels. The usage of raw RSA keys alone would get you in big >> trouble. >> >> I can only recommend reading the Schneier book ("Practical >> Cryptography") - as Valery says this is a good intro and afterwards >> you'll know that you don't want to do that on your own - because it >> is far more complex than what you describe in your "authentication" >> flow. >> >> --------------------------------------- >> Dominick Baier - DevelopMentor >> http://www.leastprivilege.com >>> ..and another thing I forgot. >>> Nobody answer me the 3 questions! >>> -- >>> Andre >>> "Valery Pryamikov" <val***@harper.no> wrote in message >>> news:%23g0PWFvQGHA.4976@TK2MSFTNGP11.phx.gbl... >>>> Hi, (I'm valery :-) >>>> >>>> After reading your post I got a very strong suspicion that >>>> regardless of your saying that you read "a lot of papers about >>>> Symmetric, Asymmetric, Hash, Envelope and Signature" you didn't >>>> read even distantly enough to be able to implement something even >>>> distantly secure. >>>> >>>> Authentication protocols are fiercely difficult to get right. The >>>> classical paper on three party authenticated protocols design was >>>> written by Needham and Schroeder "Using encryption for >>>> authentication in large networks of computers" in 1978, where they >>>> described several protocols, one of witch was modified, >>>> strengthened and extended a bit later to become what is now known >>>> as Kerberos. At the end of their paper, Needham and Schroeder wrote >>>> that "protocols such as those developed here are prone to extremely >>>> subtle errors that are unlikely to be detected in normal >>>> operations. The need for techniques to verify the correctness of >>>> such protocols is great." Since then it was many attempts to >>>> develop a formal protocol verification tools. When it concerns >>>> authentication protocols, the most successful is BAN logic that >>>> stays for the names of their creators Burrows, Abadi, Needham and >>>> was first described in their "A logic of authentication" 1990 paper >>>> that could be found here >>>> http://www.stanford.edu/class/cs259/papers/ban1990.pdf. BAN logic >>>> was successfully used for analyzing and detecting >>>> errors/redundancies in many authentication protocols such as >>>> Kerberos (redundancy), Needham-Shroeder (design problem), >>>> Denning-Saco (design problem) and many others (don't recall names >>>> from the top of my head, but there was quite a lot). >>>> >>>> Another well known formal method of analyzing protocol correctness >>>> was NRL protocol analyzer (Navy Research Laboratory). Here you can >>>> find more details on it: >>>> >>>> http://chacs.nrl.navy.mil/publications/CHACS/1994/1994meadows-pap.p >>>> df >>>> >>>> With some extension to address problems of Denial of Service that >>>> could be found in another paper by Meadows "Formal Framework and >>>> Evaluation Method for Network Denial of Service" >>>> http://citeseer.ist.psu.edu/384.html >>>> >>>> Very good survey of formal methods of protocol analysis you can >>>> find here: http://www.csc.liv.ac.uk/~wiebe/pubs/Documents/survey.ps >>>> >>>> And you can check this my blog post for very quick point on single >>>> aspect of authentication protocol: >>>> http://www.harper.no/valery/PermaLink,guid,aa88fdd0-ac5c-4315-969a- >>>> 69 54b4e05ad7.aspx >>>> >>>> But frankly, I think that you really need a lot of cryptographic >>>> background before even starting reading papers on development of >>>> authentication protocols and think of implementing such protocols >>>> yourself! >>>> >>>> "Practical Cryptography" book, that was suggested to you earlier, >>>> could be a good starting point if you only need overall >>>> understanding of basic cryptographic problems and don't plan to >>>> make cryptography to be your specialty. >>>> >>>> However if you want cryptography to be your speciality you probably >>>> have to start with Bellare-Rogaway's "Introduction to Modern >>>> Cryptography" http://www-cse.ucsd.edu/~mihir/cse207/classnotes.html >>>> (online) >>>> >>>> After that, I'd highly recommend you to read Douglas Stinson's >>>> "Cryptography Theory and Practice" third edition (second edition >>>> doesn't contain chapters on protocols) >>>> http://www.amazon.com/gp/product/1584885084 (book) >>>> >>>> Good alternative (or addition) to Stinson's book is Wenbo Mao's >>>> "Modern Cryptography: Theory and Practice" is also a recommended >>>> reading at that stage. >>>> >>>> http://www.amazon.com/gp/product/0130669431 (book) >>>> >>>> After that you MUST! read Goldwasser-Bellare's "Lecture Notes on >>>> Cryptography" http://www.cs.ucsd.edu/users/mihir/papers/gb.html >>>> (online) >>>> >>>> If you want implement algorithms yourself - you should read >>>> encyclopedic "Handbook of Applied Cryptography" >>>> http://www.cacr.math.uwaterloo.ca/hac/ (available online and as >>>> printed book) >>>> >>>> After you done with it, for hardcore cryptography and protocol >>>> design work you'll need to read Goldreich's "Foundations of >>>> Cryptography" (draft is available online >>>> http://theory.lcs.mit.edu/~oded/frag.html, but I'll highly >>>> recommend to buy books http://www.amazon.com/gp/product/0521791723 >>>> >>>> http://www.amazon.com/gp/product/0521830842) >>>> >>>> Only after you done reading references above (and reading papers >>>> that are most often cited in references section of mentioned books, >>>> lections notes and papers), then you may try to implement your own >>>> authentication protocols, and I'm sure - you will not be asking the >>>> questions that you are asking today. >>>> >>>> From the other side, I would not recommend reading Schneier's >>>> "Applied Cryptography". His non-rigorous discussion of protocols >>>> and algorithms makes it very easy to miss (oversee) difficulties of >>>> designing them, plus there are a number of conceptual mistakes in >>>> some of his descriptions (that was mussed many times in discussions >>>> that you can find in Usenet groups and on Internet). Schneier's >>>> book was an attempt to create simple exposition to cryptography for >>>> developers; however by Schneier's own words it was a mistake. >>>> >>>> -Valery. >>>> >>>> http://www.harper.no/valery >>>> >>>> "Andre Azevedo" <x***@xpto.com> wrote in message >>>> news:%23U1j2DtQGHA.3192@TK2MSFTNGP09.phx.gbl... >>>>> Hi all, >>>>> >>>>> I've started to develop a server and client socket classes with >>>>> encryption. The main communication/transport classes is working >>>>> fine >>>>> and >>>>> now I will write some encryption process. >>>>> After reading a lot of papers about Symmetric, Asymmetric, Hash, >>>>> Envelope >>>>> and Signature I still have somes doubts and I will explain what I >>>>> calling >>>>> the "Authenticate Flow" in client/server socket communication: >>>>> 1. Client connects into Server and Server accepts the connection. >>>>> 2. Server send his encryption public-key to Client. >>>>> 3. Client creates a new symetric session-key, encrypt it using the >>>>> Server >>>>> encryption public-key and send it to Server plus the Client sign >>>>> public-key. >>>>> 4. Server decrypt Client symetric session-key and simply replies >>>>> to >>>>> Client, telling "Ok, I have the symetric session-key and your sign >>>>> public-key". >>>>> Now, every time Client need send some data, it does the following: >>>>> 5. Client encrypts data with symetric session-key, sign (hash) the >>>>> result >>>>> with sign private-key. Client then sends the hash result and the >>>>> encrypted data to server. >>>>> 6. Server sign (hash) the encrypted data with the same Client hash >>>>> algoritm and save it in Hash1. After, it decrypt the sign (hash) >>>>> sended >>>>> by client using Client sign public-key to obtain the Hash2. If >>>>> Hash1 >>>>> and >>>>> Hash2 are the same, then is the correct Client. Otherwise, closes >>>>> the >>>>> connection. >>>>> 7. If ok, Server then decrypt data with symetric session-key. >>>>> Well, que questions now: >>>>> A - The hash algoritm is know by the Client and Server since it's >>>>> my >>>>> implementation of both and I don't need to send the hash algoritm >>>>> information. Is this acceptable? >>>>> B - Sendind the Client sign public-key to Server is ok. But, after >>>>> that, >>>>> I'm sending some data using Client sign private-key to Server. Is >>>>> this >>>>> secure? Is a normal way to do it? >>>>> C - Do I need to do the 5, 6 and 7 steps every time Client needs >>>>> send >>>>> some data to Server and vice-versa? Or these steps it's executed >>>>> only >>>>> once only certify the Client and, after that, both sides can send >>>>> messages encrypted only with symetric session-key? >>>>> Sorry for the long post. Any help will be apreciated >>>>> TIA, >>>>> >>>>> -- >>>>> Andre Azevedo 
Other interesting topics
setting permissions / trusting company via certificate?
HttpWebRequest using Certificates .NET 1.1 security policies broke after installing .NET 2.0 ClickOnce problem - different computed hash specified in manifest Client Authentication Can't find CryptImportKey in .NET !!!!! Can't access Process.Modules from my win form. File IO Permissions Security Error over LAN Need a secure web based database application setup recommendation. |
|||||||||||||||||||||||
