Cryptography-Digest Digest #812, Volume #12 Mon, 2 Oct 00 09:13:00 EDT
Contents:
Re: Ciphers and Unicode (Mok-Kong Shen)
Re: How Colossus helped crack Hitler's codes (Mok-Kong Shen)
Re: Why is TwoFish better than Blowfish? (Arturo)
Re: Choice of public exponent in RSA signatures (Thomas Pornin)
Re: Choice of public exponent in RSA signatures (Francois Grieu)
Re: NIST Statistical Test Suite ([EMAIL PROTECTED])
Re: Is RC4 a serious cipher? (Runu Knips)
Re: Choice of public exponent in RSA signatures (Francois Grieu)
Re: Signature size (Tom St Denis)
Re: Shareware Protection Schemes (Runu Knips)
Re: Is RC4 a serious cipher? (Tom St Denis)
SPAM WARNING ! (Runu Knips)
Re: Signature size ([EMAIL PROTECTED])
CRT and RSA 2 (Soeren Gammelmark)
Re: Choice of public exponent in RSA signatures (Francois Grieu)
Re: Ciphers and Unicode (Anders Thulin)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Ciphers and Unicode
Date: Mon, 02 Oct 2000 11:21:49 +0200
Ray Dillinger wrote:
>
> Has anyone looked at Unicode seriously, and how it will interact
> with cipher software?
>
> One basic issue I see is that if we start writing english with a
> 16-bit character set, we're going to get one point-three bits of
> information (per character) out of sixteen bits, rather than 8.
> This affects the feasibility of guessing plaintext in, say, an
> 8-byte block cipher, and drives the entropy of the plaintext
> way way down.
I may be very wrong due to poor knowledge. But isn't it
that Unicode uses 8 bits for most languages that use
alphabets? If one extends each byte to two bytes with zeros
on the left byte, there is no entropy change but only
increase of transmission cost, I guess.
M. K. Shen
>
> Yes, I know it's always good to compress before encrypting, but the
> fact is most people don't.
>
> Another basic issue with Unicode is that it has scads of special
> characters -- some are designated whitespace, some print left-to-
> right and others right-to-left, some are designated stop or break
> characters, some don't print at all, some bit combinations are
> explicitly not part of the character set, etc, etc etc. This will
> introduce a lot of niggling little complications and possibly
> reduce security by introducing more opportunities for the coders
> to mess up. It will also make major problems because lots of
> software will cheerfully convert unicode text to some preferred
> format, changing one character for another invisibly to humans.
> wanna bet digital signatures on it won't check if that happens?
>
> Another basic problem with Unicode is that it's explicitly
> "endianness-agnostic", storing MSB first and LSB first on
> different machines. Nifty as far as use is concerned, but
> I can picture a very persistent problem where digital signatures
> created on one platform don't check on a different platform
> because the mail software (or whatever) has "corrected" the
> endianness of the representation to match local standards.
> Or where ciphertext is reduced to unicode printable characters,
> transmitted, and the underlying representation is changed on
> the recipient's machine and it decrypts as gibberish.
>
> Also, you've got lots of different character sequences that
> represent the same damn glyphs. When you're looking at an
> e with a cedilla under it, for example, you've normally got
> no way of knowing whether the underlying representation is
> the precomposed character or the e followed by the non-spacing
> accent. Or a character you didn't even know about, in a
> completely different alphabet, that just happens to *look*
> like an e with a cedilla under it. So if you ever have to
> enter a key or a passphrase from a printout, or read off
> exact text by voice over the phone, or whatever, you have
> no way of knowing if it's going to be exactly the same text.
> Whether cryptographic operations that require them to be
> the same binary representation will work becomes a crapshoot.
>
> Ray
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: How Colossus helped crack Hitler's codes
Date: Mon, 02 Oct 2000 11:30:35 +0200
John Savard wrote:
>
> The article was in "American Heritage of Technology and Invention",
> and the book is "Battle of Wits" by Stephen Budiansky, ISBN
> 0684859327, published by Free Press.
I vaguely remember that the director of the museum at
Bletchley Park was writing a book several years ago. Does
anyone know about that, or is it the one given above?
M. K. Shen
------------------------------
From: Arturo <[EMAIL PROTECTED]=NOSPAM>
Subject: Re: Why is TwoFish better than Blowfish?
Date: Mon, 02 Oct 2000 11:14:37 +0200
On 28 Sep 2000 14:03:52 GMT, [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
wrote:
>[EMAIL PROTECTED]=NOSPAM (Arturo) wrote in
>> I doubt it. The author is Bruce Schneier, boss-in-chief of
>> Counterpane
>>security and writer of the "bible" in crypto, Applied Cryptography. Not
>>the kind of guy I think most likely to have been bought by the NSA
>>
> Then please tell me the kind of guy you think the NSA would own.
>Terry who seems not to have press conections or do you think I am
>the type Arturo.
Someone who spreads FUD, adds "and-the-best-encryption-is-..." with
every message, trolls, insults (some or all of the above). OTOH, I fond Bruce�s
AC to be a good hybrid between general-public and high-level information.
>>> At least these
>>>are my feelings about these fishy ciphers. It seems like NSA humour
>>>to give both ciphers FISHY names.
>>
>> Rather blame the author.
>
> I see blame the author because this is nit the kind of twist
>the NSA would do?
Nope. Blame the author because he did put the names. I just said
"blame" in an humorous sense. Of course, he might be working for the NSA, and
adopted the name after their suggestions. I could be working myself for the NSA
(just in case I am: please get me a salary raise).
> There are a lot of conflicting requiremesnts. For one make it
>secure but make it fast. For my purposes secure is a much more
>valuable requirement. The problem is you really can't measure security
>becasue what is secure today is insecure tomorrow.
Grantes. But you can�t wait till tomorrow if you need it today. DES
has awaited replacement for too long. And since nobody can guess the future,
all we can do is test algorithms with the best techniques available today. Both
TripleDES and IDEA are quite robust, so I could choose IDEA which is faster.
Yeah, you can prove that CAST is 10^10 times stronger that IDEA. But if
that means that it would take 10^50 years to break it instead of 10^40, that�s
overkill.
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: Choice of public exponent in RSA signatures
Date: 2 Oct 2000 10:24:03 GMT
According to Francois Grieu <[EMAIL PROTECTED]>:
> I'm trying to understand why so many professionals swear by it !
RSA-based PGP used 65537. This is enough to create fashion.
Besides, choosing a prime number speeds up the key selection algorithm
(e must be prime to (p-1)(q-1), so, with e = 3, when you choose p, you
have only ~67% chance that p-1 is prime to e). However, 257 would have
been almost as good as 65537.
--Thomas Pornin
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Choice of public exponent in RSA signatures
Date: Mon, 02 Oct 2000 12:40:02 +0200
[EMAIL PROTECTED] (D. J. Bernstein) wrote:
> Francois Grieu <[EMAIL PROTECTED]> wrote:
> > That's my view too in theory, but in practice I hesitate to recommend
> > Rabbin signatures, because if things go wrong with the padding, they
> > tend to go wrong so badly that the factorization of the public key is
> > revealed.
>
> This is certainly not unique to Rabin-Williams signatures. You'll reveal
> your secret key if you screw up your exponentiation in RSA, for example,
> or your random number generation in ElGamal/Schnorr/DSA.
>
> The obvious solution is to stop screwing up. This isn't rocket science.
What is special with Rabin-Williams signature is that attacks on the
padding scheme can be turned into a total break, which does not appear
true with RSA.
Give me a Rabin-Williams public key of 1024 bits for the ISO 9796-1 scheme,
accept to reveal the signature of 2 (maybe 4) messages I'll then choose,
and I'll factor the modulus.
Francois Grieu
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: sci.crypt.random-numbers
Subject: Re: NIST Statistical Test Suite
Date: Mon, 02 Oct 2000 10:53:21 GMT
Hi all,
Has anyone got code for the function erfc() that i could include in the
software as this function does not seem to be available when using
Visual C++ 6.0.
Thank you,
Brice.
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> While all the current attention of our groups in direction
> of NIST is apparently on AES, I believe that it is barely
> known that NIST has just contributed something also of
> essential interest to us. In
>
> http://csrc.nist.gov/rng/
>
> there is now available for download an apparently
> fairly good statistical test suite. A technical problem
> may be however that the stuff is in UNIX tar files.
>
> I hope that this news is of value to those interested
> in random numbers. If someone gains practical experience
> with the test suite, it would be nice if he will give
> a report on that to us.
>
> M. K. Shen
> -------------------------
> http://home.t-online.de/home/mok-kong.shen
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Mon, 02 Oct 2000 13:13:23 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Is RC4 a serious cipher?
"David C. Barber" wrote:
> I was looking the RC4 Cypherpunks code and doesn't seem to be much more than
> a simple key generator and an xor with a cycle of 256. Is this at all a
> serious (read: secure) cipher?
RC5, RC6 and Blowfish are other examples for simple, but secure ciphers.
Just because something is simple it isn't necessarily bad.
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Choice of public exponent in RSA signatures
Date: Mon, 02 Oct 2000 13:23:23 +0200
[EMAIL PROTECTED] (Thomas Pornin) wrote:
> RSA-based PGP used 65537. This is enough to create fashion.
A good theory, if not a rational justification.
By the way I believe the RSA-based PGP does not always use e = 65537,
even with the default key generation parameters: it appears the key
generation algorithm in the classic PGP 2.63 first selects the
primes p q, then proceed to find an odd e that is relatively prime
to p-1 and q-1 and at least the specified number of bits, which
is 17 bits by default. If I am right, this gives e = 65537
about 99.997% of the time, e = 65539 (which happens to be a prime
also) with probability about 2^-15, and 65541 (which is not prime)
with probability about 2^-30 (so it probably never happened).
Since PGP encrypts to multiple recipients, it has a good reason
to choose a not-too-small e, especialy if the block containing the
symetric key for the encrypted file is used for multiple recipients
without undergoing major nonlinear changes; has this been checked ?
Francois Grieu
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Signature size
Date: Mon, 02 Oct 2000 11:18:51 GMT
In article <8r9i42$6g9$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
>
> > What is your platform? What are the exact requirements?
> >
> > My suggestion is to consider ECC since 163-bit prime fields in GF(2)
> > appear to be secure (I would use a slightly larger field). They
> > essentially use the ElGamal type math if I am not mistaken.
>
> Is ECC ElGamal patented by Gericom? Any pointers to source code
> (preferably in Java but C/C++ will do)?
That's "Certicom" and no it's not patented. Some aspects of ECC are
however, so you had best check it out.
> > Why would you need to sign a 32 bit value though?
>
> Platform: Java on desktop computers
>
> The signature will be used to secure software serial numbers. To be
> more precise it is only supposed to keep people from generating their
> own serial number generators. Since the user has to key it in it has
to
> be as short as possible (sacrificing some security for that would be
> fine: I think 56-bit DES like security would be enough).
>
> And yes I know that a program can never be secure and a cracker can
> always change the code verifying the serial number (especially in
> Java). But as long as there are no unauthorized serial numbers
floating
> around people who want to use it have to download the modified program
> which lots of people will not do since it is a) insecure (viruses,
etc)
> and b) more of a hassle and c) more obviously a criminal act.
>
> Thanks for your help!
So you want people to enter a serial no to work your program and you
want to stop people from making their own and stop people from copying
them?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Mon, 02 Oct 2000 13:41:59 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Shareware Protection Schemes
musashi_x wrote:
> I want to create a serial number registration scheme for a piece of
> shareware I'm working on. I would like to use blowfish, with the private
> key allowing access to the software's full features.
There is no private key in symmetric encryption algorithms such as
Blowfish.
> I'm thinking that I could label each copy with a unique serial number
> (which would tell me which key to send the person puchasing it). The
> serial number would be the first 7 characters of the private key that
> I send them.
If I understand you correctly, you want to (a) have some private testing
data unique in every executable you sell, and (b) want the user to
provide the serial number which allows to successfully test that data.
Well, this is trivial, what kind of help do you need for that ?!?
However, the user may simply patch your software such that the 'jump if
equal' instruction which jumps to the code if the test succeeded is
transformed into a 'jump if not equal' instruction. Because it is still
the shareware version (and not a registered one), you won't get any
information from that executable, but it will offer the user all
features.
There can't be a real protection. Keep that in mind ! If you don't
believe that, visit, for example, www.gamecopyworld.com.
And beware your protection scheme should not nerve the registered
users. Otherwise they might prefer to use the illegally patched
version, and continue to use illegally patched versions if they
need newer ones.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Is RC4 a serious cipher?
Date: Mon, 02 Oct 2000 11:37:51 GMT
In article <[EMAIL PROTECTED]>,
Runu Knips <[EMAIL PROTECTED]> wrote:
> "David C. Barber" wrote:
> > I was looking the RC4 Cypherpunks code and doesn't seem to be much
more than
> > a simple key generator and an xor with a cycle of 256. Is this at
all a
> > serious (read: secure) cipher?
>
> RC5, RC6 and Blowfish are other examples for simple, but secure
ciphers.
> Just because something is simple it isn't necessarily bad.
While the round structure of Blowfish is simple, the tables are not. I
would not consider Blowfish something you could memorize... now X-TEA
is a simple cipher :-)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Mon, 02 Oct 2000 13:52:06 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: SPAM WARNING !
[EMAIL PROTECTED] wrote:
> I just read this article [... it] has tons of stories on how all
> kinds of people are using this new technology to lose weight FAST,
> and apparently, very safely. [...]
Hey cool, 'safely' !
So it has something to do with security, doesn't it ?
And we all have weight problems...
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Signature size
Date: Mon, 02 Oct 2000 12:11:39 GMT
> That's "Certicom" and no it's not patented. Some aspects of ECC are
> however, so you had best check it out.
Oops I know. Freud got into my way ;-) Gericom is a European notebook
company.
> So you want people to enter a serial no to work your program and you
> want to stop people from making their own and stop people from copying
> them?
Yes and no. I do not want to stop people from copying the serial
numbers. We will keep track of all serial numbers assigned. Thus if one
gets published on the net we know where it originated (who the license
holder is). This will cause people to think twice about
publishing/sharing their serial numbers since they can be traced back
to them.
This is not supposed to be an all or nothing measure. It is just
supposed to stop people from publishing serial numbers on the web/news
or even publishing serial number generators on the web (and there are a
lot of those out there right now).
regards,
kryps
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Soeren Gammelmark <[EMAIL PROTECTED]>
Subject: CRT and RSA 2
Date: Mon, 02 Oct 2000 14:40:16 +0200
Hi -
I've written here and asked before about RSA and chines reminder
theorem, but after thinking about it, I have one more question:
Have can you deduce: m1 =3D c ^ (d mod (p - 1)) mod p
m2 =3D c ^ (d mod (q - 1)) mod q
?
These equations can ofcourse be solved with CRT, but how do you deduce
them from m =3D c ^ d mod n?
S=F8ren Gammelmark
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Choice of public exponent in RSA signatures
Date: Mon, 02 Oct 2000 14:51:30 +0200
[EMAIL PROTECTED] (Thomas Pornin) wrote:
> RSA-based PGP used 65537. This is enough to create fashion.
A good theory, if not a rational justification.
By the way I believe the RSA-based PGP does not always use e = 65537,
even with the default key generation parameters: it appears the key
generation algorithm in the classic PGP 2.63 first selects the
primes p q, then proceed to find an odd e that is relatively prime
to p-1 and q-1 and at least the specified number of bits, which
is 17 bits by default. If I am right, this gives e = 65537
about 99.997% of the time, e = 65539 (which happens to be a prime
also) with probability about 2^-15, and 65541 (which is not prime)
with probability about 2^-30 (so it probably never happened).
Since PGP encrypts to multiple recipients, it has a justification
for a not-too-small e, and/or nonlinear padding of secret data (like
the IDEA key) when it is RSA-enciphered using multiple keys.
[I just checked the source in PGP 2.63, and the left padding with
random for each distinct recipient looks safe to me, even for e=3]
Francois Grieu
------------------------------
From: Anders Thulin <[EMAIL PROTECTED]>
Subject: Re: Ciphers and Unicode
Date: Mon, 2 Oct 2000 12:51:03 GMT
Mok-Kong Shen wrote:
> I may be very wrong due to poor knowledge. But isn't it
> that Unicode uses 8 bits for most languages that use
> alphabets?
Unicode always uses 32 bits to idetify a character code. These are
then encoded in various ways.
Unicode/UTF-8 uses 8 bits per character only for those languages that
will do with 7-bit ASCII characters. Any other character will require 2-6
bytes to represent.
The UTF-8 encoding looks like this (stolen from the UTF-8 and Unicode FAQ),
where the U-xxxxxxxx is the canonical 32-bit code.
U-00000000 - U-0000007F: 0xxxxxxx
U-00000080 - U-000007FF: 110xxxxx 10xxxxxx
U-00000800 - U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx
U-00010000 - U-001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
U-00200000 - U-03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
U-04000000 - U-7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
(rightmost bit in 8-bit code is least significant bit in 32-bit representation.
Only shortest possible encoding is valid -- there should be no 10000000 bytes)
There are also UTF-32 and UTF-16 encodings (yes, also UTF-32 is an encoding.
Big-Endian and Little-Endians issues are still alive and well.)
It seems possible that some of these encodings are 'better' than the others
for a particular method of encryption.
Worst case scenario: Encoding a 8-bit ASCII text as some form of UTF-32 -- lots
of 00 bytes --, and then stream coding it seems likely to produce some detectible
artifacts. And we have a plaintext known to 75% ...
--
Anders Thulin [EMAIL PROTECTED] 040-10 50 63
Telia Prosoft AB, Box 85, S-201 20 Malm�, Sweden
------------------------------
** 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
******************************
