Am 08.12.2013 11:51, schrieb Paul R. Ramer:
Peter Lebbing <pe...@digitalbrains.com> wrote:
We're debating the risk that a card is backdoored. If there is such a
risk, that
risk still exists if we allow for the possibility that manufacturers
try to do
what you say. They're not mutually exclusive; how come you infer that I
assume
that the manufacturer would not do the opposite?
It was not my intent to make it seem that I had made any insinuations on your
part. It was more that I wanted to express an alternate possibility rather
than the nefarious one that was being discussed.
It seemed that the only scenario involving pressure or coercion on the part of
the U.S. being discussed was one of compliance by the company rather than a
range of possibilities. Events in life do not always happen neatly and
predictably. If we are going to discuss outcomes, we need to talk about more
than one.
Looking backwards (history) if there was a possibility to build in a
backdoor such one
always had happened and had been exploited.
It applied and still applies for "most" of commercial IT software and
hardware vendors
and even such OSS projects focused on securiry like openBSD (in the past).
Smart cards are good only for a certain level of privacy to keep rather
primitive ciriminals away.
As long everyone is not able to audit the source code of firmware or
operating systems
(in particular closed source software products) there are a lot of other
possibilities to steal your secrets.
I didn't follow the history of the CryptoStick until now but I would
like to add my "few cents" somewhere later.
An idea would be not to trust anyone and to create so called linux live
images yourself.
(saving them on a read-only medium and booting from it into live mode).
Example and some description how to do it:
http://rsync.it-infrastrukturen.org/banque-live/
http://git.it-infrastrukturen.org/banque-live.git
Due to my limited time resources all existing .iso images there are
currently NOT up to date (8 months old).
It is for me a time intensive challenge to patch gnupg 2.0 or the much
more interesting 2.1
to support longer keys and create .deb packages with all dependencies.
(like RSA 15k .. even they are not inside "secure" standards .. from my
"paranoid" point of view)
A little security is not real security. There always can be backdoors in
the firmware (BIOS, closed source drivers etc).
Kind regards, Mark
--
m...@it-infrastrukturen.org
http://rsync.it-infrastrukturen.org
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
