Re: Secrecy and user trust
- From: Ed Greshko <Ed.Greshko@xxxxxxxxxxx>
- Date: Mon, 08 Sep 2008 08:22:58 +0800
Les Mikesell wrote:
Ed Greshko wrote:In other words, you don't know how to define what a "fake key" is....so
Ed Greshko wrote:
It would be very nice if someone would fully define what they mean by
the very vague term "fake key".
In this context it would one that a user would install that was not
the one officially created for the packages in the fedora repository.
just avoid it and pretend.
So, the target is "one" system.
And along with that, define the method used to distribute said key in a
manner that would be oblivious to the all end users.
It doesn't have to fool all the end users, just you. Or someone with
content worth stealing, or on a network worth penetrating.
More "ifs".
It has to be
oblivious to all end users such that nobody would be able to raise an
alarm in a reasonable amount of time.
What's a reasonable amount of time? A victim would notice if/when
they manage to get an official RPM that the key doesn't match (unless
their subverted packages remove the check) and might or might not do
something besides import the correct key.
And, it is even less easy to "fool" the people whose networks have
If the public/private key methods employed today are as easy to
penetrate and subvert as some seem to be claiming then one has to
question why it hasn't already been done.
It's not easy to fool everyone. The question is whether there is a
way to start from scratch so you can't fool anyone.
something worth stealing....
Why go through the laughingly improbably scenario of attempting to
subvert the public/private key infrastructure with the potential need
need to simultaneously subvert DNS infrastructure on a single target
when there are already other much more simple attack vectors?
Oh, and to answer your question...."Is there a way to design a system so
you can't fool anyone?" Absolutely not.
--
Do YOU have redeeming social value?
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
- Follow-Ups:
- Re: Secrecy and user trust
- From: Les Mikesell
- Re: Secrecy and user trust
- References:
- Secrecy and user trust
- From: Bill Davidsen
- Re: Secrecy and user trust
- From: Bill Crawford
- Re: Secrecy and user trust
- From: Les Mikesell
- Re: Secrecy and user trust
- From: Bill Crawford
- Re: Secrecy and user trust
- From: Bill Davidsen
- Re: Secrecy and user trust
- From: John Aldrich
- Re: Secrecy and user trust
- From: Travis Arnold
- Re: Secrecy and user trust
- From: Anders Karlsson
- Re: Secrecy and user trust
- From: Bill Davidsen
- Re: Secrecy and user trust
- From: Patrick O'Callaghan
- Re: Secrecy and user trust
- From: Bill Davidsen
- Re: Secrecy and user trust
- From: Patrick O'Callaghan
- Re: Secrecy and user trust
- From: Ed Greshko
- Re: Secrecy and user trust
- From: Patrick O'Callaghan
- Re: Secrecy and user trust
- From: Ed Greshko
- Re: Secrecy and user trust
- From: Bill Davidsen
- Re: Secrecy and user trust
- From: Ed Greshko
- Re: Secrecy and user trust
- From: Bill Davidsen
- Re: Secrecy and user trust
- From: Ed Greshko
- Re: Secrecy and user trust
- From: Les Mikesell
- Re: Secrecy and user trust
- From: Ed Greshko
- Re: Secrecy and user trust
- From: Ed Greshko
- Re: Secrecy and user trust
- From: Les Mikesell
- Secrecy and user trust
- Prev by Date: Re: Secrecy and user trust
- Next by Date: Re: Secrecy and user trust
- Previous by thread: Re: Secrecy and user trust
- Next by thread: Re: Secrecy and user trust
- Index(es):
Relevant Pages
|