Need to implement #52
Comments
|
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 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, ***@***.***> 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
<#52 (comment)>, 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,
***@***.***>
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
> <#52 (comment)>, 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
<#52 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4FW6UEDPMUOR3MNXFNH7DSS2AR7ANCNFSM4UKROJGQ>.Web
Bug from
https://github.com/notifications/beacon/AC4FW6QVBQEUUL7PGJ4D5NLSS2AR7A5CNFSM4UKROJG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFPZ7PCI.gif
[ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage",
"potentialAction": { ***@***.***": "ViewAction", "target":
"#52 (comment)",
"url":
"#52 (comment)",
"name": "View Issue" }, "description": "View this Issue on GitHub",
"publisher": { ***@***.***": "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, ***@***.***> 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
<#52 (comment)>, 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:
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: [email protected]
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
<#52 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ANGASGHLGLUZ3W7XSLL7QVTSSZXTTANCNFSM4UKROJGQ>
.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#52 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACEIQBDHQ2SZY7AFFA3TRH3SS7FLTANCNFSM4UKROJGQ>.
|
|
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
-->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: [email protected] 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, <[email protected]> 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 > <#52 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/ANGASGHLGLUZ3W7XSLL7QVTSSZXTTANCNFSM4UKROJGQ> > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#52 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACEIQBDHQ2SZY7AFFA3TRH3SS7FLTANCNFSM4UKROJGQ>. —You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The text was updated successfully, but these errors were encountered: