Need to implement - Githubissues

can u please help how can i implement this encryption and decryption algorithm in socket programming in linux, as i want to encrypt and decrypt the messages between server and client.

You have a couple of challenges. I would split the encryption/decryption part from the message exchange. Get the message transfer part working for unencrypted messages first, so you can prove you have this part working.

Then move to encryption. For this you need to have a register of public keys somewhere. So you need to either make this part of your exchange protocol, or have a separate microservice that handles public keys. Either way. you will need to serialise the key and the parameters. I would go with the former and make it part of the conversation setup process:

Bare in mind that he message you send can be no longer than the key, or there abouts. This is a restriction of NTRU. Its not very good at sending very large messages. But what you can do is use the NTRU encryption process to exchange AES256 keys. Now you can send large blocks of data, encrypted with AES without having to exchange an AES key prior to this.

.> I want to communicate, here is my public NTRU key <- OK, I accept, and here is my public NTRU key -> [e-NTRU] : Here is my random AES256 key <- [e-NTRU] : And here is my random AES256 key -> [e-AES256] : Here is a secret message <- [e-AES256] : and here is my secret response .....

Its a matter of choice if you have two different AES keys or you share it for the life of the conversation.

Does that help? Keep in mind that you should NOT sign the messages with the NTRU private key. There is a weakness in NTRU that (partially) exposes the key in this instance. I would suggest signing in a different keyspace entirely if that is needed. YMMV

Hope this helps....

Look we have client and server which are sharing messages.. Now we are unable to implement .. Can you explain throughout because we are just beginners ...

On Wed, 2 Dec, 2020, 22:34 AdrianChallinorOsiris, notifications@github.com wrote:

You have a couple of challenges. I would split the encryption/decryption part from the message exchange. Get the message transfer part working for unencrypted messages first, so you can prove you have this part working.

Then move to encryption. For this you need to have a register of public keys somewhere. So you need to either make this part of your exchange protocol, or have a separate microservice that handles public keys. Either way. you will need to serialise the key and the parameters. I would go with the former and make it part of the conversation setup process:

Bare in mind that he message you send can be no longer than the key, or there abouts. This is a restriction of NTRU. Its not very good at sending very large messages. But what you can do is use the NTRU encryption process to exchange AES256 keys. Now you can send large blocks of data, encrypted with AES without having to exchange an AES key prior to this.

.> I want to communicate, here is my public NTRU key <- OK, I accept, and here is my public NTRU key -> [e-NTRU] : Here is my random AES256 key <- [e-NTRU] : And here is my random AES256 key -> [e-AES256] : Here is a secret message <- [e-AES256] : and here is my secret response .....

Its a matter of choice if you have two different AES keys or you share it for the life of the conversation.

Does that help? Keep in mind that you should NOT sign the messages with the NTRU private key. There is a weakness in NTRU that (partially) exposes the key in this instance. I would suggest signing in a different keyspace entirely if that is needed. YMMV

Hope this helps....

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tbuktu/libntru/issues/52#issuecomment-737365366, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANGASGHLGLUZ3W7XSLL7QVTSSZXTTANCNFSM4UKROJGQ .

Hi,

maybe a good invest would be a cryptography book -.- Just saying..

best regards,

Yves

Am 02.12.2020 um 19:21 schrieb T0RPID0:

Look we have client and server which are sharing messages.. Now we are unable to implement .. Can you explain throughout because we are just beginners ...

On Wed, 2 Dec, 2020, 22:34 AdrianChallinorOsiris, notifications@github.com wrote:

You have a couple of challenges. I would split the encryption/decryption part from the message exchange. Get the message transfer part working for unencrypted messages first, so you can prove you have this part working.

Then move to encryption. For this you need to have a register of public keys somewhere. So you need to either make this part of your exchange protocol, or have a separate microservice that handles public keys. Either way. you will need to serialise the key and the parameters. I would go with the former and make it part of the conversation setup process:

Bare in mind that he message you send can be no longer than the key, or there abouts. This is a restriction of NTRU. Its not very good at sending very large messages. But what you can do is use the NTRU encryption process to exchange AES256 keys. Now you can send large blocks of data, encrypted with AES without having to exchange an AES key prior to this.

.> I want to communicate, here is my public NTRU key <- OK, I accept, and here is my public NTRU key -> [e-NTRU] : Here is my random AES256 key <- [e-NTRU] : And here is my random AES256 key -> [e-AES256] : Here is a secret message <- [e-AES256] : and here is my secret response .....

Its a matter of choice if you have two different AES keys or you share it for the life of the conversation.

Does that help? Keep in mind that you should NOT sign the messages with the NTRU private key. There is a weakness in NTRU that (partially) exposes the key in this instance. I would suggest signing in a different keyspace entirely if that is needed. YMMV

Hope this helps....

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tbuktu/libntru/issues/52#issuecomment-737365366, or unsubscribe

https://github.com/notifications/unsubscribe-auth/ANGASGHLGLUZ3W7XSLL7QVTSSZXTTANCNFSM4UKROJGQ .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/tbuktu/libntru/issues/52#issuecomment-737408905, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC4FW6UEDPMUOR3MNXFNH7DSS2AR7ANCNFSM4UKROJGQ.Web Bug from https://github.com/notifications/beacon/AC4FW6QVBQEUUL7PGJ4D5NLSS2AR7A5CNFSM4UKROJG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFPZ7PCI.gif

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/tbuktu/libntru/issues/52#issuecomment-737408905", "url": "https://github.com/tbuktu/libntru/issues/52#issuecomment-737408905", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

Sorry to disturb you again, But I m too close now, i implemented key generation obtained public key from client, ecrypted the message sent by client now how do i share my client phblic key to server and decrypt that message on server side and again vice versa for security chat....plz help m on a project deadline is just 2 days...

On Wed, 2 Dec, 2020, 22:34 AdrianChallinorOsiris, notifications@github.com wrote:

You have a couple of challenges. I would split the encryption/decryption part from the message exchange. Get the message transfer part working for unencrypted messages first, so you can prove you have this part working.

Then move to encryption. For this you need to have a register of public keys somewhere. So you need to either make this part of your exchange protocol, or have a separate microservice that handles public keys. Either way. you will need to serialise the key and the parameters. I would go with the former and make it part of the conversation setup process:

Bare in mind that he message you send can be no longer than the key, or there abouts. This is a restriction of NTRU. Its not very good at sending very large messages. But what you can do is use the NTRU encryption process to exchange AES256 keys. Now you can send large blocks of data, encrypted with AES without having to exchange an AES key prior to this.

.> I want to communicate, here is my public NTRU key <- OK, I accept, and here is my public NTRU key -> [e-NTRU] : Here is my random AES256 key <- [e-NTRU] : And here is my random AES256 key -> [e-AES256] : Here is a secret message <- [e-AES256] : and here is my secret response .....

Its a matter of choice if you have two different AES keys or you share it for the life of the conversation.

Does that help? Keep in mind that you should NOT sign the messages with the NTRU private key. There is a weakness in NTRU that (partially) exposes the key in this instance. I would suggest signing in a different keyspace entirely if that is needed. YMMV

Hope this helps....

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tbuktu/libntru/issues/52#issuecomment-737365366, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANGASGHLGLUZ3W7XSLL7QVTSSZXTTANCNFSM4UKROJGQ .

Hey..Are you asking me to write this for you? What language are you using because there are some I won't do!!!! Joking, of course, for a fee I will write in any language you like, and that includes Cobol!

Basically, as I said, you need to serialize the public key and transmit it. That is not quite as easy as it seems, but look at the definitions of the public key. You also need to share the scheme name and the PRNG name. SO three things needed there:

The seraialized public key;
The Encryption scheme;
The PRNG name

How you then send this to the recipients is a matter for your use case. This is NOT secret information. The clue is in the word "PUBLIC", so put it on a web site, broadcast to all participants, or offer it on demand.

There are a number of variations on this theme with multiple public keys being the main one.

But frankly, this is going way beyond a few pointers approaching paid for consultancy. You really need to understand this encryption scheme to make it work for you, and my helping you out is not a substitute to your reading the technical literature.

Adrian Challinor FRAS

Osiris Consultants Ltd t: +44-7860-290-883 e: adrian.challinor@osiris.co.uk

On Thu, 2020-12-03 at 09:47 -0800, T0RPID0 wrote:

On Wed, 2 Dec, 2020, 22:34 AdrianChallinorOsiris, notifications@github.com wrote:

You have a couple of challenges. I would split the encryption/decryption part from the message exchange. Get the message transfer part working for unencrypted messages first, so you can prove you have this part working.

Then move to encryption. For this you need to have a register of public keys somewhere. So you need to either make this part of your exchange protocol, or have a separate microservice that handles public keys. Either way. you will need to serialise the key and the parameters. I would go with the former and make it part of the conversation setup process:

Bare in mind that he message you send can be no longer than the key, or there abouts. This is a restriction of NTRU. Its not very good at sending very large messages. But what you can do is use the NTRU encryption process to exchange AES256 keys. Now you can send large blocks of data, encrypted with AES without having to exchange an AES key prior to this.

.> I want to communicate, here is my public NTRU key <- OK, I accept, and here is my public NTRU key -> [e-NTRU] : Here is my random AES256 key <- [e-NTRU] : And here is my random AES256 key -> [e-AES256] : Here is a secret message <- [e-AES256] : and here is my secret response .....

Its a matter of choice if you have two different AES keys or you share it for the life of the conversation.

Does that help? Keep in mind that you should NOT sign the messages with the NTRU private key. There is a weakness in NTRU that (partially) exposes the key in this instance. I would suggest signing in a different keyspace entirely if that is needed. YMMV

Hope this helps....

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tbuktu/libntru/issues/52#issuecomment-737365366, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANGASGHLGLUZ3W7XSLL7QVTSSZXTTANCNFSM4UKROJGQ .

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/tbuktu/libntru/issues/52#issuecomment-738173740, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACEIQBDHQ2SZY7AFFA3TRH3SS7FLTANCNFSM4UKROJGQ.

Thnx mate……..😊 Sent from Mail for Windows 10 From: AdrianChallinorOsirisSent: 04 December 2020 15:58To: tbuktu/libntruCc: T0RPID0; AuthorSubject: Re: [tbuktu/libntru] Need to implement (#52) Hey..Are you asking me to write this for you? What language are you using because there are some I won't do!!!! Joking, of course, for a fee I will write in any language you like, and that includes Cobol! Basically, as I said, you need to serialize the public key and transmit it. That is not quite as easy as it seems, but look at the definitions of the public key. You also need to share the scheme name and the PRNG name. SO three things needed there: 1. The seraialized public key; 2. The Encryption scheme; 3. The PRNG name How you then send this to the recipients is a matter for your use case. This is NOT secret information. The clue is in the word "PUBLIC", so put it on a web site, broadcast to all participants, or offer it on demand. There are a number of variations on this theme with multiple public keys being the main one. But frankly, this is going way beyond a few pointers approaching paid for consultancy. You really need to understand this encryption scheme to make it work for you, and my helping you out is not a substitute to your reading the technical literature. -- Adrian Challinor FRAS Osiris Consultants Ltd t: +44-7860-290-883 e: adrian.challinor@osiris.co.uk On Thu, 2020-12-03 at 09:47 -0800, T0RPID0 wrote: Sorry to disturb you again, But I m too close now, i implemented key generation obtained public key from client, ecrypted the message sent by client now how do i share my client phblic key to server and decrypt that message on server side and again vice versa for security chat....plz help m on a project deadline is just 2 days... On Wed, 2 Dec, 2020, 22:34 AdrianChallinorOsiris, wrote: > You have a couple of challenges. I would split the encryption/decryption > part from the message exchange. Get the message transfer part working for > unencrypted messages first, so you can prove you have this part working. > > Then move to encryption. For this you need to have a register of public > keys somewhere. So you need to either make this part of your exchange > protocol, or have a separate microservice that handles public keys. Either > way. you will need to serialise the key and the parameters. I would go with > the former and make it part of the conversation setup process: > > Bare in mind that he message you send can be no longer than the key, or > there abouts. This is a restriction of NTRU. Its not very good at sending > very large messages. But what you can do is use the NTRU encryption process > to exchange AES256 keys. Now you can send large blocks of data, encrypted > with AES without having to exchange an AES key prior to this. > > .> I want to communicate, here is my public NTRU key > <- OK, I accept, and here is my public NTRU key > -> [e-NTRU] : Here is my random AES256 key > <- [e-NTRU] : And here is my random AES256 key > -> [e-AES256] : Here is a secret message > <- [e-AES256] : and here is my secret response > ..... > > Its a matter of choice if you have two different AES keys or you share it > for the life of the conversation. > > Does that help? Keep in mind that you should NOT sign the messages with > the NTRU private key. There is a weakness in NTRU that (partially) exposes > the key in this instance. I would suggest signing in a different keyspace > entirely if that is needed. YMMV > > Hope this helps.... > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > , or > unsubscribe > > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. —You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.

tbuktu / libntru

Need to implement #52