Cryptography-Digest Digest #533, Volume #12 Fri, 25 Aug 00 09:13:00 EDT
Contents:
Re: Serious PGP v5 & v6 bug! (Ian Bell)
PGP Bug: IMPORTANT Personal test report ("Michel Bouissou")
Re: The DeCSS ruling (Daniel James)
My encryption algorithm ("Slava K.")
Re: PGP Bug: IMPORTANT Personal test report ("Michel Bouissou")
Re: SHA-1 program (cool!) (Mark Wooding)
"Warn when encrypting to keys with an ADK" (S.R. Heller)
Re: How many bits of strength does the ZIP encryption have? (Tim Tyler)
Re: Bytes, octets, chars, and characters (Joona I Palaste)
Re: Steganography vs. Security through Obscurity ([EMAIL PROTECTED])
Re: "Warn when encrypting to keys with an ADK" ("Michel Bouissou")
Re: Steganography vs. Security through Obscurity ([EMAIL PROTECTED])
Re: PGP Vulnerability ("Cheri & Mike Jackmin")
UNIX Passwords ("Martin 'SirDystic' Wolters")
----------------------------------------------------------------------------
From: Ian Bell <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: Fri, 25 Aug 2000 12:03:00 +0100
In message <[EMAIL PROTECTED]>, Sam Simpson
<[EMAIL PROTECTED]> writes
>Original from Dr R.Anderson, uk-crypto mailing list.
>The effect is that GCHQ can create a tampered version of your PGP
>public key containing a public key whose corresponding private key is
>also known to themselves, and circulate it. People who encrypt
>traffic
>to you will encrypt it to them too.
Is it possible to put a public key within a public key and for it to
work?
I've tried using PGP6.5.3 to encrypt to a key that had an ADK on it. The
result was that PGP raised an error that I didn't have the ADK's public
key on my keyring and proceeded to just encrypt to the real recipient.
The error message told be that I should ask the recipient for the ADK's
public key.
Therefore it would seem that for GCHQ to exploit the bug, they would
have to add an ADK to Joe Bloggs' key and have to lure people into
downloading the GCHQ public key...
...unless of course, they could put the GCHQ public key _within_ Joe
Bloggs' tampered key and have PGP recognize and use it.
--
Ian Bell T U R N P I K E
------------------------------
From: "Michel Bouissou" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: PGP Bug: IMPORTANT Personal test report
Date: Fri, 25 Aug 2000 13:20:49 +0200
Well folks,
To be able to diagnose the EXACT behaviour of my PGP 6.5.2 Freeware /
Windows, I made some tests myself which will help understanding how PGP
behaves when encrypting to keys with a forged ADK.
My PGP has the following settings:
- Warning when encrypting to key with an ADK set to ON;
- Display of the ADK column in PGPkeys set to ON.
For this, I imported forged test keys gotten from Ralf's website in the
following way:
1) I imported Key-B1, which is "Billy Clean's" key to which a forged ADK was
added
- This key shows up in PGPKeys with the ADK circle being RED, which
immediately identifies this key as containing a forged ADK.
- The properties of the key shows an ADK tab, in which I see the unknown key
(keyID) being an enforced ADK.
==> FIRST CONCLUSION: It is immediately visible in PGPkeys that the key
contains an ADK, although PGP doesn't detect that this ADK is a forged one.
2) From the explorer, I encrypted a text file to "Billy Clean's" key and
mine as well.
- As soon as I select "Billy Clean's" key in the recipient key selection
box, I get a dialog box that states:
"The user Billy Clean has a missing Additional Decryption Key". Contact the
owner of the key to obtain the additional decryption key"
- I click on OK then see only my own key and Billy's one in the selected
recipients field.
- I encrypt and all goes well.
- Now I try to decrypt the file. The dialog box shows the file was encrypted
to BILLY and MYSELF, no visible trace of another decryption key.
- I can decrypt the file.
3) Now I import Key-C into my keyring, which is the public key of the
"forger" of Billy's key -- The ADK's public key.
- The "ADK" tab in Billy's public key properties box now shows that his ADK
is "control" (the newly imported key).
4) From the explorer, I encrypt again a text file to "Billy's" key and mine
as well.
- As soon as I select "Billy's" key in the recipient selection box, BOTH
BILLY'S KEY *AND* CONTROL'S one drop into the selected recipients field.
- IT IS THUS VISIBLE THAT "CONTROL" WILL BE ABLE TO DECRYPT THE MESSAGE
- NO SPECIFIC WARNING DIALOG BOX HAS BEEN ISSUED BY PGP although the "Warn
when encrypting to key with an ADK" option was selected.
==> SECOND CONCLUSION: The warning option doesn't seem to work at all in
this situation, but it is visible that there will be a supplementary
recipient that was not selected by the sender.
- Now I encrypt the file
5) I try to decrypt the file
- The decryption passphrase box shows me that the file is encrypted for ME,
BILLY and CONTROL. It is thus visible to me that CONTROL is able to decrypt
the file.
- The file decrypts OK
==> IMPORTANT NOTE:
- In the first place, me not having the ADK public key, it seems that the
file was NOT encrypted to the ADK
- In the 2nd place, me HAVING the ADK public key, the file was visibly
encrypted to the ADK as well
THIS IS MOST IMPORTANT. Reading carefully Ralf's paper, the ADK public key
seems NOT to be actually included in public keys that mention mandatory use
of this ADK. YOU MUST HAVE THE ADK public key as well. Only the ADK's key ID
is included in the key that holds and ADK, which is not enough to allow
encryption to the ADK by itself.
==> IF YOU ENCRYPT A MESSAGE TO A KEY WITH AN ADK, but DO NOT have the ADK
public key in your own keyring, PGP warns that the ADK key is missing, then
apparently DROPS it and accepts to encrypt to the intended recipient ONLY,
and NOT to the ADK !!!!!
THIS DRAMATICALLY LOWERS THE RISK OF EXPLOITATION OF THIS BUG, because if
you receive a key with a forged ADK for one of your correspondants, you
would ALSO NEED to have the forged ADK's public key in YOUR own keyring to
make PGP able to encrypt for this key. Without this ADK public key, PGP will
warn you that it is missing, and will just drop it and encrypt for the
recipient only !
- And there is a low probability that you have this attacker's key in your
ring... If yes, you might be able to easily identify the attacker.
SUMMARY OF RESULTS:
=====================
According to the tests I made:
1) Keys with an ADK (forged or not) can be clearly visible in PGPkeys
2) The "warn to encrypt to key with an ADK" feature does NOT seem to work
3) The ADK's recipient key gets clearly visible in the "recipient selection
box" as soon as you select a recipient key that holds an ADK and you have
the ADK's public key in your keyring as well.
4) Due to the faulty (2), the existence of the ADK COULD BE INVISIBLE when
the selection of recipient keys is automatic (and thus the selection box is
bypassed), i.e. when using an e-mail software plugin. But I had no occasion
to test this yet.
3) You MUST have the ADK's public key in your ring for PGP to encrypt a
message to this ADK
4) If you don't, PGP issues a warning and bypasses the ADK. ENFORCEMENT OF
ADK IN PGP is NOT STRICT, you can bypass it as soon as you don't have the
ADK's public key in your ring !
FINAL CONCLUSIONS:
===================
In light of this, it appears to me that the COMPLETE IMPLEMENTATION OF THE
ADK SYSTEM IN PGP IS SERIOUSLY FLAWED and doesn't meet the security and
quality standards expected for such critical software.
- ADKs can be forged onto public keys in an unacceptable manner;
- Wanted (option selected) warning messages are not displayed;
- Enforcement of the ADK policy is not strict and can be bypassed, which
doesn't suit the needs of organizations that want to make sure that the ADK
policy HAS TO BE APPLIED in all cases.
And all this is very disappointing to me.
--
Michel Bouissou <[EMAIL PROTECTED]> PGP DH/DSS ID 0x5C2BEE8F
Network Administrator - Internet Quake - http://www.i-quake.com
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: The DeCSS ruling
Date: Fri, 25 Aug 2000 12:20:27 +0100
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Mark Wooding wrote:
> > Quid custodes ipso custodian
>
> I think you mean `Quis custodet ipsos custodes?' What you've written
> makes no sense.
At risk of seeming Juvenal, it's `Quis custod*i*et ipsos custodes?'
------------------------------
From: "Slava K." <[EMAIL PROTECTED]>
Subject: My encryption algorithm
Date: Fri, 25 Aug 2000 14:27:26 +0200
I have designed a new encryption algorithm, and would like comments about
it's security. The following is a specification of the algorithm in general
programming terms. Tell me what you think. EMail me your comments
([EMAIL PROTECTED]).
� A password of any size is inputted (K). If K is the length of zero or one,
and error is reported.
� A counter � N1 is set to the first character of the password. N2 is set to
the second.
� The two password character (Respective to N1 and N2. They may be converted
to integers or bytes if required by the language) are XORed together (X).
� A character is read from the input file (P. This can again be converted
into an integer or a byte if required) and XORed with X.
� The result is written to the output file.
� If N1 equals the size of K, it is set to 1. Otherwise, N1 equals N1 + 1.
� If N2 equals the size of K, it is set to 1. Otherwise, N2 equals N2 + 1.
� The process is repeated if there are any characters left to encrypt.
------------------------------
From: "Michel Bouissou" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP Bug: IMPORTANT Personal test report
Date: Fri, 25 Aug 2000 13:34:24 +0200
Michel Bouissou <[EMAIL PROTECTED]> a �crit dans le message :
8o5kqk$mls$[EMAIL PROTECTED]
>
> 1) I imported Key-B1, which is "Billy Clean's" key to which a forged ADK
was
> added
>
> - This key shows up in PGPKeys with the ADK circle being RED, which
> immediately identifies this key as containing a forged ADK.
Sorry, I mean't "an ADK", not "a forged ADK"
--
Michel Bouissou <[EMAIL PROTECTED]> PGP DH/DSS ID 0x5C2BEE8F
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: SHA-1 program (cool!)
Date: 25 Aug 2000 11:36:18 GMT
S. T. L. <[EMAIL PROTECTED]> wrote:
> <<Use unsigned long long instead of unsigned long int, unsigned long
> int are about 32 bits while unsingned long long are about 64 bits (as
> "required" by fips 180-1).>>
>
> I'm certain that unsigned long long is *not* C89 standard. It might be C99
> standard, but I know nothing about C99 yet. I don't know if DJGPP supports
> long longs.
C89 doesn't support `long long'. C99 does; there's an off-topic rant
about the way it's been added. DJGPP will support `long long', because
it's derived from GCC and GCC's supported it for ages.
> Yeah, I looked at that too. Since my problems appear to come from
> really long files, those vectors aren't useful to me. I'd like it if
> someone could independently hash a file of 1,000,000,000 "a"
> characters, using a program that's not SHA1.EXE, SHA1.COM, or
> HASHcipher.
OK, that was easy. I've tried three implementations (OpenSSL, Perl
Digest::SHA1, and Catacomb's hashsum). All agree that the SHA1 hash of
10^9 `a' characters is d0f3e4f2f31c665abbd8f518e848d5cb80ca78f7.
Just to really test things out, I've also tested 8 x 10^9 `a' characters
(which is well over 2^{32} *bytes*). My implementation (Catacomb
hashsum), and the Perl one (by Peter Gutmann) agree that the right
answer is 6295dd8c1d5b704c85a361033eb5e7d9d6f1dc71; however, OpenSSL
gets 8d42fe8154924bc142d3f0ec75bac769ebb71113 instead for some reason.
I've glued some instrumentation to my implementation and checked the
padding is correct (which it is), so I'm confident that I got the right
answer. (I also noticed a portability bug which needs fixing. That
won't be hard, though.)
> <<DJGPP supports unsigned long long>>
>
> Oooh, good. Cool. I'll probably be using that now.
Not what I'd have recommended, but I can't really object...
-- [mdw]
------------------------------
From: S.R. Heller <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: "Warn when encrypting to keys with an ADK"
Date: Fri, 25 Aug 2000 04:56:48 -0700
Reply-To: [EMAIL PROTECTED]
=====BEGIN PGP SIGNED MESSAGE=====
I think there is some (quite understandable) misunderstanding about
this option in NAI's PGP. Despite what the average English-speaker
might think, the phrase does not mean, "If I encrypt to a public key
with an ADK, warn me." Those of you with a key with an ADK (called
internally an Additional Recipient Request) on it can see that this
doesn't happen. What the option means is, "If I encrypt to a public
key with an ARR, and then try to remove the ADK from the recipient's
list [i.e., from the lower pane in the select recipients dialog],
warn me that this might be 'violating the policy' established for the
key with the ARR." That's a mouthful, but you can test it yourself to
see what I mean.
Assuming your ring has a key with an enforced ARR and the
corresponding ADK, try this, using the usual PGP clients (encrypt
with clipboard or via Explorer or whatever):
1. Switch off "Warn when ..."
2. Try to encrypt something with the key with the ARR. You'll see the
ADK added to the recipients automatically.
3. Select the ADK and drag it out of the recipients list. The key
with the ARR remains.
Now switch on "Warn" and repeat the above. When you try to remove the
ADK, you'll see a dialog warning you about violating policy. That's
the "warning" they're talking about -- not something with a big red
Stop sign saying, "Hey, you're about to encrypt to an ADK, mister!"
(Note that if the ARR is unenforced you shouldn't be warned in either
case. The enforcement status can be viewed with the key's other
properties by right-clicking on the key in PGPKeys. A red ball means
'enforced'.) You should still be able to remove the ADK from the
recipients list, but you've been warned that the receiving site might
not like the ciphertext if it doesn't have the ADK. The "Warn" option
really means, "Warn me if I'm violating a remote site's ADK policy by
encrypting to X without encrypting to Y." With this option, you will
also receive a warning when the ADK isn't on the local ring. Again,
the meaning is not at all what you might think: it's not warning you
about something for your own security, but warning that your message
might be violating a remote site's ADK policy.
This might not work the same way in all versions, and I think it can
also be affected by preferences set by your administrator (if you
have one). I believe the business versions have a further 'strict'
setting where, if this is activated, you'll see (v6.5.x) a little
padlock next to the ADK on the recipients list, and you won't be
warned about policy if you try to drag the ADK off -- you'll be
stopped and told that you can't encrypt to the key with the ARR
without also encrypting to the ADK. This is, in NAI PGP's internal
language, enforcing a remote ADK.
If anyone needs some examples of enforced vs. not-enforced ARR'd keys
for testing, I've got two here, along with a test key (which has
nothing to do with ADK and can be ignored) and the corresponding ADK:
<http://www.oz.net/~srheller/spgp/bin/testkeys.asc>
The keys include private keys, which all have the passphrase
"testing".
Steve H.
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.1 for non-commercial use <http://www.pgp.com>
iQCVAwUBOaZetU/8MJkAFkZtAQFf6gQAoq9i1mCjayRAxdD+TE+BbMETVktml8vN
HLADbeIBPdiZAHy+4L8ADvtJ1iVrZcphaQyCXMibUEx91msYAdUeH7u8V5yJBDld
Tn5+U8Dk/PXCD2aoefXRBmm5o/g14bV34/RQUmcBxeeaMm9dANi8OsFXrYReK92t
60pDoPySj1o=
=ueim
=====END PGP SIGNATURE=====
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: How many bits of strength does the ZIP encryption have?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 25 Aug 2000 11:43:02 GMT
Roadkill <[EMAIL PROTECTED]> wrote:
: Sundial Services wrote:
:> Actually, Tim, about a year and a half ago I investigated the
:> possibilities of cracking PKZip's cipher -without- knowing plaintext and
:> actually succeeded in doing so from time to time, using a variation of
:> the published known-plaintext attack.
:>
:> The essential observation that I made and was pursuing off-and-on is
:> that the frequency characteristics (and a metric I called "bit density")
:> in a compressed file are very, very predictable. You can readily tell
:> if the data is compressed-anything or if random noise (a la
:> cryptography) has been injected into it. And you can modify, relax,
:> loosen the tests made by the published algorithm -- so that they are not
:> looking for "exact" bytes in each of the 12 positions (say), but only
:> "probable" ones.
:>
:> It helps considerably that most Zip files are -archives- containing
:> dozens or even hundreds of members, all of which are likely to have
:> similar frequency characteristics and sometimes even blocks of very
:> similar data, especially in the first few hundred bytes.
: Very interesting. So basically you are saying that compressing plain
: text /before/ encrypting like PGP does isn't such a good idea after
: all. I have to remember this.
I'd have thought failure to compress "plain text" would be likely to
provide even more probably-known plaintext.
At any rate, I don't beleive that the conclusion you present follows
logically from the statements above - or that the conclusion is correct.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: Joona I Palaste <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,alt.folklore.computers
Subject: Re: Bytes, octets, chars, and characters
Date: 25 Aug 2000 11:50:14 GMT
AndyC <[EMAIL PROTECTED]> scribbled the following
on comp.lang.c:
: On Fri, 25 Aug 2000, G Swaine wrote:
:> The '020 required instructions to be on even addresses, AFAICR
: That was a requirement of all 68k chips, IIRC.
Yes it was. When I was programming on my 68000-based Amiga 500, I was
once searching for a method to intentionally crash the computer. I
found that it could be done by modifying a 16-bit word on an odd
address.
Processor trivia: The 6510 microprocessor includes the instruction
JAM (code 0x02), which will completely hang (ie. jam) the computer.
To be able to proceed, you must do a power-cycle. What the heck is the
use of this instruction?
--
/-- Joona Palaste ([EMAIL PROTECTED]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #80 D+ ADA N+++ |
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"I am not very happy acting pleased whenever prominent scientists overmagnify
intellectual enlightenment."
- Anon
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Steganography vs. Security through Obscurity
Date: Fri, 25 Aug 2000 12:00:30 GMT
In article <8o39ro$210$[EMAIL PROTECTED]>,
David A Molnar <[EMAIL PROTECTED]> wrote:
{many excellent ideas. ]
- Thanks! - Bruce
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Michel Bouissou" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: "Warn when encrypting to keys with an ADK"
Date: Fri, 25 Aug 2000 14:10:01 +0200
S.R. Heller <[EMAIL PROTECTED]> a �crit dans le message :
8o5n05$kiv$[EMAIL PROTECTED]
>
> I think there is some (quite understandable) misunderstanding about
> this option in NAI's PGP. Despite what the average English-speaker
> might think, the phrase does not mean, "If I encrypt to a public key
> with an ADK, warn me."
Yes, there indeed is such a misunderstanding !!!
I'm a frenchman and english is not my own language, and I was stupid enough
to think that when selecting and option that says "Warn when encrypting to
keys with an ADK" I probably would get warned "when encrypting to keys with
an ADK"...
How stupid!
I guess I need some more english lessons before I can understand "N.A.I.'s
english".
Thank you Steve for the explanation, but I have this strange feeling
somebody out there is taking us for fools...?
--
Michel Bouissou <[EMAIL PROTECTED]> PGP DH/DSS ID 0x5C2BEE8F
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Steganography vs. Security through Obscurity
Date: Fri, 25 Aug 2000 12:07:22 GMT
In article <8o3g28$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Guy Macon) wrote:
> Not needed - the solution is trivial.
[deleted...]
Thanks, Guy (and Doug).
Well, I was interested in the application of Traitor Tracing.
If the message obviously includes encoded information, then the traitor
won't pass it on.
I'll look into the other references given. Thanks for all of the help.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Cheri & Mike Jackmin" <[EMAIL PROTECTED]>
Subject: Re: PGP Vulnerability
Date: Fri, 25 Aug 2000 08:45:37 -0400
>Personally, I'm switching to the GNU version of GPG as soon as it becomes
>available in a Win98 build. See http://www.gnupg.org/gpa.html.
>I don't my crypto to have key escrow capability.
Keep in mind that the vulnerability will still exist not matter what version
you are using; it depends upon exploiting a weakness in the sender's
software, not the recipients.
My free Windows version of PGP will alert me if I am encrypting a message to
an ADK; furthermore, I can check an option in the View menu to see if any
ADKs are associated with the public keys on my ring. This allows me to
detect if a public key has been potentially compromised and to alert the
owner. (I have a link to the latest versions of PGP from my home page at
www.lightlink.com/critters)
I have not yet heard of a good solution to this problem. It's not a
catastrophe, but it is pretty bad.
MikeJ
------------------------------
From: "Martin 'SirDystic' Wolters" <[EMAIL PROTECTED]>
Subject: UNIX Passwords
Date: Fri, 25 Aug 2000 14:56:09 +0200
Hi,
Is there a description available,
how UNIX encrypts (or hashes) its
Passwords?
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
