Hi guys, I need a secure data transfer mechanism between my server (APIs and normal HTMLs) and clients (normal users or other servers). Is digital digest using Hash + public and private keys mechanism a correct way? Is there any tutorial or pointer in setting up digital digested return for my server responses? Any help is appreciated! Arthur -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Arthur Chan wrote:> Hi guys, > > I need a secure data transfer mechanism between my server (APIs and > normal HTMLs) and clients (normal users or other servers). > > Is digital digest using Hash + public and private keys mechanism a > correct way? > > Is there any tutorial or pointer in setting up digital digested return > for my server responses?Why can''t you use SSL/TLS? It would be a lot less effort than rolling your own. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Hi Robert, Thanks for the info first. Actually, I have the question after reading "Php and Web development 4th edition" (Addison-Wesley) p354: <quote> Digital Signatures Digital signatures are related to public key cryptography but reverse the role of public and private keys.A sender can encrypt and digitally sign a message with her secret key. When the message is received, the recipient can decrypt it with the sender’s public key. Because the sender is the only person with access to the secret key, the recipient can be fairly certain from whom the message came and that it has not been altered. Digital signatures can be really useful.The recipient can be sure that the message has not been tampered with, and the signatures make it difficult for the sender to repudiate, or deny sending, the message. It is important to note that although the message has been encrypted, it can be read by anybody who has the public key.Although the same techniques and keys are used, the purpose of encryption here is to prevent tampering and repudiation, not to prevent reading. Because public key encryption is fairly slow for large messages, another type of algo- rithm, called a hash function, is usually used to improve efficiency.The hash function calculates a message digest or hash value for any message it is given. It is not important what value the algorithm produces. It is important that the output is deterministic—that is, that the output is the same each time a particular input is used, that the output is small, and that the algorithm is fast. The most common hash functions are MD5 and SHA. A hash function generates a message digest that matches a particular message. If you have a message and a message digest, you can verify that the message has not been tam- pered with, as long as you are sure that the digest has not been tampered with.To this end, ** the usual way of creating a digital signature is to create a message digest for the whole message using a fast hash function and then encrypt only the brief digest using a slow public key encryption algorithm.The signature can now be sent with the message via any normal unsecure method.** When a signed message is received, it can be checked.The signature is decrypted using the sender’s public key.A hash value is then generated for the message using the same method that the sender used. If the decrypted hash value matches the hash value you generated, the message is from the sender and has not been altered. </quote> I don''t understand how to work with the "**... **" parts in Rails Then the book goes on next section: "Digital Certificates" which should be the SSL. Therefore, as the books separate the idea. So I don''t know whether I should implement both. Indeed, as I remembered, mostly, the session keys sensitive items should be using https, e.g. login, signup. Please correct me if I am wrong. Thanks a bunch. Arthur On 1月16日, 上午12時49分, Robert Walker <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> Arthur Chan wrote: > > Hi guys, > > > I need a secure data transfer mechanism between my server (APIs and > > normal HTMLs) and clients (normal users or other servers). > > > Isdigitaldigest using Hash + public and private keys mechanism a > > correct way? > > > Is there any tutorial or pointer in setting updigitaldigested return > > for my server responses? > > Why can''t you use SSL/TLS? It would be a lot less effort than rolling > your own. > -- > Posted viahttp://www.ruby-forum.com/.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
More info from the book for the question: It said that SSL is a layer between Transport Layer (TCP/udp) and Application Layer. And it seems that the digital signatures is in the Application Layer. Agreed? Arthur On 1月16日, 上午10時22分, Arthur Ccube <arthurcc...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hi Robert, > > Thanks for the info first. > > Actually, I have the question after reading "Php and Web development > 4th edition" (Addison-Wesley) p354: > > <quote> > Digital Signatures > Digital signatures are related to public key cryptography but reverse > the role of public and private keys.A sender can encrypt and digitally > sign a message with her secret key. When the message is received, the > recipient can decrypt it with the sender’s public key. Because the > sender is the only person with access to the secret key, the recipient > can be fairly certain from whom the message came and that it has not > been altered. > Digital signatures can be really useful.The recipient can be sure that > the message has not been tampered with, and the signatures make it > difficult for the sender to repudiate, or deny sending, the message. > It is important to note that although the message has been encrypted, > it can be read by anybody who has the public key.Although the same > techniques and keys are used, the purpose of encryption here is to > prevent tampering and repudiation, not to prevent reading. > Because public key encryption is fairly slow for large messages, > another type of algo- rithm, called a hash function, is usually used > to improve efficiency.The hash function calculates a message digest or > hash value for any message it is given. It is not important what value > the algorithm produces. It is important that the output is > deterministic—that is, that the output is the same each time a > particular input is used, that the output is small, and that the > algorithm is fast. > The most common hash functions are MD5 and SHA. > A hash function generates a message digest that matches a particular > message. If you have a message and a message digest, you can verify > that the message has not been tam- pered with, as long as you are sure > that the digest has not been tampered with.To this > end, > ** the usual way of creating a digital signature is to create a > message digest for the whole message using a fast hash function and > then encrypt only the brief digest using a slow public key encryption > algorithm.The signature can now be sent with the message via any > normal unsecure method.** > > When a signed message is received, it can be checked.The signature is > decrypted using the sender’s public key.A hash value is then generated > for the message using the same method that the sender used. If the > decrypted hash value matches the hash value you generated, the message > is from the sender and has not been altered. > > </quote> > > I don''t understand how to work with the "**... **" parts in Rails > > Then the book goes on next section: "Digital Certificates" which > should be the SSL. Therefore, as the books separate the idea. So I > don''t know whether I should implement both. > > Indeed, as I remembered, mostly, the session keys sensitive items > should be using https, e.g. login, signup. > > Please correct me if I am wrong. > > Thanks a bunch. > Arthur > > On 1月16日, 上午12時49分, Robert Walker <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote: > > > Arthur Chan wrote: > > > Hi guys, > > > > I need a secure data transfer mechanism between my server (APIs and > > > normal HTMLs) and clients (normal users or other servers). > > > > Isdigitaldigest using Hash + public and private keys mechanism a > > > correct way? > > > > Is there any tutorial or pointer in setting updigitaldigested return > > > for my server responses? > > > Why can''t you use SSL/TLS? It would be a lot less effort than rolling > > your own. > > -- > > Posted viahttp://www.ruby-forum.com/.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.