Backdoor rumor for gcc/PGP
Vaughn Herbert Seward
This thread originates from an E-mail I received about a WWW site
someone saw with the paranoid theory that a trapdoor was placed in PGP
by means of tampering with the GNU C compiler gcc.
In <574rf5$m...@news.nstn.ca> hcls...@tallships.istar.ca (Hume Smith)
writes, in part:
>he actually *did* something pretty much
>exactly what's described in this paranoid theory - he twiddled the C
compiler
>to detect when it was compiling login and insert a backdoor; and to
detect when
>it ws compiling itself to insert the backdoor inserter. then he
recompiled the
>compiler, deleted the hack's source, and it spread through a lot of
unix
>systems because the critical parts of the source changed very little.
And A. Engelfriet also noted this.
The fact that it's been done, although still leaving it likely the
specific rumor isn't real, does raise some questions.
1) Where could you hide a backdoor in PGP? If someone tried to add a
"key-escrow" segment, like the Clipper LEAF, to PGP messages, wouldn't
people see it right away?
There's one obvious spot for a backdoor. When selecting the two random
primes from which the modulus is formed, select at least one of them
with only 40 bits (or less) of actual randomness.
There's at least one other less obvious spot: some systems using RSA
always use the same public e (3, 7, or 17); but if instead a 'random' e
is used, one could instead calculate a 'random' d with 40 bits of
randomness and calculate e from it.
The third spot for a backdoor, somewhat easier to check (because the
behavior from a given RANDSEED.BIN could be verified) would be to limit
session keys to 40 bits or randomness.
2) Another good reason that the NSA doesn't approve software encryption
as secure. In fact, given such things are possible, one wonders how
institutions with computing-related security concerns might validate
their compilers.
One possibility is to use the compiler option to print out
assembly-language source of the generated object code; make spot checks
between the listing and the object, (not forgetting that the flaw may
be in your linker, not your compiler, so check .EXEs, not just .OBJs)
as well as comparing the executable to one generated without the option
(the "good behavior" possibility) and inspect the listing itself (the
"bad behavior" possibility).
3) This particular story is still not credible, since they made one
slip. How do you get Richard Stallman to do something by making threats
to Phil Zimmerman?
Furthermore, Richard Stallman & co. have a serious purpose in what
they're doing, so this kind of stunt is unlikely from them. As there
are other C compilers than gcc, one could first compile gcc with
another compiler, then use the result to compile gcc (to get a clean
copy without the commercial compiler's library embedded). I could,
however, imagine someone porting gcc, or putting together a Linux
distribution, and pulling this kind of stunt. Probably to get at login
rather than PGP, of course, in the latter case.
This all goes to show that Bruce Schneier's dictum that security is
about more than algorithms is indeed true.
John Savard
the sole author of this post, for which no one else is responsible
Larry Kingery
I originally heard this bit of lore as a hidden "feature" of the
original C compiler for unix, which would propagate itself into any
compiler it created. Hence, all unix C compilers not written from
scratch are infected.
Needless to say, I didn't believe it then, either.
--
Larry Kingery kin...@cs.uiowa.edu
----------------------------------------------------------------
Gregory G Rose
In article <k0zu3qf...@bolivar.cs.uiowa.edu>,
Larry Kingery <kin...@cs.uiowa.edu> wrote:
>I originally heard this bit of lore as a hidden "feature" of the
>original C compiler for unix, which would propagate itself into any
>compiler it created. Hence, all unix C compilers not written from
>scratch are infected.
>
>Needless to say, I didn't believe it then, either.
The story first appeared in Ken Thompson's ACM
Turing Award lecture, in 1979(?). It is true,
although the program in question was Dennis
Ritchie's C compiler for the PDP-11, which even
then obsoleted by Johnson's PCC. Gnu was unherd :-)
of at the time.
It wouldn't propagate to other C compilers, only
itself, as it worked by recognising code in the
two affected programs (cc and login).
Don't be so quick to write it off.
Greg.
Dean Pentcheff
Better yet, read Thompson's article/lecture. The attack described is
fascinating in its insidiousness, but is also not an all-powerful
demon. I highly recommend the article as a really interesting read.
Some sources for it:
Thompson, Ken. Reflections on trusting trust. ACM Turing Award
Lecture, 1983.
Communcations of the ACM 1984, 27(8):761-763.
ACM Turing Award Lectures: The First Twenty Years 1965-1985. ACM
Press.
Denning, P.J. (ed.) 1990. Computers under attack: intruders, worms and
viruses. ACM Press.
-Dean
--
N. Dean Pentcheff <pent...@acm.org> WWW: http://tbone.biol.sc.edu/~dean/
Biological Sciences, Univ. of South Carolina, Columbia SC 29208 (803-777-3936)
PGP ID=768/22A1A015 Keyprint=2D 53 87 53 72 4A F2 83 A0 BF CB C0 D1 0E 76 C0
Get PGP keys and information with the command: "finger de...@tbone.biol.sc.edu"
Adam Morris
In article <k0zu3qf...@bolivar.cs.uiowa.edu>,
Larry Kingery <kin...@cs.uiowa.edu> wrote:
>I originally heard this bit of lore as a hidden "feature" of the
>original C compiler for unix, which would propagate itself into any
>compiler it created. Hence, all unix C compilers not written from
>scratch are infected.
That's odd, because a certain Ken Thompson gave a talk (his turing award
acceptance speech)called "Reflections on trusting trust"... it is available
online as
http://www.acm.org/classics/sep95/
Now, on re-reading that piece, it still doesn't strike me that the man was
lying. In fact he clearly states at one point "the actual bug I planted in
the compiler..." Anyway, it's certainly possible, whether it is being done or
not... :-}
>Needless to say, I didn't believe it then, either.
I don't believe the GCC/PGP one, but I can believe it of the original comment
from Ken Thompson...
Adam.
Larry Kingery
Dean Pentcheff <de...@tbone.biol.sc.edu> writes:
>
> g...@qualcomm.com (Gregory G Rose) writes:
> > In article <k0zu3qf...@bolivar.cs.uiowa.edu>,
> > Larry Kingery <kin...@cs.uiowa.edu> wrote:
> > >I originally heard this bit of lore as a hidden "feature" of the
> > >original C compiler for unix, which would propagate itself into any
> > >compiler it created. Hence, all unix C compilers not written from
> > >Ascratch are infected.
> > >
> > >Needless to say, I didn't believe it then, either.
> >
> > The story first appeared in Ken Thompson's ACM
> > Turing Award lecture, in 1979(?). It is true,
> > although the program in question was Dennis
> > Ritchie's C compiler for the PDP-11, which even
> > then obsoleted by Johnson's PCC. Gnu was unherd :-)
> > of at the time.
> >
> > It wouldn't propagate to other C compilers, only
> > itself, as it worked by recognising code in the
> > two affected programs (cc and login).
That's my point! By the time the story had spread, it was able to
recognize what it was compiling and propagate to other C compilers.
THAT'S what I don't believe. All I was trying to say is that this
current situation sounds a lot like the way this story got blown out of
proportion.
Please, no more mail telling me about the original hack. I know. I'm
not saying he didn't do it, I'm saying he didn't do what it was
rumored he did.
Larry
Boudewijn W. Ch. Visser
adam....@octacon.co.uk (Adam Morris) writes:
>In article <k0zu3qf...@bolivar.cs.uiowa.edu>,
> Larry Kingery <kin...@cs.uiowa.edu> wrote:
>>I originally heard this bit of lore as a hidden "feature" of the
>>original C compiler for unix, which would propagate itself into any
>>compiler it created. Hence, all unix C compilers not written from
>>scratch are infected.
No,not ANY compiler. Only the one that was available with all existing
Unix systems. This was very early in the history of Unix, so everybody
had the same Unix with the same compiler and the same sources.
[snip Ken Thompson description of login/compiler backdoor]
>I don't believe the GCC/PGP one, but I can believe it of the original comment
>from Ken Thompson...
AFAIK it is still not completely clear whether Ken Thompson actually -did-
implement this,or only described how it could have been done.
In those circumstances (one compiler to compile them,one compiler to link
them,one compiler to build them all :-) or some Tolkienesque variation)
the backdoor as described by Ken Thompson would have been possible.
There are now many different compilers, and lots of them used for bootstrapping
GCC. (so Thompsons doctored compiler that inserted a backdoor in clean source
would require a very grand conspiracy. Hoping that a backdoor directly in the
GCC would be overlooked seems naive. Many people do look at the sources,as
can be seen in gnu.gcc.bug,for example. )
With which compiler is the DOS version of PGP actually compiled ?
I hardly use the Dos-executable version,(so I haven't looked into it very much,
besides,I don't have any Dos C compilers), but I do hope that the compiler
used, the exact version and the exact Makefile or switches given are
documented somewhere,so that people can verify that the executable is
good.
Boudewijn
--
+-------------------------------------------------------------------+
|Boudewijn Visser |E-mail:vis...@ph.tn.tudelft.nl |finger for |
|Dep. of Applied Physics,Delft University of Technology |PGP-key |
+-- my own opinions etc --------------------------------------------+
Kurt M. Hockenbury
Boudewijn W. Ch. Visser (vis...@ph.tn.tudelft.nl) wrote:
: [snip Ken Thompson description of login/compiler backdoor]
:
: AFAIK it is still not completely clear whether Ken Thompson actually -did-
: implement this,or only described how it could have been done.
He did it.
From: j...@news.IntNet.net (Jay Ashworth)
Newsgroups: alt.sys.pdp10,alt.folklore.computers,comp.lang.lisp,alt.os.multics
Subject: The Thompson Login Trojan: The REAL Story
Date: 30 Apr 1995 01:11:47 -0400
Lines: 84
Message-ID: <3nv66j$b...@xcalibur.IntNet.net>
Keywords: horse, mouth
fho...@us.oracle.com (Forrest Howard) writes:
>In article <3n0hac$j...@crcnis3.unl.edu>, jhe...@herbie.unl.edu (jhesse) wrote:
>> Peter da Silva (pe...@bonkers.taronga.com) wrote:
>> : In article <WGD.95Ap...@martigny.ai.mit.edu>,
>> : Bill Dubuque <w...@zurich.ai.mit.edu> wrote:
>> : >"The actual bug I planted in the compiler would match code in
>> : >the UNIX "login" command..."
>> : I always heard he implemented it but didn't distribute it.
>> What did "it" do?
>Actually I think it was distributed. Ken talked about it at the 2nd? unix
>users group meeting at columbia. In my faded recollection I believe he
>said there was code in cpp that
>
>a) inserted code when compiling login.c (or was it init.c or gtty.c?) that
> added code to recognize a particular username/password independent of
> /etc/passwd.
>b) reinserted the trojen horse when recompiling cpp.c
Proving that the real Mrs. Robinson stood up.
It occured to me last week that k...@research.att.com is _still_ a valid
address, 25 years later... so I asked. Here, from Ken himself, is the
Real Story<tm>:
) From k...@plan9.att.com Sun Apr 23 14:42 EDT 1995
) Received: from plan9.att.com by IntNet.net (5.x/SMI-SVR4)
) id AA19375; Sun, 23 Apr 1995 14:42:51 -0400
) Message-Id: <9504231842.AA19375@ IntNet.net>
) From: k...@plan9.att.com
) To: j...@IntNet.net
) Date: Sun, 23 Apr 1995 14:39:39 EDT
) Content-Type: text
) Content-Length: 928
) Status: RO
)
) thanks for the info. i had not seen
) that newsgroup. after you pointed it
) out, i looked up the discussion.
)
) writing to news just causes more
) misunderstandings in the future. there
) is no way to win.
[ note: I asked him if he minded my posting the reply, he had no objection ]
) fyi: the self reproducing cpp was
) installed on OUR machine and we
) enticed the "unix support group"
) (precursor to usl) to pick it up
) from us by advertising some
) non-backward compatible feature.
) that meant they had to get the
) binary and source since the source
) would not compile on their binaries.
)
) they installed it and in a month or
) so, the login command got the trojan
) hourse. later someone there noticed
) something funny in the symbol table
) of cpp and were digging into the
) object to find out what it was. at
) some point, they compiled -S and
) assembled the output. that broke
) the self-reproducer since it was
) disabled on -S. some months later
) the login trojan hourse also went
) away.
)
) the compiler was never released
) outside.
)
) ken
Everyone: please save this post, so the next time the question comes up,
you can just go look. :-)
Cheers,
-- jr 'will bug legends for food' a
--
Jay R. Ashworth High Technology Systems Consulting Ashworth
Designer Linux: The Choice of a GNU Generation & Associates
ka1fjx/4 "I minored in babbling in college... and got +1 813 790 7592
j...@baylink.com honors in it." --Brian Heath NIC: jra3
Wim Lewis
In article <579rb9$o...@tor-nn1-hb0.netcom.ca>,
Vaughn Herbert Seward <sew...@netcom.ca> wrote:
>This thread originates from an E-mail I received about a WWW site
>someone saw with the paranoid theory that a trapdoor was placed in PGP
>by means of tampering with the GNU C compiler gcc.
>
>The fact that [a similar attack has been done], although still leaving it
>likely the specific rumor isn't real, does raise some questions.
>
>1) Where could you hide a backdoor in PGP? If someone tried to add a
>"key-escrow" segment, like the Clipper LEAF, to PGP messages, wouldn't
>people see it right away?
[several suggestions elided]
There are far subtler ways to leak information from a trojan PGP. For
example, when you encrypt a message with PGP, the key for the
conventional cipher is chosen randomly. There's no reason that the
"random" session key, or the many bytes of "random" padding required to
round out the session key to the size of the RSA key, couldn't contain
a few bits of information about the RSA secret key being used.
The larger the RSA key, the more payload space is available here.
If you send me enough messages encrypted using the doctored PGP, I
will eventually learn all of your secret key. And there's no obvious
incompatibility between your PGP and a non-trojan one; the channel is
steganographic, if you like.
If I (the evil attacker modifying your copy of PGP) am willing to
spend a bit more computational effort every time you encrypt, I can
even have the *encrypted* session key contain the leaked information.
That way, I can eventually learn your secret key just by eavesdropping
on enough of your encrypted traffic, even if it isn't addressed to me
or to anyone I know.
Likewise, any other piece of "random" data in the protocol (the CFB IV
for the symmetric-encoded packet, the low order few bits in a time
stamp) can be used by a hacked version of PGP as a covert channel to
sneak extra information into your outgoing messages, in such a way
that the resulting messages are indistinguishable from those produced
by the Real Thing, at least not without complex statistical tests
(and if it's done well, perhaps not even then).
I'm just listing a few things which come immediately to mind.
An expert in the field (which I am not!) could presumably point
out several other nasty applications for a PGP trojan horse.
--
Wim Lewis * wi...@hhhh.org * Seattle, WA, USA
PGP 0x27F772C1: 0C 0D 10 D5 FC 73 D1 35 26 46 42 9E DC 6E 0A 88
USENET: No Fun Anymore since 1987
8-Q
wi...@netcom.com (Wim Lewis) wrote:
>[several suggestions elided]
Interesting. I heard a rumor that there were 'fake' versions of PGP
circulating several months ago. It is interesting that a few weeks
ago the police here (UK) siezed some floppy disks from an active IRA
cell. One can assume that the encryption used was mil PGP, however
the contents were published within three weeks. Were they using
number crunchers or was there a back door?
Geoffrey T. Falk
In article <84964214...@coolbong.demon.co.uk>,
8-Q <8...@coolbong.demon.co.uk> wrote:
>
>Interesting. I heard a rumor that there were 'fake' versions of PGP
>circulating several months ago. It is interesting that a few weeks
>ago the police here (UK) siezed some floppy disks from an active IRA
>cell. One can assume that the encryption used was mil PGP, however
>the contents were published within three weeks. Were they using
>number crunchers or was there a back door?
We have a certain degree of insurance against tampering. The source
code for PGP and the compiler is freely available. While I have not
gone through it with a fine-tooth comb, the fact that I am allowed to
do this gives me a lot of confidence that there is no "active"
backdoor in the product.
That said, I think the pseudorandom-number algorithms are probably
by far the weakest part of PGP. It's hard to design a good PRNG, and
it's hard to evaluate the strength of a PRNG. Furthermore, PGP leaves
temporary files all over the disk, which could leave a trace, even if
they are overwritten and deleted. And it leaves a random seed file on
the disk.
Then there are attacks that are a lot easier than breaking the PRNG,
like Tempest; and it's not easy to come up with a strong passphrase
either.
g.
--
I conceal nothing. It is not enough not to lie. One should strive
not to lie in a negative sense by remaining silent. ---Leo Tolstoy
PER US CODE 47.227, UNSOLICITED E-MAIL ADS WILL BE BILLED $500/ITEM
Geoffrey T. Falk <g...@math.rochester.edu> http://www.cirp.org/~gtf/
Dr. Who
Geoffrey T. Falk (g...@math.rochester.edu) wrote:
: In article <84964214...@coolbong.demon.co.uk>,
: 8-Q <8...@coolbong.demon.co.uk> wrote:
: >
: >Interesting. I heard a rumor that there were 'fake' versions of PGP
: >circulating several months ago. It is interesting that a few weeks
: >ago the police here (UK) siezed some floppy disks from an active IRA
: >cell. One can assume that the encryption used was mil PGP, however
: >the contents were published within three weeks. Were they using
: >number crunchers or was there a back door?
: We have a certain degree of insurance against tampering. The source
: code for PGP and the compiler is freely available. While I have not
: gone through it with a fine-tooth comb, the fact that I am allowed to
: do this gives me a lot of confidence that there is no "active"
: backdoor in the product.
I am curious just how many people actually HAVE gone throught the PGP
2.6.2 source codes that are to be found on MIT? I'm also curious
how many people are reading this that have the knowledge required for
such an extensive task. I am looking into the subject, but have barely
scratched the surface; I've been told many times: if you don't trust it,
read the source. yeah... right.
: That said, I think the pseudorandom-number algorithms are probably
: by far the weakest part of PGP. It's hard to design a good PRNG, and
: it's hard to evaluate the strength of a PRNG. Furthermore, PGP leaves
: temporary files all over the disk, which could leave a trace, even if
: they are overwritten and deleted. And it leaves a random seed file on
: the disk.
: Then there are attacks that are a lot easier than breaking the PRNG,
: like Tempest; and it's not easy to come up with a strong passphrase
: either.
Is there somewhere that I might obtain some reasonably "credible" info
on TEMPEST? I read an old underground hack-file on it once, but I
have a hard time putting much faith in it...
--
------------------------------------------------
THINK FREE! | mi...@ripco.com
Knowledge is Power! | question everything!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Gus
8-Q (8...@coolbong.demon.co.uk) wrote:
: Interesting. I heard a rumor that there were 'fake' versions of PGP
: circulating several months ago. It is interesting that a few weeks
: ago the police here (UK) siezed some floppy disks from an active IRA
: cell. One can assume that the encryption used was mil PGP, however
: the contents were published within three weeks. Were they using
: number crunchers or was there a back door?
Hmm, you've got to be stupid to be a terrorist in the first place, so
assumption that those IRA (spit) fools were using pgp is not based
in anything solid.
By sheer number crunching, there was not enough time, which just leaves
a brute force passphrase attack, or a bit of rubber hose crypanalysis to
retrieve the passphrase.
--
- an...@intasys.com -
= http://www.thepulse.co.uk/angus =
-= 82 AA 4D 7F D8 45 58 05 6D 1B 1A 72 1E DB 31 B5 =-
AEC MADDEN
Gus (an...@intasys.com) wrote:
: 8-Q (8...@coolbong.demon.co.uk) wrote:
: : Interesting. I heard a rumor that there were 'fake' versions of PGP
: : circulating several months ago. It is interesting that a few weeks
: : ago the police here (UK) siezed some floppy disks from an active IRA
: : cell. One can assume that the encryption used was mil PGP, however
: : the contents were published within three weeks. Were they using
: : number crunchers or was there a back door?
: Hmm, you've got to be stupid to be a terrorist in the first place, so
: assumption that those IRA (spit) fools were using pgp is not based
: in anything solid.
: By sheer number crunching, there was not enough time, which just leaves
: a brute force passphrase attack, or a bit of rubber hose crypanalysis to
: retrieve the passphrase.
Doesn't it really rather depend on if they retrieved the secret key as
well as the messages? If they did it is a (relatively [1]) easy task to
read the messages.
cheers
--
Alex Madden - A.E.C....@Comp.Bradford.ac.uk
Department of Computing - Comp Sci
[1] Relative to doing what the above posters had suggested, ie brute
forcing a military strength key, or subverting it by adding code to gcc
and pgp source.
Jill Baker
aecm...@comp.brad.ac.uk (AEC MADDEN) wrote:
>Doesn't it really rather depend on if they retrieved the secret key as
>well as the messages? If they did it is a (relatively [1]) easy task to
>read the messages.
How?
Suppose I have a message encrypted to you, and I have your public and secret
keys, but _NOT_ your passphrase, how would I go about cracking the message?
Jill (my opinions are my own, no-one else's)
-----------------------------------------------------------------------
PGP Key ID: 0xB26FC709
Fingerprint: 72 C4 EB 30 E1 42 27 90 D0 76 A1 0D E1 52 0C 15
John Savard
jba...@madge.com (Jill Baker) wrote:
>aecm...@comp.brad.ac.uk (AEC MADDEN) wrote:
>>Doesn't it really rather depend on if they retrieved the secret key as
>>well as the messages? If they did it is a (relatively [1]) easy task to
>>read the messages.
>How?
>Suppose I have a message encrypted to you, and I have your public and secret
>keys, but _NOT_ your passphrase, how would I go about cracking the message?
Actually that is quite easy.
A PGP style message consists of two parts:
-- a header, containing a random session key, enciphered using RSA.
The header is enciphered using the recipient's public key; and the
recipient's secret key is exactly what is needed to decrypt it.
If PGP doesn't let you add somebody else's secret key to your keyring,
that is just a minor mechanical problem. Either write your own
implementation of RSA, or alter the source code. It isn't
cryptanalysis.
-- and then the actual message, enciphered using IDEA. The key here
is the random session key.
The passphrase of the recipient is used if you're at the console of
the recipient's computer, or have a copy of his keyring, in order to
get the recipient's secret key. But it's the secret key, not the
passphrase (useless without a copy of the keyring) that you need to
read a message.
John Savard
ph...@ix.netcom.com
John Savard wrote:
> The passphrase of the recipient is used if you're at the console of
> the recipient's computer, or have a copy of his keyring, in order to
> get the recipient's secret key. But it's the secret key, not the
> passphrase (useless without a copy of the keyring) that you need to
> read a message.
The secret key is equally useless without the passphrase. It consists of
the modulus and encryption exponent(which is the same as in the public
key and is stored in the clear) and the decryption exponent and a few
numbers to make decryption easier (all of which is encrypted with the
passphrase).
phma
Arnoud Galactus Engelfriet
-----BEGIN PGP SIGNED MESSAGE-----
In article <58ok54$6...@madge2.dev.madge.com>,
jba...@madge.com (Jill Baker) wrote:
> Suppose I have a message encrypted to you, and I have your public and secret
> keys, but _NOT_ your passphrase, how would I go about cracking the message?
You attempt to guess the passphrase. If you have that, cracking the
message is trivial.
Guessing the passphrase is a lot easier than any way to crack IDEA or
RSA. A program like PGPCrack can test phrases you supply, but a
more advanced program would also be able to do things that UNIX password
crackers do.
Galactus
- --
To find out more about PGP, send mail with HELP PGP in the SUBJECT line to me.
NEW ADDRESS: --> gala...@stack.nl <-- Please PGP encrypt your mail.
Finger gala...@turtle.stack.nl for public key (key ID 0x416A1A35).
Anonymity and privacy site: http://www.stack.nl/~galactus/remailers/
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: cp850
iQCVAgUBMrMNJTyeOyxBaho1AQGPygQAmc4KCshHLdNzRhL69Q9fqEosMOABqWv0
901pWtyYH6s7Ui9lJ+a7bwlINuPG2OOn961N0b+0S3VBdFan2MtHoQkFHmbhKGMG
14t060kLpUIomES5X5UY4ygCbAujZ4VLEpy4jr6S2RaVb/lPVfbUejyWSBkj6S+h
cRZ2HY04AEU=
=kgXF
-----END PGP SIGNATURE-----
tracer
On Thu, 12 Dec 1996 09:44:01 GMT, jba...@madge.com (Jill Baker) wrote:
>aecm...@comp.brad.ac.uk (AEC MADDEN) wrote:
>
>
>>Doesn't it really rather depend on if they retrieved the secret key as
>>well as the messages? If they did it is a (relatively [1]) easy task to
>>read the messages.
>
>How?
>
>Suppose I have a message encrypted to you, and I have your public and secret
>keys, but _NOT_ your passphrase, how would I go about cracking the message?
>
>
>
> Jill (my opinions are my own, no-one else's)
>-----------------------------------------------------------------------
> PGP Key ID: 0xB26FC709
> Fingerprint: 72 C4 EB 30 E1 42 27 90 D0 76 A1 0D E1 52 0C 15
>
A related question is that if you use pgp the settings are in the
environment. This means that any program being able to get data from
your system can read if you use pgp and where its located and that
means it can in theory steal your key.
With the many internet programs its a matter of time before someone
writes a script or whatever which will send your key back mixed in
with other data so you wouldnt even notice it.
If you have public and secret key, I found that cracking my own
phrase was a matter of about 20 minutes. However I use a short one.
If you have that as well in the environment as some people do, you may
just as well publish your key...\
In my case contents arent really secret anyway so it doesnt worry me.
Even if your key is hidden some programs make copies and in general
they sit (deleted) in the temp directory.
Again a fairly easy excercise for a programmer to see if you have pgp
and if the key cannot be found as on my system, then to go to the
temp directory as specified in the environment and to see if any
deleted files are your key.
Alebeard
even if the key is compromised, and the pC os compromised, how would the pass
phrase be aquired? is there any way for a progamer to take apart your key and
aquire it? aside from quessing it, how secure is the pass phrase if the key is
obtained?
John Savard
ph...@ix.netcom.com wrote:
The _keyring_ is useless without the passphrase, because it contains
only an _encrypted_ copy of the secret key.
The secret key _itself_, that is, the exponent d (and the modulus M,
which is also found in the public key), is sufficient to decrypt
anything sent in RSA. From that, you get the session key, and decrypt
the message.
Don't call the "keyring" the "secret key". If that's what the original
poster did, which is not at all necessarily true, that will only
confuse everybody.
John Savard
Jill Baker
sew...@netcom.ca (John Savard) wrote:
>Don't call the "keyring" the "secret key". If that's what the original
>poster did, which is not at all necessarily true, that will only
>confuse everybody.
>John Savard
Point taken, but my original question (rephrased in the correct jargon) still
stands:
Suppose I have a message encrypted to you, and I have your public and secret
keyrings (the files pubring.pgp and secring.pgp which I have copied from your
computer), but _NOT_ your passphrase, how would I go about cracking the
message?
I am rather hoping that the correct answer is "It can't be done". If not, I'll
have to rethink my PGP usage strategy.
Boudewijn W. Ch. Visser
jba...@pobox.com (Jill Baker) writes:
>sew...@netcom.ca (John Savard) wrote:
>>Don't call the "keyring" the "secret key". If that's what the original
>>poster did, which is not at all necessarily true, that will only
>>confuse everybody.
>>John Savard
>Point taken, but my original question (rephrased in the correct jargon) still
>stands:
>Suppose I have a message encrypted to you, and I have your public and secret
>keyrings (the files pubring.pgp and secring.pgp which I have copied from your
>computer), but _NOT_ your passphrase, how would I go about cracking the
>message?
>I am rather hoping that the correct answer is "It can't be done". If not, I'll
>have to rethink my PGP usage strategy.
Whether or not it can be done depends on the passphrase. You can try to
guess it , and in some (many ?) cases you will succeed.
ChrisTof
Dr. Who wrote:
>
> Geoffrey T. Falk (g...@math.rochester.edu) wrote:
> : In article <84964214...@coolbong.demon.co.uk>,
> : >
> : >Interesting. I heard a rumor that there were 'fake' versions of PGP
> : >circulating several months ago. It is interesting that a few weeks
> : >ago the police here (UK) siezed some floppy disks from an active IRA
> : >cell. One can assume that the encryption used was mil PGP, however
> : >the contents were published within three weeks. Were they using
> : >number crunchers or was there a back door?
the "suspects" were under surveillance with some kind of tempest
installation or their machine was "sligthly modified" :)
Then, once they knew everything the suspects were typing/displaying
on their machine, it probably became trivial to send the police to
collect the disks.
It is much less expensive and by far easier than trying to brute force
PGP (with chance of failure).
Or one of suspects may simply gave them the secret key...
Tof
Timothy Miller
ChrisTof <chr...@voice.imaginet.fr> writes:
> Or one of suspects may simply gave them the secret key...
Or the secret keyring was collected with the rest of the data,
and the passphrase was bleedingly obvious.
--
Cerebus <tmi...@ims.advantis.com>
PGP Fingerprint: BC AB 28 19 A6 A4 FF 5B CA 4D B4 03 3A A7 F4 5C