PGP source code

Dave Howe DHowe at Hawkswing.demon.co.uk
Sun, 2 Sep 2001 20:01:47 +0100


> > PGPdisk and PGPnet).
> I have never felt the slightest inclination to use either of those so
> I would prefer to do without ...
Hmm. as far as I know (and I am hoping someone here knows better of
course) PGPnet is the nearest to a free IPSEC solution for windows that
is available.
I would not touch PGPdisk with a bargepole though - having OTF
encryption as tightly bound to PGP as PGPdisk is (and with newer
versions doing a MSOffice on you - deliberately upgrading your datafiles
to make them unreadable in the older versions) Scramdisk is a much much
better bet - even leaving aside the facts it is much cheaper and that
there is a Linux driver available for scramdisk.

> >It also requires a specific compiler,
> Is that absolute?  Or because of the adde libraries?
I don't know - It is possible that you could rewrite parts or all of it
(although it *does* appear to be a MFC app) to remove the dependancy on
MS Visual studio. Imad would be the person to ask there though, not me.

> So something that is available as complete source, and compilable with
> a compiler for which the complete source is also avialable, is,
> provided the compiler source does not have a backdoor itself which I
> am unable to spot and nobody else who is able is willing to tell me
> about, is a significantly better bet.
I would say so - modulo the problems with compiling the source to the
compiler of course *grin*

> I installed GNU-PG a while ago, I'll get on with understanding it.
I have noticed a certain "taking of sides" over GPG / NAI PGP lately -
mostly because GPG is not by default compatable with pre-7.x versions of
PGP. (yes, you can set it to be compatable with all 5.x and later by
setting some flags, but since when have users read manuals?)
The project seems to have alienated Imad, which is a shame - both due to
the loss to the project and to the ckt version of the program.

> Taking this a bit further, given that the source code for the
> operating system the NHS seems determined to favour is not available,

> except to Chinese visitors, we have no reason to trust the operation
> of any program running on it to preserve privacy and had best get on
> with moving to Linux or BSD for the desktop.
No objections there - I am only still on windows because I have to
support it. if I could get my employer to migrate towards Linux, I
would.
Killer apps are, of course Outlook and MS Office - open source
replacements for which hopefully should be available soon.

> Or can we trust the X86 microcode (he says risking revealing a
> considerable depth of ignorance about what the microcode is, does, or
> could be perverted to do)?
Damned if I know - my depth of ignorance here matches yours. I know of
no reasonable way to audit microcode, but I suppose you could try
running stuff in parallel on AMD and Intel processors, in the hope you
will spot any differences in behaviour.