Why trust gpg4win?
pete at heypete.com
Wed Sep 11 11:48:08 CEST 2013
On Wed, Sep 11, 2013 at 11:01 AM, Jan <takethebus at gmx.de> wrote:
> On 10/09/2013 15:18, NdK wrote:
>>>> You'd be exposed nearly to the same attack vectors. Plus some more (the
>>>> ones that handle the extra layer), so you'd have to check more code.
>>> So what about using that free USB stack for AVR's to implement a flash
>>> device? You would be able to audit about everything; flylogic even has
>>> these nice pictures of the ATmega88 masks...
>> Sorry, I don't follow your reasoning here.
>> Pete proposed to use an USB-to-Serial interface to avoid attacks against
>> the USB stack on the PC. Why should an AVR be used to implement a flash
> Maybe Pete meant such an USB-to-Serial interface
> http://www.robotsimple.com/Computer_Interface/USB_to_Serial_Adapter ?
Actually, I was thinking of something that was the exact opposite:
some device (which I don't think exists) that would allow one to
connect a USB flash drive to the device, and have the device convert
that into RS232 serial data for the computer, thus avoiding any USB
interaction with the computer itself. The computer would then need to
process the serial data to read or write files on the drive. As far as
I know, nothing like that exists and I'm not sure if it'd be possible
to do. Even if it was possible, it'd be immensely slower than normal
My thought was that since serial is older and simpler than USB that it
would be possible to better audit and secure the connection between
the flash drive and the computer using such a method. My idea was
derived from one of the ways CAcert keeps their root certificate
secure: the signing system is kept offline, but is connected via a
serial cable to an online computer (e.g. the web server). The simple
daemon that listens on the serial port of the signing system will only
respond to requests for signing things but they did not implement any
file-transfer-over-serial functionality so it would (presumably) be
impossible to compromise the root certificate remotely. My idea would
be for something similar, but with file-transfer capability over
The device you linked to, which is quite common, is the opposite: one
can connect a serial device (say a microcontroller, a UPS, etc.) to
the device, which converts it to USB and transmits that data to the
computer. The device appears as a serial port on the computer.
In brief, the device you linked to tunnels serial-over-USB. My thought
was to do filesystem-access-over-serial.
Mine is probably a very silly idea and I was basically throwing the
idea at the wall to see if it'd stick. :)
More information about the Gnupg-users