Why ¨trouble¨ ?

[No such Client]

On 08/28/2012 03:52 AM, No such Client wrote:
> and putting your key on a keyserver.. No thanks..
>
> If you're against publishing your public key on a key server, why are
> you signing messages with your private key and sending them to a public
> mailing list?  No one receiving the messages will be able to make use of
> the signature in the slightest.
>
> -> Many here sign their msgs. I don´t personally import everyone´s keys, as I don´t know, trust, nor want to trust them. Some here have my pubkey. But that is the same for others who sign msgs here. They can get my key by me sending it to them personally, and directly. No keyserver required.. And I have also sent my pubkey as both an s-pack, and a public .asc to said lists just in case someon wants to have a good, albeit untrusted signature.. But that is also besides your point. 
>
>
> On a more general note, the article you've linked has some social
> critiques of reliance on keysigning, but has no real commentary on the
> danger of public key cryptography.
> -> well, the article in question is titled ¨ Social implications of Keysigning¨ ^^.. Those dangers that you speak of still exist, sure.
>
>  Isn't the point of public key
> cryptography to allow one piece of a key to be read by any party while
> keeping the problem of recovering the encrypted data intractable?
>
> -> That may be your interpretation of the point. My point is to allow the intended recipient to decrypt ciphertext, and by reducing access to my pubkey (it shouldnt surprise you if i have more than one key) , I can further make things more secure by using --hidden-recipient, and relaying the ciphertext in a covert channel. Harder to attack ciphertext if you have neither the public nor secret key. Why put your pubkey up forever, to make it easier to socially or technically attack your comms?  
>
>  Ifyou are restricting heavily the people you share your public key with,
> why not simply use a symmetric algorithm, forgetting public key
> cryptography completely?  -> Uhh. because the benefit of pubkey encryption is still there, minus the risk of having pubkeys there forever permanently. (Disclosure: I was young and dumb once, and I too was a big fan of keyservers long ago.. I regret that now. And nothing can be done to rectify that. ) You can torture a password out of the other side, wheras layering PKI in such a way to make comms less coercion-resistant. Say, having a one key to authorize certain actions,  another for relaying traffic, and a third as a ¨wrapping key¨ which is transmitted say using pastebin.. So even if someone is tortured into giving up their system (and you can torture passwords, or keyfiles out of most people for hard drives, or even priv keys), the party would have a harder time constructing a properly formatted msg (with layered signing/ internal procedures) making it harder to forge a msg (assuming associates were not aware said individual was grabbed. Perhaps it is different in your country, however in the military, we often have to think pragmatically of the human weakness, and when symmetric or pKI is appropiate. Otherwise, others are at risk.
>
>  It would certainly render the problem of
> recovering any encrypted communication far less tractable. -> using gpg -ca -o cipher.txt plaintext.txt -> can be bruteforced by any idiot who writes a script to guess various permutations of a password, esp. given what he may find out using a side-channel attack on the sender/reciever and/or the context in which he believes the traffic is employed. using gpg -sea -R recipient  -o 3.txt (using ¨3" so that anyone recieving said text may falsely believe that there are previous comms) is alot more secure, even moreso if pubkeys are not shared overtly.. Why give any would-be attackers extra info ? Its often more useful who you comm with, not what you are communicating about.. Why  use symmetric crypto if said password can be coerced out of someone, whereas one can just skip keysigning, and
> use pki? 
> pants.
>
>
>
>
>   


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20120828/ac59cca8/attachment.pgp>