Cryptography-Digest Digest #637, Volume #9 Wed, 2 Jun 99 07:13:02 EDT
Contents:
Re: 576-bit blowfish?! (Boris Kazak)
Simple crypto question ("SBS")
Re: RSA <> std.encryption (Bo Hedemark Pedersen)
Re: RSA <> std.encryption (Bo Hedemark Pedersen)
Re: ScramDisk and Windows 2000 (Brad Aisa)
Re: block ciphers vs stream ciphers (Bruce Schneier)
Re: definition of public domain ("Roger Schlafly")
? Rc5/Rc6 key-schedule ? ([EMAIL PROTECTED])
Re: block ciphers vs stream ciphers ("Douglas A. Gwyn")
Re: Obscure Code (Thomas Pornin)
Re: Obscure Code ("Douglas A. Gwyn")
Re: RSA <> std.encryption ("Douglas A. Gwyn")
Finding a 192 bit hash (Was: Using symmetric encryption for hashing) ("Thomas J.
Boschloo")
Re: Reasons for controlling encryption (Bill Unruh)
Re: Viability of encrypted flash cards? (Eric Smith)
Re: SHA-1 output random? (Francois Grieu)
----------------------------------------------------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Subject: Re: 576-bit blowfish?!
Date: Tue, 01 Jun 1999 20:46:54 -0400
Reply-To: [EMAIL PROTECTED]
Matthew Bennett wrote:
>
> Just to test, I tried using a key longer than 56 characters in my blowfish
> implementation written C (my key is stored as an unsigned char). After
> increasing the defined maximum key length in the blowfish header file, I
> found I could get a different cipher-text output from changing any one of up
> to ~72~ characters in my key. For example, using a 100-byte key, changing
> only any of the last 27 characters of this key had no effect on the cipher
> output.
>
> So it seemed a maximum of 72 characters were being "used" - unlike the 56 it
> is supposed to be? This effect was seen in two separate blowfish source
> codes.
>
> Could someone point out to me where I've gone wrong :)
>
> /\/\/\//
================
As far as I understand, the reason for this is purely historical.
Originally Blowfish was designed without the initial and final XOR-ing,
so in 16-round Blowfish there were 14 entries in the P-box, totaling 56
bytes. Naturally. this was the limit for key length, and it was this
number that went into the paper.
Later on, the size of the P-box was increased by 4 entries, so that
now the total size of the P-box is 72 bytes, but the paper was not
revised.
So the 56-byte limit may be regarded as an uncorrected typo, the extra
16
bytes are mixed with the same thoroughness as the rest of the crowd, and
are in no sense easier to attack.
So the total maximum length of Blowfish key is 72 bytes (576 bits).
Period, end of story.
Best wishes BNK
------------------------------
From: "SBS" <sbs@sbs>
Subject: Simple crypto question
Date: Wed, 2 Jun 1999 00:16:05 -0400
Hi all,
I am wondering how I can figure out the following problem. I need to set up
a licensing scheme for software we sell to avoid uncontrolled spread of the
software.
Setting a data structure holding the licensing information is not very
tough, hoewever how to I store that somewhere one the machine since I do not
want to use dongle like security.
If I encrypt the licence information, the software needs to decrypt it to
check it. Where do I store the key? It also needs to encrypt the data for
new licenses to be issued. I need to be able to setup a non trivial
authentication scheme to "tell" the software that the license is valid and
should be encrypted for later check.
Any help is welcomed
Stephane
note : I apologize for my level of english, let me know if anything needs
more details.
------------------------------
From: Bo Hedemark Pedersen <[EMAIL PROTECTED]>
Subject: Re: RSA <> std.encryption
Date: Wed, 02 Jun 1999 07:16:19 +0200
But isn't there any way that you can estimate the time to crack the
privat-key in RSA? Like when you say that a 40-bit conventional key can
be cracked in 10,000 secs. using a machine, that can test 10^8 keys per
sec.
Thanks for the quick respond,
Bo
"Michael J. Fromberger" wrote:
>
> In sci.crypt you write:
>
> >Is there any way to compare the security of RSA and standard
> >encryption?
>
> Hello there,
>
> The answer depends on what you mean by "standard" encryption. Are you
> referring to the symmetric encryption typically called "conventional"
> encryption by software packages that support it?
>
> If so, then the short answer is 'no' -- RSA is a public-key algorithm
> based on principles of number theory. Its security is thought to
> depend on the difficulty of integer factorization (although there has
> been, as yet, no proof of this). Most "conventional" encryption
> software employs symmetric block ciphers such as 3DES, Blowfish, or
> IDEA, whose security is based on the principles of "confusion and
> diffusion" described by Claude Shannon, the father of modern
> information theory.
>
> In other words, it's a case of trying to compare apples and oranges.
> Both asymmetric algorithms such as RSA, and symmetric ones such as
> Blowfish and IDEA, can be used for encryption -- but they go about it
> in such different ways, that the question of "security" cannot be
> meaningfully compared except in very limited ways.
>
> It's more meaningful to compare the security of RSA to the security of
> other public-key algorithms such as ElGamal, and to compare the
> security of symmetric ciphers to each other. Each is useful in its
> own domain.
>
> Cheers,
> -M
>
> --
> Michael J. Fromberger Software Engineer, Thayer School of Engineering
> sting <at> linguist.dartmouth.edu http://www.dartmouth.edu/~sting/
> Mp/8iFe3es7ycyzY8saI8mJI+TMcPxaY+4JFcOf+ximcYBCdQ87W0Sla7NDY9JGVWRe5dz8/
>
> "It is a miracle that curiosity survives formal education."
> -- Albert Einstein
--
Bo Hedemark Pedersen, email: [EMAIL PROTECTED]
IT konsulent, tlf: 8937 6626
UNI-C Århus, tlf: 8937 6666
Olof Palmes Allé 38, fax: 8937 6677
8200 Århus N, www: http://www.uni-c.dk
------------------------------
From: Bo Hedemark Pedersen <[EMAIL PROTECTED]>
Subject: Re: RSA <> std.encryption
Date: Wed, 02 Jun 1999 07:29:30 +0200
Jerry Coffin wrote:
>
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> > Is there any way to compare the security of RSA and standard encryption?
>
> Without knowing the key-length used with RSA, and the specific
> "standard encryption" you're referring to (DES?), no, it's not
> possible. It's certainly possible to give an idea of about the key
> length needed to make RSA about as difficult to break as DES is, but
> I'm not sure whether that's what you're asking or not.
Yes, that's what I'm asking :o)
Can you estimate it mathematically (take me through the calculations)?
> Given that DES
> can be broken fairly quickly and easily at the present time, I'm also
> a bit uncertain as to what, if anything, this would accomplish.
Thanks,
Bo
------------------------------
From: Brad Aisa <[EMAIL PROTECTED]>
Subject: Re: ScramDisk and Windows 2000
Date: Wed, 02 Jun 1999 02:33:45 -0400
Note to readers of this thread:
PGPDisk is a commercial alternative to ScramDisk, and works under NT or
9x. It has basically the same feature set. I've been using it for
months, and it has performed flawlessly.
--
Brad Aisa
[EMAIL PROTECTED] -- PGP public keys available at:
http://keys.pgp.com:11371/pks/lookup2?op=index&search=Brad+Aisa
"Laissez faire."
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: block ciphers vs stream ciphers
Date: Mon, 31 May 1999 23:39:09 GMT
On Wed, 26 May 1999 15:56:41 +0000, Helger Lipmaa <[EMAIL PROTECTED]>
wrote:
>Bruce Schneier wrote:
>
>> When NIST solicited comments on AES, I suggested that they ask for a
>> stream cipher instead of a block cipher, but I was a small minority.
>> So we have even more block cipher work.
>>
>> I would actually like to see more stream cipher work; constructions
>> like RC4 are not well enough understood.
>
>Suprisingly I agree with you. Never bothered to give any public comments
>for NIST at this subject, but the industry I have contacts with needs a
>good stream cipher, instead of YABCS ('yet another block cipher
>standard').
I made this comment to NIST. They ignored it.
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.perl.misc
Subject: Re: definition of public domain
Date: Wed, 2 Jun 1999 00:42:09 -0700
>A public-domain program is one upon which the author
>has deliberately surrendered his copyright rights.
A better definition of public domain software is software that
can be copied and used without any legal restrictions.
Public domain software is not copyrighted, but must also
be free from patent, trademark, and trade secret restrictions.
Occasionally works enter the public domain without a deliberate
action on the part of the author. (Eg, a copyright expires.)
------------------------------
From: [EMAIL PROTECTED]
Subject: ? Rc5/Rc6 key-schedule ?
Date: Thu, 27 May 1999 11:48:50 GMT
Hello!
As part of a research I am doing right now, I have to examine the RC5
algorithm. So I have a question about the key-schedule.
In 'The Rc5 Encryption Algorithm' Prof. Rivest writes: 'the key-
expansion function has certain amount of one-wayness: it is not so easy
to determine K from S'.
So, I wanted to ask whether it is already demonstrated how the secret
key is achieved from the expanded key table. For now I haven't found
anything, but my sources are somehow limited. I am asking, because I
worked on such process, and for now everything looks fine.
I will be really thankful for any comment.
Best wishes!
PS: On the nist.gov site I read the comments about the AES submissions,
so there was something about an alternative key schedule for RC6. Can
you give me some more information.
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: block ciphers vs stream ciphers
Date: Wed, 02 Jun 1999 08:12:22 GMT
DJohn37050 wrote:
> There are 2 well-studied modes of operation of a block cipher (OFB
> and CFB) that create a stream cipher. Going in the other direction
> is more problematic.
No, it is easy to use a stream cipher in block mode, and unlike the
converse case, no security is lost in doing so.
> Also, a block cipher does not allow bit manipulations, while a
> stream cipher does.
You seem to mean, undetected alterations of the ciphertext. If so,
you're mistaken. Blocks can be spoofed, and some stream ciphers
(designed for reliable channels) will cascade errors.
> Also, a stream cipher has the sync problem, CBC mode is self-
> synchronizing.
Since the beginning of message is normally quite clear to the
(intended) recipient, there is no synchronization problem.
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: Obscure Code
Date: 2 Jun 1999 08:14:43 GMT
According to Oliver J. Hanau <[EMAIL PROTECTED]>:
> Does anyone now if there is any kind of source on producing obscure
> code, i.e. code that is hard for an attacker to analyze/debug?
During the 80's, some assembly programmers were really good at this.
This was mainly used for protection of games against piracy during the
golden age of Apple II, C64, Atari ST and Amiga. However, such knowledge
was rarely made public (by definition...) and was more black magic and
art than science.
--Thomas Pornin
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Obscure Code
Date: Wed, 02 Jun 1999 08:35:49 GMT
Thomas Pornin wrote:
> During the 80's, some assembly programmers were really good at this.
> This was mainly used for protection of games against piracy during the
> golden age of Apple II, C64, Atari ST and Amiga. However, such knowledge
> was rarely made public (by definition...) and was more black magic and
> art than science.
And as usual with "security through obscurity", the bad guys met the
challenge and cracked the protection schemes anyway. I have a whole
shelf full of publiched cracks for Apple II-era software. (But I
always paid for software, myself. Since I earn a living developing
software, I appreciate the need to reward the producers.)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: RSA <> std.encryption
Date: Wed, 02 Jun 1999 08:22:25 GMT
> Is there any way to compare the security of RSA and standard
> encryption?
No, because the optimal algorithm for cryptanalysis is not (publicly)
known in either case (RSA nor DES). If you are willing to assume that
DES cannot be broken with substantially less effort than a brute-force
search over the key space, and are willing to assume that RSA must be
cracked via factorization, and that current methods for factoring
products of large primes are nearly as good as can be found, then a
comparison could be made (for a given RSA key length). However, those
aren't very safe assumptions, and I don't want to mislead you by
giving an estimate that depends on such assumptions.
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Subject: Finding a 192 bit hash (Was: Using symmetric encryption for hashing)
Date: Wed, 02 Jun 1999 10:57:02 +0200
Paul Onions wrote:
>
> It's not one-way: given a hash output, simply "invent" the other ciphertext
> bits and decrypt. This gives a preimage of the output.
>
> It's not collision-resistant: as above, but "invent" two lots of ciphertext
> bits and decrypt each. This gives two preimages with the same output.
>
> So using any kind of invertible message transformation in this way is no
> good for constructing a cryptographic hash.
I finally get it (I think). If I would sign a RSA modulus this way, some
attacker could just take this signature and create an other key using
the 'hash', 'inventing' some bytes and decrypting the result :-(
Thanks for answering my question! But now I have a new problem; If I
want to use something like Rijndael-192 for symmetric encryption, how do
I hash my conventional passphrase. Surely there are some solutions for
this?!
Thomas
--
"The early worm gets eaten by birds"
PGP key: http://x11.dejanews.com/getdoc.xp?AN=453727376
Email: boschloo_at_multiweb_dot_nl
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Reasons for controlling encryption
Date: 2 Jun 1999 08:39:27 GMT
In <[EMAIL PROTECTED]> Paul Koning <[EMAIL PROTECTED]> writes:
>Bill Unruh wrote:
>> are OK. They already do that. Read ITAR or the EAR in the USA. Lots is
>> exempted from the regulations (including bank transfers, etc)
>I don't think so. It's common to say things like "40 bit crypto is
>exempt" or "bank applications are exempt" but that's not what the
>regulations actually say. Instead, nothing is exempt, but different
>uses and different strengths are covered by different sets of rules.
>Depending on which set applies to you, the amount of hassle imposed
>varies greatly. But if you assume that certain application X isn't
>covered, you may be in for an unpleasant surprise.
It is certainly true that 40 bit IS covered and requires a license, and
that much commercial and banking stuff requires a licese but tht those
license are granted after a one time review. You may not need a new
license for each export. However, as I said, the legislators ( or in
this case the executive) can write exemptions.
Here is a list of such exemptions from EAR (not inclusive, just one
sections list) :
iFrom EAR Section 5 part 2 5A0002
Related Controls: See also 5A992. This entry does not
control: a.) "Personalized smart cards" or specially designed
components therefor, with any of the following
characteristics: 1.) Not capable of message traffic
encryption or encryption of user-supplied data or related key
management functions therefor; or 2.) When restricted for use
in equipment or systems excluded from control under the note
to 5A002.c, or under paragraphs b through h of this note. b.)
Equipment containing "fixed" data compression or coding
techniques; c.) Receiving equipment for radio broadcast, pay
television or similar restricted audience television of the
consumer type, without digital encryption and where digital
decryption is limited to the video, audio or management
functions; d.) Portable or mobile radiotelephones for civil
use (e.g., for use with commercial civil cellular
radiocommunications systems) that are not capable of
end-to-end encryption; e.) Decryption functions specially
designed to allow the execution of copy-protected "software",
provided the decryption functions are not user-accessible; f.)
Access control equipment, such as automatic teller machines,
self-service statement printers or point of sale terminals,
that protects password or personal identification numbers
(PIN) or similar data to prevent unauthorized access to
facilities but does not allow for encryption of files or text,
except as directly related to the password or PIN protection;
g.) Data authentication equipment that calculates a Message
Authentication Code (MAC) or similar result to ensure no
alteration of text has taken place, or to authenticate users,
but does not allow for encryption of data, text or other media
other than that needed for the authentication; h.)
Cryptographic equipment specially designed , developed or
modified for use in machines for banking or money
transactions, and restricted to use only in such transactions.
Machines for banking or money transactions include automatic
teller machines, self-service statement printers, point of
sale terminals, or equipment for the encryption of
interbanking transactions.
------------------------------
From: Eric Smith <[EMAIL PROTECTED]>
Crossposted-To: alt.security,talk.politics.crypto
Subject: Re: Viability of encrypted flash cards?
Date: 02 Jun 1999 02:40:27 -0700
"Cor!" <[EMAIL PROTECTED]> writes:
> If such a system became widely available, then I guess it would be used
> by criminals more than anyone else (ie. peadophiles, Chinese workers at
> Los Alamos, etc.).
Why do you say that? Do you think PGP is used by criminals more than anyone
else? Do you think that non-criminals have no legitimate use for cryptography?
There's almost no statement I find more terrifying than "the innocent have
nothing to fear."
------------------------------
From: [EMAIL PROTECTED] (Francois Grieu)
Subject: Re: SHA-1 output random?
Date: Tue, 01 Jun 1999 08:52:14 +0200
[EMAIL PROTECTED] (David Wagner) wrote:
> Francois Grieu <[EMAIL PROTECTED]> wrote:
> > At least, the output of SHA-1 is asymptotically equidistributed when
> > message size grows, as a simple consequence that the round function,
> > for a given message appendice, is a bijection on the set of states.
> I don't think this is right.
Oops !! As you pointed out in your refutation, my hypothesis is (much
probably) wrong, AND my reasoning fussy (lacking additional hypothesis
at the very least).
I thank you for correcting me, and fimrly decide to
- never again analyse an algorithm from memory (I coded SHA-1 in 8051
assembly a few month ago)
- double-check my reasoning before polluting the newsgroup
Now I find myself unable to prove anything about the asymptotic
distribution of SHA-1 output, not even that every output value can
be reached !
Francois Grieu
------------------------------
** 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
******************************
