full-disclosure - Re: stealing ssh keys

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Thu, 25 Oct 2012 10:23:12 +0530
From: "Raj Mathur (राज माथुर)" <raju@...ux-delhi.org>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: stealing ssh keys

On Thursday 25 Oct 2012, Thor (Hammer of God) wrote:
> I think you're over reacting just a bit.  You can give out your
> private key to whomever/whatever you want to be able to decrypt data
> encrypted with the public key.  It all depends on the use-case, and
> what you want done.  Just because its a private key doesn't mean
> it's automatically some critical security component.   Many times it
> is, but it doesn't have to be.

That statement is deeply flawed.

A private key is meant to be exactly that: private.  If a process or 
entity is handing out its private key to another process/entity for any 
reason whatsoever, then there is something seriously wrong in the way 
the interaction has been designed.

The basis of public-key cryptography is that you (generic you) have two 
keys: public and private.  These two keys are orthogonal to each other, 
so:

A. Data encrypted with your private key can only be decrypted by using 
your public key, and
B. Data encrypted with your public key can only be decrypted using your 
private key.

With this, we can implement the two basic requirements of crypto.  In 
very general terms, these are:

1. Data privacy.  When someone needs to send data privately to you, they 
encrypt it with your public key.  Then only the person who has the 
corresponding private key (you) can decrypt the data.  Anyone else 
intercepting the message will only have junk.

2. Identity.  When you need to establish the ownership of data 
originating from you, you encrypt the message with your private key.  
Since only your public key can decrypt that message, any recipient can 
check (by decrypting with your public key) that your private key has 
been used to encrypt.  This establishes you as the originator of the 
data.

As you can see, in both cases the recipient of the data only needs your 
public key, while only you need your private key.  There is no 
reasonable circumstance under which you would need to share your private 
key with someone else.

Regards,

-- Raj
-- 
Raj Mathur                          || raju@...dalaya.org   || GPG:
http://otheronepercent.blogspot.com || http://kandalaya.org || CC68
It is the mind that moves           || http://schizoid.in   || D17F

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/