Cryptography-Digest Digest #556, Volume #12 Mon, 28 Aug 00 13:13:00 EDT
Contents:
Re: Stream Cipher ([EMAIL PROTECTED])
Re: PGP Bug: IMPORTANT Personal test report (Steven Markowitz)
Re: Additional fix to ADK bug (John Savard)
Re: PRNG Test Theory ("Tony T. Warnock")
Re: SHA-1 program (cool!) (Daniel Leonard)
Re: Steganography vs. Security through Obscurity ([EMAIL PROTECTED])
Re: My (New) New algorithm ("Slava K.")
Re: UNIX Passwords (JCA)
Re: Fly ball in left field... (JCA)
Re: My (New) New algorithm ("Scott Fluhrer")
Blowfish question (and others) (Chris J/#6)
Re: Blowfish question (and others) (Kent Briggs)
Re: Blowfish question (and others) ([EMAIL PROTECTED])
Re: Blowfish question (and others) (David A Molnar)
ZixIt Mail ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Stream Cipher
Date: Mon, 28 Aug 2000 14:04:19 GMT
In article <8odpvs$4g5$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hi all!
>
> Stream Cipher using OTP and Random Number Generator approach.
> Delphi source code and executable can be download at
> www.alex-encryption.de
First off very unoriginal stuff, second off your site is a disgrace to
the profession. Your block ciphers are poorly documented and your
RSA/DES Null attacks are just plain wrong.
Arrg... read a book/posting or two would ya?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Steven Markowitz)
Crossposted-To: comp.security.pgp.discuss
Subject: Re: PGP Bug: IMPORTANT Personal test report
Date: 28 Aug 2000 14:00:48 GMT
In article <8o5kqk$mls$[EMAIL PROTECTED]> "Michel Bouissou" <[EMAIL PROTECTED]>
writes:
[ snip ]
>==> IMPORTANT NOTE:
>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 the public key contains only the key id of the ADK, then isn't that a
serious security flaw? My understanding is that it is possible for an
attacker to create a new key having the same key id as an existing key,
although the fingerprints will differ. I have read that this can be done
for RSA keys; I'm not sure about DH/DSS keys. This would allow an
attacker to cause messages to be encrypted to himself, instead of to the
intended ADK, as long as the sender had the attacker's ADK on his
keyring.
This attack would apply even if the recipient's key had not been tampered
with. It seems to me that in order for the ADK mechanism to be secure,
the signed portion of a key would have to include the key id, length, and
key fingerprint of the ADK.
Am I misuderstanding something, or is the current ADK setup inherently
insecure?
---- Steven Markowitz
--
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be the
views of D. E. Shaw & Co., L.P. or any of its affiliates.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Additional fix to ADK bug
Date: Mon, 28 Aug 2000 14:09:38 GMT
On Mon, 28 Aug 2000 13:58:03 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:
>Essentially, a sender ADK is one imposed by the sender's employer or
>government, and a recipient ADK is one imposed by the recipient's
>employer or government. Distinguishing them, by ensuring that all ADKs
>obtained from a version of the recipient's key block are labelled as
>recipient ADKs,
Of course, it would be trivial for a man-in-the-middle to alter
messages to change this labelling. That could be avoided without
sending signatures to the individual keys; one could have the sender
sign the list of ADKs.
But even without such a precaution, this would still have a benefit,
since although attacks using the ADK bug are a kind of
man-in-the-middle attack, they are easier than a real MITM attack,
because they only require uploading a bad certificate once, and can be
used by attackers who don't have the capability of mounting a true
MITM attack.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: PRNG Test Theory
Date: Mon, 28 Aug 2000 20:35:51 -0600
Reply-To: [EMAIL PROTECTED]
Kolmogorov (of course) has an article about this. I don't know the
reference, but it's in Knuth's volume II. Kolmogorov discusses the
number of bit strings of a given length that pass a certain number of
tests. It's in the Indian Statistics Journal, (Sankhya or something
similar.) The idea is that as one adds tests, the number of strings
passing the tests shrinks.
------------------------------
From: Daniel Leonard <[EMAIL PROTECTED]>
Subject: Re: SHA-1 program (cool!)
Date: Mon, 28 Aug 2000 14:56:31 GMT
On 25 Aug 2000, Mark Wooding wrote:
> 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.
>=20
> 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.
Well, my program and Sun implementation of SHA1 in Java agree with your
first value. Altough I never used OpenSSL, it seems bugged.
The program used to get these value is the same as the one in another
thread about SHA1 by S.T.L. with one minor difference, it does 8000 loops
instead on 1000. And it takes a hell lot of time
My implementation
- 0x6295dd8c1d5b704c85a361033eb5e7d9d6f1dc71 done in 2043666 milliseconds
Sun's
- 0x6295dd8c1d5b704c85a361033eb5e7d9d6f1dc71 done in 1895739 milliseconds
That's a little more than half an hour each.
==========
Daniel L=E9onard
OGMP Informatics Division E-Mail: [EMAIL PROTECTED]
D=E9partement de Biochimie Tel : (514) 343-6111 ext 5149
Universit=E9 de Montr=E9al Fax : (514) 343-2210
Montr=E9al, Quebec Office: Pavillon Principal G-312
Canada H3C 3J7 WWW :
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Steganography vs. Security through Obscurity
Date: Mon, 28 Aug 2000 14:57:52 GMT
In article <[EMAIL PROTECTED]>,
Runu Knips <[EMAIL PROTECTED]> wrote:
> Okay, but then it is a mixture of crypto and steno, because
> there is already a key in it.
Crypto isn't a requirement for stego. As a simple case, if I send two
different messages, and one appears in a newspaper unchanged, then it's
obvious who published the message.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Slava K." <[EMAIL PROTECTED]>
Subject: Re: My (New) New algorithm
Date: Mon, 28 Aug 2000 18:12:59 +0200
r1 is the random number selected for the first counter. p1 is the first copy
of the password. By "Advance p1 by r1character" I mean that r1 is added to
the current location in p1.
For example:
If r1 = 3, p1 = "Sample" and the current character in p1 = 3 ("m"),
then p1[k1 = k1 + r1]
when k1 is the current character in p1 (3).
Scott Fluhrer <[EMAIL PROTECTED]> wrote in message
news:8oc8f8$5l2$[EMAIL PROTECTED]...
>
> Slava K. <[EMAIL PROTECTED]> wrote in message
> news:8oaf1l$kkd$[EMAIL PROTECTED]...
> > I have thought of another encryption algorithm. Please tell me what you
> > think
> > (Again, the algorithm is described in generalized programming terms):
> >
> > 1. A password of length n is entered (Passwords of 2 bytes of smaller
make
> > the
> > algorithm inadequate, so using them should not be allowed).
> > 2. Two random values are generated: r1 and r2.
> > 3. Two copies of the password are saved in memory: p1 and p2.
> > 4. p1 is advanced by r1 characters for each byte/bit it encrypts.
> > p2 is advanced by r2 characters for each byte/bit it encrypts.
> > 5. A byte/bit is read from the input file. It is then encrypted like so:
> > c = p (XOR p1[r1] XOR p2[r2])
>
> Question: what do you mean "p1 is advanced by r1 characters"? What
> algorithm do you mean to advance a random value?
>
> >
> > The obviouse problem with this algorithm is that the entire password is
> not
> > used. This means that another password could generate the same results.
> > However, if the password is long enough, the possibility of the program
> > selecting the same random numbers when a password with the exact same
> bytes
> > in the exact same locations is entered is negligible.
> >
> > - NOTE - In order to enable the decryption of the file, r1 and r2 should
> be
> > saved along with the file.
> >
> > <EMail me your comments to [EMAIL PROTECTED]>
> >
> >
>
>
------------------------------
From: JCA <[EMAIL PROTECTED]>
Subject: Re: UNIX Passwords
Date: Mon, 28 Aug 2000 08:05:41 -0700
Martin 'SirDystic' Wolters wrote:
> Hi,
>
> Is there a description available,
> how UNIX encrypts (or hashes) its
> Passwords?
Why don't you have a look into the Linux
code?
------------------------------
From: JCA <[EMAIL PROTECTED]>
Subject: Re: Fly ball in left field...
Date: Mon, 28 Aug 2000 08:10:13 -0700
Greggy wrote:
> The following coded message:
>
> "Joe is a fly ball out in left field, and must return to first base
> ASAP. The third baseman is 6 feet 3 inches tall."
>
> has the following characteristics:
>
> Joe is the code name of a person being referred to.
> Fly ball means he is excited.
> "in left field" means he is a kook.
> first base is a normal state of mind.
> The third baseman is the person who issued the coded message and the
> height of the third baseman is the signature for the message itself.
>
> The point is that this message can be transfered in just about any form
> through any channel and can be authenticated as well.
Well, yes, but I don't think it is all that practical for general
usage. The
data you can transfer is highly stereotyped (unless you come up with a
huge codebook, which is not a practical solution) and interception of
successive
messages makes decryption relatively straightforward, as long as the code
remains unchanged.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: My (New) New algorithm
Date: Mon, 28 Aug 2000 08:14:26 -0700
Slava K. <[EMAIL PROTECTED]> wrote in message
news:8ocsuu$d1t$[EMAIL PROTECTED]...
> r1 is the random number selected for the first counter. p1 is the first
copy
> of the password. By "Advance p1 by r1character" I mean that r1 is added to
> the current location in p1.
> For example:
> If r1 = 3, p1 = "Sample" and the current character in p1 = 3 ("m"),
> then p1[k1 = k1 + r1]
> when k1 is the current character in p1 (3).
If that's the case, and you wrap around when you hit the end of the
password, then it can be broken using Gaussian Elimination with |p1|+|p2|
(that is, the combined length of p1 and p2) known plaintext bytes, even if
the attacker doesn't know p1 or p2. Unless p1 or p2 is extremely long, this
doesn't look like a workable approach...
>
> Scott Fluhrer <[EMAIL PROTECTED]> wrote in message
> news:8oc8f8$5l2$[EMAIL PROTECTED]...
> >
> > Slava K. <[EMAIL PROTECTED]> wrote in message
> > news:8oaf1l$kkd$[EMAIL PROTECTED]...
> > > I have thought of another encryption algorithm. Please tell me what
you
> > > think
> > > (Again, the algorithm is described in generalized programming terms):
> > >
> > > 1. A password of length n is entered (Passwords of 2 bytes of smaller
> make
> > > the
> > > algorithm inadequate, so using them should not be allowed).
> > > 2. Two random values are generated: r1 and r2.
> > > 3. Two copies of the password are saved in memory: p1 and p2.
> > > 4. p1 is advanced by r1 characters for each byte/bit it encrypts.
> > > p2 is advanced by r2 characters for each byte/bit it encrypts.
> > > 5. A byte/bit is read from the input file. It is then encrypted like
so:
> > > c = p (XOR p1[r1] XOR p2[r2])
> >
> > Question: what do you mean "p1 is advanced by r1 characters"? What
> > algorithm do you mean to advance a random value?
> >
> > >
> > > The obviouse problem with this algorithm is that the entire password
is
> > not
> > > used. This means that another password could generate the same results
.
> > > However, if the password is long enough, the possibility of the
program
> > > selecting the same random numbers when a password with the exact same
> > bytes
> > > in the exact same locations is entered is negligible.
> > >
> > > - NOTE - In order to enable the decryption of the file, r1 and r2
should
> > be
> > > saved along with the file.
> > >
> > > <EMail me your comments to [EMAIL PROTECTED]>
> > >
> > >
> >
> >
>
>
------------------------------
From: [EMAIL PROTECTED] (Chris J/#6)
Subject: Blowfish question (and others)
Reply-To: [EMAIL PROTECTED]
Date: 28 Aug 2000 16:48:51 +0100
Hiya,
I've been hiding here for a while, and am mostly an interested
onlooker :) However I've recently got into a small crypto discussion
with someone, who claims Blowfish was around in the eighties...I'm
having rather a tricky time accepting this as I can't find a reference
that confirms this, all info about it being dated from about 1993 onwards.
According to this other person its "misinformation" (I've pointed out the
details about Blowfish on Counterpanes site, and it's not been accepted).
His information is coming from details provided by GnuPG and the GnuPG
mailing list...I'm not on the list myself so I don't know how techincal
or accurate it is (or isn't).
Can anyone actually give me any other solid references about Blowfish, its
age and its security (how secure is blowfish these days?).
In a vaguely related note, PGP I'm sure wasn't out in the eighties (contrary
to this other persons notes)...and can someone also give a vague idea of the
security of triple-DES? Am I mistaken thinking it's still mostly secure?
I'm probably gonna drop the discussion about this before it gets out of
hand...I just feel that I'm needing to throw some hard facts that I can backup
to actually get somewhere. Or find out that what I think I know is in fact
wrong and back down gracefully :)
Any information or pointers to information would be useful thanks :)
Chris...
--
@}-,'-------------------------------------------------- Chris Johnson --'-{@
/ "(it is) crucial that we learn the difference / [EMAIL PROTECTED] \
/ between Sex and Gender. Therein lies the key / \
/ to our freedom" -- LB / www.nccnet.co.uk/~sixie \
------------------------------
From: Kent Briggs <[EMAIL PROTECTED]>
Subject: Re: Blowfish question (and others)
Date: Mon, 28 Aug 2000 16:07:35 GMT
Chris J/#6 wrote:
> Can anyone actually give me any other solid references about Blowfish, its
> age and its security (how secure is blowfish these days?).
Schneier published Blowfish in 1994. See the April '94 issue of Dr. Dobb's
Journal. Blowfish is a Feistel block cipher with a variable size key up to 448
bits. It's widely believed to be very secure.
--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Blowfish question (and others)
Date: Mon, 28 Aug 2000 16:19:27 GMT
In article <8oe1l3$ggr$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hiya,
>
> I've been hiding here for a while, and am mostly an interested
> onlooker :) However I've recently got into a small crypto discussion
> with someone, who claims Blowfish was around in the eighties...I'm
> having rather a tricky time accepting this as I can't find a reference
> that confirms this, all info about it being dated from about 1993
onwards.
> According to this other person its "misinformation" (I've pointed out
the
> details about Blowfish on Counterpanes site, and it's not been
accepted).
> His information is coming from details provided by GnuPG and the GnuPG
> mailing list...I'm not on the list myself so I don't know how
techincal
> or accurate it is (or isn't).
>
> Can anyone actually give me any other solid references about
Blowfish, its
> age and its security (how secure is blowfish these days?).
As quoted from Applied Crypto by Bruce S. the inventor of Blowfish, it
was invented in April of 1994 (References 1388 and 1389 of the book).
The best attack is a differential attack that works with weak keys, but
in general even that attack is too difficult to mount to break the
cipher.
Blowfish for all we know is still a secure, efficient, patent-free,
simple block cipher.
> In a vaguely related note, PGP I'm sure wasn't out in the eighties
(contrary
> to this other persons notes)...and can someone also give a vague idea
of the
> security of triple-DES? Am I mistaken thinking it's still mostly
secure?
Triple-DES has been around since the 80's if I am not mistaken. It's
still consider secure, but dog-awfully slow and cumbersome. Your best
bet is to avoid it if you have to program your own system, unless you
have to be FIPS compliant.
> I'm probably gonna drop the discussion about this before it gets out
of
> hand...I just feel that I'm needing to throw some hard facts that I
can backup
> to actually get somewhere. Or find out that what I think I know is in
fact
> wrong and back down gracefully :)
>
> Any information or pointers to information would be useful thanks :)
Look up FIPS-42 for more info on DES
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Blowfish question (and others)
Date: 28 Aug 2000 16:40:09 GMT
Chris J/#6 <[EMAIL PROTECTED]> wrote:
> that confirms this, all info about it being dated from about 1993 onwards.
As already pointed out, Blowfish was originally published in Dr. Dobb's
Journal in 1994. (I thought it was earlier, but no big deal).
> According to this other person its "misinformation" (I've pointed out the
> details about Blowfish on Counterpanes site, and it's not been accepted).
Oh dear. What is this person's standard of credibility?
> Can anyone actually give me any other solid references about Blowfish, its
> age and its security (how secure is blowfish these days?).
No major attacks are publically known against Blowfish.
Twofish exists because the AES ciphers need to have larger block sizes,
not because Blowfish is "inferior." Although Twofish probably benefits
from the experience gained by the designers since Blowfish came out.
> In a vaguely related note, PGP I'm sure wasn't out in the eighties (contrary
> to this other persons notes)...and can someone also give a vague idea of the
> security of triple-DES? Am I mistaken thinking it's still mostly secure?
The PGP User's Guide has (or had) a brief history of PGP, starting when
PRZ coded PGP 1.0 and then went around uploading it to a bunch of BBSes.
My memory says '92 - '93 for that, but check the Guide, which is
distributed with PGP.
DES has been around for almost 30 years. Still no one has been able to
come up with a practical attack substantially better than brute
force(not counting fun things like timing and power attacks). At least not
in public. 3DES removes the brute force problem. So if you are going to
pick one cipher, this is a serious candidate.
-David
------------------------------
From: [EMAIL PROTECTED]
Subject: ZixIt Mail
Date: Mon, 28 Aug 2000 16:52:57 GMT
Is it just me or ZixIt mails seems like a "been-there, done-that"
company?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
