Prev: Public & Private Key
Next: Encryption & Authentication
From: Pink on 19 Dec 2009 12:39

"Paul Rubin" <no.email(a)nospam.invalid> wrote in message
news:7xr5qrb9x7.fsf(a)ruckus.brouhaha.com...
> "Res" <res(a)pk.com> writes:
>> Peter, I am really not using DH for secure communication here.
>> Hence my question whether a smaller prime number will do?
>
> It will not do. The security comes from the large size of the prime.
>
> Why do you want to use DH at all? Why not a shared secret key? The
> benefit of public key is when there are a large number of communicating
> parties, or when strangers want to talk to each other. If it's just two
> parties and they know each other, then use secret keys.

It's not just 2 parties. There is only one Bob in my example, but a large
number
of Alice's he sends instructions to.


From: Pink on 19 Dec 2009 12:51

"Paul Rubin" <no.email(a)nospam.invalid> wrote in message
news:7xr5qrb9x7.fsf(a)ruckus.brouhaha.com...
> "Res" <res(a)pk.com> writes:
>> Peter, I am really not using DH for secure communication here.
>> Hence my question whether a smaller prime number will do?
>
> It will not do. The security comes from the large size of the prime.
>
> Why do you want to use DH at all? Why not a shared secret key? The
> benefit of public key is when there are a large number of communicating
> parties, or when strangers want to talk to each other. If it's just two
> parties and they know each other, then use secret keys.

It's not just 2 parties. There is only one Bob in my example, but a large
number of Alices he sends instructions to.



From: Pink on 19 Dec 2009 12:52

"Peter Pearson" <ppearson(a)nowhere.invalid> wrote in message
news:7p2lnbF6joU1(a)mid.individual.net...
> On Fri, 18 Dec 2009 17:01:45 +0530, Res <res(a)pk.com> wrote:
>> "Joseph Ashwood" <ashwood(a)msn.com> wrote in message
>> news:uAHWm.396$8e4.97(a)newsfe03.iad...
>>>
>>> A single P of 2048 bits is good for a long time.
>>
>> This is a huge pain point for me.
>>
>> I have a maximum of somewhere around 8 to 10 bytes which can be
>> transferred from Alice to Bob (as a request). Hence my request is
>> essentially
>> going to be Alice transmitting her calculated
>> (g ** Random Number) mod Prime.
>> This means that the Prime cannot be a huge number like you suggest.
>
> By using the equivalent elliptic-curve system, you can get
> the sizes of the quantities down to 400 bits or so. If you're
> really limited to 10 bytes, I don't believe any public-key
> system will save you.
>
> I'm sorry to say the unwelcome guild-member thing, but if
> it's important that this system be secure against an
> intelligent and resourceful adversary, you really need the
> committed involvement of someone well experienced in the
> field. There are too many subtle mistakes to make, too
> many unconscious assumptions, for a casual design approach
> to stand any good chance of success.


Peter, I am programmer without much background in cryptography, but
trying to learn more.

There are existing systems where I am which aren't really secure - they
mostly use glorified XOR cryptography. Their security lies in the auditing
capability. And security is just so that a casual person will not break it.

Just as a learning exercise, I am looking at these systems &
the existing constraints & thinking of ways to make it even 10% more
secure. My ideas or solutions aren't really going to be implemented. Just
doing this in my spare time as an exercise to learn a bit more.


From: Pink on 19 Dec 2009 13:12
Thank you for your patience with my 'naive' questions.

> "Joseph Ashwood" <ashw...(a)msn.com> wrote in message be at the absolute
> limit 614 bits, that will probably be "secure" for a few minutes. A better
> solution would be to move to ECDH (Elliptic Curve Diffie Hellman) and
> ECDSA where you can barely be secure at 160 bits (20 bytes), 256 bit to be
> safe. The 256 bit signature will then take up 512 bits, the short term key
> another 512 bits, using SHA-256. This is about the best that can be done
> securely. Anything smaller is weak. Using integers a quick check says the
> 10 byte version is only about 90 seconds, the elliptic curve maybe 5
> minutes, neither is anything approaching secure. Even 16 bytes of ellitpic
> curve is only a day or so.

Ok - got it.
Just out of curiousity, what will be the form of attack to crack this?

i.e. an eavesdropper knows g, P, Alice & Bob's each's generated public
key. He also knows the encrypted text.
Now what will he do in 90 seconds (of a program) to get the shared secret?
He has to guess either a or b to get to the shared secret, right?
This is the part of cryptattack I am not able to understanding - how does
the
attack happen - understanding this will probably help me to analyze security
of a solution better.


From: Pink on 19 Dec 2009 13:14
Thank you for your patience with my 'naive' questions.

> "Joseph Ashwood" <ashw...(a)msn.com> wrote in message be at the absolute
> limit 614 bits, that will probably be "secure" for a few minutes. A better
> solution would be to move to ECDH (Elliptic Curve Diffie Hellman) and
> ECDSA where you can barely be secure at 160 bits (20 bytes), 256 bit to be
> safe. The 256 bit signature will then take up 512 bits, the short term key
> another 512 bits, using SHA-256. This is about the best that can be done
> securely. Anything smaller is weak. Using integers a quick check says the
> 10 byte version is only about 90 seconds, the elliptic curve maybe 5
> minutes, neither is anything approaching secure. Even 16 bytes of ellitpic
> curve is only a day or so.

Ok - got it.
Just out of curiousity, what will be the form of attack to crack this?

i.e. an eavesdropper knows g, P, Alice & Bob's each's generated public
key. He also knows the encrypted text.
Now what will he do in 90 seconds (of a program) to get the shared secret?
He has to guess either a or b to get to the shared secret, right?
This is the part of cryptattack I am not able to understanding - how does
the
attack happen - understanding this will probably help me to analyze security
of a solution better.



First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Public & Private Key
Next: Encryption & Authentication