Re: Secrecy and user trust

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Aldo Foot wrote, On 09/04/2008 12:10 PM:
On Wed, Sep 3, 2008 at 8:42 PM, Bill Davidsen <davidsen@xxxxxxx> wrote:
Patrick O'Callaghan wrote:
On Wed, 2008-09-03 at 10:30 -0400, Bill Davidsen wrote:
hardest of all find a secure way to provide the public part of the
signing key
The whole point about asymmetric encryption is that you don't need a
secure distribution channel. The worst that can happen is that some fake
public key gets distributed, which won't match the private key and hence
will be instantly detectable.

NAK - if a fake public key were distributed then packages signed with the
fake key would be matched, allowing full access to install crap in your
machine. And packages signed with any valid redhat key would be rejected.

The public key really must be distributed in a secure manner.


Isn't the point of a Public Key to be publicly distributed?

Only part of the point.
Yes, you can give your Public Key to me, and I can give it to Jim, and Jim can give it to Jane, and it is still good for it's purpose, which is to validate that the packet of data sent on the net has not been messed with between being signed with the private key and arriving at the destination.

But, should Jane be trusting a key given to her by that shady guy Jim to install random bits of software?

Now if some time earlier Jane and I had met, and exchanged public keys and she felt that my signature was worthy of trust[1], and I had signed your key before giving it to Jim, then Jane would have SOME reason to trust that the key came from _WHO_ it claims to come from instead of some key that Jim generated to do a MITM attack[2].

The underlying thing Bill was getting at with "The public key really must be distributed in a secure manner" is security from an INTEGRITY perspective[3].

Unfortunately, currently most of us only have a very tenuous web of trust back to any key that that could vouch for the fact that any new key is actually from the Fedora crew. Many folks will trust the key because the old key (which has a shadow of doubt over it) will sign it, i.e., they will get it with yum and because the old key's sig passes what is on their system it will be installed. Some may trust it because they have a substantial web of trust to Paul Frields or other Fedora community members who may sign a version of the public key. Others may trust it because they trust a person who gives it to them and know that person got it physically from a person at the red hat building who the second person trusts.

See the suggestion I made a while back[4] for further information about our current use of cobwebs of trust. My suggestion then was not to take care of the current situation, it is too late for using it for the current situation, but it would make any later situations easier to deal with. I still think Fedora needs a master key made (soon after the current situation is resolved) so that we can start building at least a cobweb for it.

The Private Key is what you closely guard against all tampering.

~af


[1] http://en.wikipedia.org/wiki/Web_of_trust

[2] http://en.wikipedia.org/wiki/Man-in-the-middle_attack#Example_of_a_successful_MITM_attack_against_public-key_encryption

[3] http://en.wikipedia.org/wiki/Data_integrity

[4] https://www.redhat.com/archives/fedora-list/2008-August/msg03255.html
{something seems bonkers with the way the html is showing the foot notes at the end of the message, as it looks like foot note 2 is referencing 3-7, but those seem to have been concatenated onto the same line with foot note 2.}

--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux