Cryptography-Digest Digest #914, Volume #9 Tue, 20 Jul 99 08:13:03 EDT
Contents:
Re: WinZip secure? ([EMAIL PROTECTED])
Re: Looking for RC4 alternative ("Larry Ellis")
Re: another news article on Kryptos (Jim Gillogly)
[Q] Finding K from P and C ("Sungmin Chun")
Re: another news article on Kryptos (Jim Gillogly)
Re: [Q] Finding K from P and C (Jim Gillogly)
Re: How to crack monoalphabetic ciphers (Jerry Coffin)
Re: How to crack monoalphabetic ciphers (Jerry Coffin)
Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length? (Jerry
Coffin)
Re: Looking for RC4 alternative (fungus)
Meta-Certificate Group moved site? (Anonymous)
Re: A Good Key Schedule (Mok-Kong Shen)
Kryptos is a puzzle, an image ("collomb")
Re: [Q] Finding K from P and C (Klaus Pommerening)
Re: Does base64 encoding lessen security? (Eric Young)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: WinZip secure?
Date: Tue, 20 Jul 1999 01:44:32 -0400
> I want to know how much secure zipped file with password.
> Are there methods to crack zipped file with password?
The encryption algorithm that comes with pk zip is not secure at all.
There are methods to crack it by brute force...but those are not very
time effective. To break it, you need about 40 to 200 bytes of
plaintext. If the compressed file has any headers (such as a ms word
document etc). It's easy to get the plaintext and decrypt the file.
(Applied Cryptography 395)
------------------------------
From: "Larry Ellis" <[EMAIL PROTECTED]>
Subject: Re: Looking for RC4 alternative
Date: Tue, 20 Jul 1999 00:53:53 -0500
>
> I know for certain that we CANNOT use RC4 in our release product (what a
> shame, as it's so easy to code), so I'm really keen to hear of alternative
> stream ciphers we can use for free. Our product is for a niche market
where
> only superficial hacking might be expected, so ease of coding is more
> important than super strength scrambling.
I don't know why ease of coding is an issue, since there is an assortment of
alorithms available with good source code examples.... Blowfish, Twofish,
and TEA are all easy to find. These are block ciphers but are trivial to
adapt for stream mode (see "Applied Cryptography", Schneier).
If you insist on very short simple code, try TEA (be sure to use the
"Extended" variant). I have the (very brief) papers on Tea and XTEA, and
can email them to you if you like. TEA has been the subject of a few
security concerns in this group, but it sounds as if it may be adequate for
your needs.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: another news article on Kryptos
Date: Mon, 19 Jul 1999 21:56:45 -0700
Douglas A. Gwyn wrote:
> Actually, the idea of running billions of guesses isn't very
> productive when you don't know what kind of system you're dealing
> with. If I were analyzing it, which I don't currently have time
> to do, I'd assume one of the likely candidate systems such as
> plaintext autokey, then use special methods (such as chaining)
> that are relevant for C/A of such systems. Any guesswork at the
> initial stage would be limited to (a) trying probable words and
> (b) using ancillary possible clues, such as the KRYPTOS mixed
> alphabet.
While I agree that that's preferable in general, I don't have any
special methods for one of my top three candidates, and it has a
lot of potential initial key set-up conditions. Another of my
favorites has some nice special methods, but only for more ciphertext
or known plaintext, so again I'm reduced to massive hill-climbing.
I've definitely had the KRYPTOS mixed alphabet in all its forms as
one of my numero uno tries on each possible system, though.
--
Jim Gillogly
Highday, 27 Afterlithe S.R. 1999, 04:52
12.19.6.6.15, 13 Men 3 Xul, Ninth Lord of Night
------------------------------
From: "Sungmin Chun" <[EMAIL PROTECTED]>
Subject: [Q] Finding K from P and C
Date: Tue, 20 Jul 1999 15:44:37 +0900
Hi, there.
E(P, K) = C
where
P : Plain text
C : Cipher text
K : Key
E(P, K) : Encryption method
Can we find K easily for well-known E(P,K)
when P and C are given?
####################################
Associate Research Engineer
Institute for Advanced Engineering
[EMAIL PROTECTED]
####################################
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: another news article on Kryptos
Date: Tue, 20 Jul 1999 00:34:36 -0700
Douglas A. Gwyn wrote:
> Just out of curiosity, what does its modulo-26 FFT spectrum look like?
Beats me -- would I go to Kullback's "Statistical methods" for that?
--
Jim Gillogly
Highday, 27 Afterlithe S.R. 1999, 07:33
12.19.6.6.15, 13 Men 3 Xul, Ninth Lord of Night
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: [Q] Finding K from P and C
Date: Tue, 20 Jul 1999 00:36:58 -0700
Sungmin Chun wrote:
> E(P, K) = C
> where
> P : Plain text
> C : Cipher text
> K : Key
> E(P, K) : Encryption method
>
> Can we find K easily for well-known E(P,K)
> when P and C are given?
It depends entirely on E.
--
Jim Gillogly
Highday, 27 Afterlithe S.R. 1999, 07:35
12.19.6.6.15, 13 Men 3 Xul, Ninth Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: How to crack monoalphabetic ciphers
Date: Tue, 20 Jul 1999 03:37:07 -0600
In article <7mn9pq$ea6$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> Only in LZ78 and LZW (of the LZ methods) can you truly have invalid
> codes. This is a waste of space though. If for the first 100 bytes
> only the lower 7 bits of the lookup are being used then there is wasted
> space (if your index is 10 bits for example). In LZ77 and LZSS same
> thing however the codes should still be accepted (producing garbage
> out) since it's perfectly valid to read out of the ring buffer at any
> point (it's easier to code for this assumption then check the CRC
> afterwards).
Think about things for a moment. We know that a properly functioning
LZSS compressor will never produce an offset of -1024 (to use your
example) for the first byte, nor for any byte before 1024 bytes into
the input. We also know that it'll never produce a length greater
than the current offset into the input.
Now, our whole idea here was to figure out whether a particular
decoding was valid. Since we know that valid plaintext won't contain
these values, we can reject any decoding that contains them. Given
that you usually use a fairly large ring-buffer with LZSS (to maximize
the possibility of finding the string), this means there's a fairly
large section of a file in which certain codes cannot occur.
Given a bad decoding of a file, what are the chances that we won't
produce one of those codes that can't occur? We have to postulate
accidentally producing a few kilobytes of output that don't contain a
certain set of values. At the very beginning of the file, the illegal
values outnumber the legal ones by a LARGE margin, meaning that our
chances of a bad decoding producing a value we KNOW couldn't be there
is actually pretty good. I haven't done an extensive analysis, but my
guess is that we could eliminate well over 99% trial decodings based
entirely upon this, without having to go the next step and decompress
the plaintext to see if it looks reasonable.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: How to crack monoalphabetic ciphers
Date: Tue, 20 Jul 1999 03:37:16 -0600
In article <7mnued$nfm$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> > Then hybrid systems like LZSS+huffman or LZ77+huffman would really
> > throw this off?
> >
> Maybe not. If it's compressed with one, it may not compress at all with
> the other. Not sure though, not a compression expert.
That depends. If you try to combine two compression techniques that
work in roughly similar ways, such as LZSS with LZ77 or Huffman with
Shannon-Fanno, you will only rarely improve results over using only
one by itself -- often the result will be even worse than a single
compression.
OTOH, combining compressors from different families (e.g. Huffman with
an LZ*) often works quite well (though it's still not as good as just
a direct addition of the compression you get from each on its own).
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length?
Date: Tue, 20 Jul 1999 03:37:27 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ I waited to reply to this until I had a chance to re-read the
Memorandum Of Understanding between NSA and NIST ]
> NSA does not have "veto" power over NIST nor AES in particular.
> NSA has an official role in protection of *governmental* data,
> but none whatsoever in the "private sector".
This may be true to some degree. However, most standards issued by
NIST have bearing both the private sector AND on governmental
agencies, meaning that the NSA gets involved in nearly all of them.
The following are extracted from the MOU (as quoted in AC2):
---- start of quotes -----
I. The NIST will:
4. Develop telecommunications security standards for protecting
sensitive unclassified computer data, drawing upon the expertise and
products of the National Security Agency, to the greatest extent
possible, in meeting these responsibilities in a timely and cost-
effective manner.
6. Request the NSA�s assistance on all matters related to
cryptographic algorithms and cryptographic techniques including but
not limited to research, development evaluation, or endorsement.
III. The NIST and the NSA shall:
5. Establish a Technical Working Group to review and analyze issues of
mutual interest pertinent to protection of systems that process
sensitive or other unclassified information. The Group shall be
composed of six federal employees, three each selected by NIST and
NSA...
7. Ensure the Technical Working Group reviews prior to public
disclosure all
matters regarding technical systems security techniques to be
developed for use
in protecting sensitive information in federal computer systems to
ensure they are consistent with the national security of the United
States. If NIST and NSA are unable to resolve such an issue within 60
days, either agency may elect to raise the issue to the Secretary of
Defense and the Secretary of Commerce. It is recognized that such an
issue may be referred to the President through the NSC for resolution.
No action shall be taken on such an issue until it is resolved.
---- end of quotes ----
To summarize: if NIST writes a standard that will be used on
government data, the NSA can (at the very least) cause extreme
difficulty in its adoption if it so chooses. Given that the current
DES allows its use on unclassified government data, I believe it's
safe to say that AES will be specified for use on government data as
well. This means that NIST is obliged to use NSA resources to the
greatest extent possible in evaluating it. If it comes to a point
that the NSA really doesn't want a particular algorithm chosen, and
the NIST does, they could end up getting issues referred to the
president a few dozen times (IAW III.7), which would almost certainly
throw a wrench in the works of its being accepted.
IOW, no, they don't have direct and absolute veto power over NIST
decisions. OTOH, they do have the ability to cause enough problems in
adopting a standard, that it's nearly certain that NIST won't manage
to adopt a standard of which the NSA strongly disapproves.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Looking for RC4 alternative
Date: Tue, 20 Jul 1999 09:46:39 +0200
[EMAIL PROTECTED] wrote:
>
> > I know for certain that we CANNOT use RC4 in our release product (what a
> > shame, as it's so easy to code), so I'm really keen to hear of alternative
> > stream ciphers we can use for free.
>
> From what I understand you CAN use RC4 in your program so long as you do not
> use the name RC4. It seems they have the name RC4 trademarked and the
> algorithm uncopywrighted. At least that is my take on it.
Correct, except you mean "unpatented" instead of "uncopywrighted"(sic).
Don't worry about using RC4 if you don't use the name.
Call it ARCFOUR instead.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
Date: Tue, 20 Jul 1999 11:25:52 +0200 (CEST)
From: Anonymous <[EMAIL PROTECTED]>
Subject: Meta-Certificate Group moved site?
Does anyone have a URL for the MCG?
They used to be at http://www.mcg.org.br/, but I've been getting an
error for that site (the server does not have a DNS entry) for a few
days. A web search for the MCG only gives references to this site. I
can't mail Ed Gerck either:
> 451 <[EMAIL PROTECTED]>... mcg.org.br: Name server timeout
> Message could not be delivered for 5 days
Have they moved somewhere?
Cheers,
-nick
(PS. Forgive the anonymity, but my local newsfeed is on the blink)
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: A Good Key Schedule
Date: Tue, 20 Jul 1999 10:40:57 +0200
John Savard wrote:
>
>
> Well, from knowing any one of the DES subkeys, you can recover 48 of
> the bits in the 56 bit key. If a hash function were used, then a
> transformation that was not invertible would be used.
I see your point. However, since you use one hash function, I suppose
you have to employ a keyed one in order to obtain from one passphrase
a number of different keys for use in the various steps of your
algorithm. Would you please tell how do you obtain the keys for the
hash function?
M. K. Shen
------------------------------
From: "collomb" <[EMAIL PROTECTED]>
Subject: Kryptos is a puzzle, an image
Date: 20 Jul 1999 10:58:01 GMT
The result of Kryptos is a puzzle.
Everyone knows that any puzzle generally reveals an image.
At the beginning of any puzzle, one places initially the first elements
along the border
In the case of Kryptos one finally arrives at an image that it is then
necessary to interpret to know the hidden message.
I deciphered Kryptos and I reveal on my web-site the final image with his
interpretation.
http://calvaweb.calvacom.fr/collomb/
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Klaus Pommerening)
Subject: Re: [Q] Finding K from P and C
Date: 20 Jul 1999 11:28:12 GMT
In <7n15ml$1k7$[EMAIL PROTECTED]> "Sungmin Chun" wrote:
> E(P, K) = C where P : Plain text C : Cipher text K : Key
> E(P, K) : Encryption method
> Can we find K easily for well-known E(P,K)
> when P and C are given?
>
Take a Book on Crypto and search for
`known plaintext attack'.
--
Klaus Pommerening [http://www.Uni-Mainz.DE/~pommeren/]
Institut fuer Medizinische Statistik und Dokumentation
der Johannes-Gutenberg-Universitaet, D-55101 Mainz, Germany
PGP fingerprint: F5 03 CE E7 70 C2 8C 74 BA ED EC 60 83 3B 7C 89
------------------------------
From: Eric Young <[EMAIL PROTECTED]>
Subject: Re: Does base64 encoding lessen security?
Date: Tue, 20 Jul 1999 21:39:57 +1000
John Savard wrote:
> Michael Slass <[EMAIL PROTECTED]> wrote, in part:
> >My question is about
> >whether the base64 encoding renders a brute-force attack easier
> The session key should be encrypted by RSA while still in pure binary
> form. Base-64 encoding should only be applied to the binary encrypted
> data as the very last step, so that if the data were sent as pure
> binary instead, the attacker could base-64 encode it himself.
>
> If indeed a system applied base-64 encoding, and then encrypted the
> resulting ASCII characters as binary data, that would be a serious
> error.
In OpenSSL/SSLeay/SSL-C the base64 encoding is just an alternative
form of encoding for the binary files with the added advantage of
typing information on the front (can have multiple object of
different types in the same file, edited via emacs/vi, cut past
between windows etc).
For the encryption, the binary is encrypted and then encoded
as base 64 with the iv and algorithm encoded in text in a form
similar to that used in PEM (hence the name).
The decision to go this way was made 3-4 years ago when the only
well defined binary encoding for encrypted data was PKCS-7 which
contained way to much ASN.1 for me to want to look at for such a
simple task.
eric
------------------------------
** 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
******************************
