Cryptography-Digest Digest #133, Volume #12 Thu, 29 Jun 00 03:13:01 EDT
Contents:
Re: very large primes (Dan O.)
CryptoAPI: Exporting & Importing Public/Private key pairs. ("Jorge")
Re: Surrendering Keys, I think not. (zapzing)
Re: Dynamical Cryptography algorithm (Benjamin Goldberg)
Re: Variability of chaining modes of block ciphers (Shawn Willden)
Re: Algo's with no easy attacks? (Shawn Willden)
Diffie Hellman Primes : Speed Tradeoff Q ([EMAIL PROTECTED])
Re: Dynamical Cryptography algorithm ("Scott Fluhrer")
Re: Thoughts on "Cracking" of Genetic Code (Boris Kazak)
Re: Thoughts on "Cracking" of Genetic Code (John Savard)
Re: Diffie Hellman Primes : Speed Tradeoff Q (Roger Schlafly)
Re: Another chaining mode (Boris Kazak)
Re: Does anyone have code for generating primitive polynomials? (Mack)
Re: Compression & Encryption in FISHYLAND (Kurt Shoens)
Re: Remark on practical predictability of sequences (David A Molnar)
Re: Variability of chaining modes of block ciphers (Mok-Kong Shen)
Re: Another chaining mode (Mok-Kong Shen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Dan O.)
Subject: Re: very large primes
Date: Wed, 28 Jun 2000 18:22:40 -0600
In article <[EMAIL PROTECTED]>, Simon Johnson
<[EMAIL PROTECTED]> wrote:
> Right, i've got another such problem......
>
> Does F(x)= 6(X) + 1 always produce a prime, is there a
> proof/disproof of this?
You almost have it right! Try:
F(X) = 6; F(X) + 1 is prime.
--
Dan Oetting <[EMAIL PROTECTED]>
------------------------------
From: "Jorge" <[EMAIL PROTECTED]>
Subject: CryptoAPI: Exporting & Importing Public/Private key pairs.
Date: Wed, 28 Jun 2000 20:56:51 -0500
Hi there,
I'm using CryptoApi (MS Enhanced Provider) in a VC++ application and
everything like the encryption and decryption functions works pretty
good but I have a problem while importing and exporting
Private/Public key pairs.
According to the documentation, you can use the CryptExportKey
function using a Session key to encrypt the blob, and the
PRIVATEKEYBLOB modifier, to tell the function to crypt the private &
private key bundled in the blob.
Ok, my keys were created using CRYPT_EXPORTABLE. So, when I am
deleting the keys I receive two screens (one for the public key and
one for the private one) warning you about that. However, when I am using
CryptExportKey with the PRIVATEKEYBLOB modifier it only appears one
screen warning me about exporting the Private key, not the Public
key. Ok, perhaps this is by design.
According to the documentation, you use CryptImportKey to import the
keys to the CSP. In my case this is not working. The function seems
to work, but there is no imported keys inside the container after the
operation.
There no sample talking about this in the Microsoft documentation,
all the samples works with session keys and nobody in Internet is
talking about this, so I think not too much people is working with
CryptoAPI.
Do you know if it is possible to export/import the public/private
key pair using the Enhanced Provider? How is it???
Or perhaps you need some special authorization from Microsoft in
order to do this???
Thanks in advance,
Jorge.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Surrendering Keys, I think not.
Date: Thu, 29 Jun 2000 02:18:04 GMT
In article <[EMAIL PROTECTED]>,
Simon Johnson <[EMAIL PROTECTED]> wrote:
> Good point,
>
> However, for personal encryption, it is perfect.
But why would one wish to use an OTP for personal
encryption? I could see that you could then put
your secret stuff in two places instead of one,
but this is really pretty bad security compared
to encryption with a good cipher and a key that
has been memorized. So for "personal" encryption
I just don't see the point of OTP.
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Dynamical Cryptography algorithm
Date: Thu, 29 Jun 2000 03:01:20 GMT
Sylvain Martinez wrote:
[snip]
> Sorry I am not familiar with blowfish and thought it was the case.
> Is there any cryptography algorithm around allowing the user to change
> different value such as the size of the different blocks used in the
> crypt process ? (I am not speaking about the keylength, but the size
> of the block the algorithm will work with)
Sure. The lja1 cipher will work with any number of bytes.
[snip]
> I am not a math genius, creating a new algorithm using complex
> mathematical formalas would have been useless because I would then
> more or less copied an existing algorithm.
Complicated math formulae are used in public key encryption - most
symmetric ciphers use relatively simple operations.
[snip]
Having the algorithm vary depending on a user choice or platform is a
bad idea. Since there are 4 variants of the algorithm, then an attacker
could simply have 4 computers attempting to crack each one in parallel.
Consider a definition of what an encryption key is: "The only part of
an algorithm that needs to be replaced to restore a compromised cipher
engine to its full strength" Your key should just be a secret
bitstring, known only to the encipherer and the decipherer. The
algorithm should be *known,* not in any way secret [except for the key].
------------------------------
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: Variability of chaining modes of block ciphers
Date: Wed, 28 Jun 2000 21:05:27 -0600
Mok-Kong Shen wrote:
> You are right. Many thanks for the demonstration. This indeed clearly
> shows that my view up till now that there could be chaining modes
> among what I mentioned in the original article that offer more than
> a few bits is wrong. Your demonstration simultaneously provides me
> the insight that one should use non-linear values for chaining, if one
> desires to do better. An idea that suggests itself is to use the square
> of the sum as chaining value, for that evidently escapes your attack.
It appears to escape this attack. To make it really good, you should probably make it
some sort of keyed transform, with good avalanche and diffusion properties.
Better yet, use a good cipher and don't rely on chaining to add security against key
recovery attacks. Many chaining modes are very effective at what they are intended
for --
defeating block substitution/rearrangement attacks that are left open by ECB mode.
Even better still, maybe you should use a well-studied, standard technique that
effectively obscures the blocks and adds substantial security -- A stream cipher.
ARCFOUR
would be a good choice, since it's simple, free, small, efficient and secure. When
combining a weak block cipher with a good stream cipher, I would be tempted to discard
the
weak block cipher, though :)
Finally, you could get a good block cipher, *and* a good stream cipher and be quite
certain that no one will read your e-mail unless they break into your house and steal
your
keys or hold a gun to your head and ask you what you wrote.
Shawn.
------------------------------
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: Algo's with no easy attacks?
Date: Wed, 28 Jun 2000 21:06:53 -0600
tomstd wrote:
> [EMAIL PROTECTED] wrote:
> >How about the ciphers that combine several publicly known real
> random
> >sequences?
>
> How random could a publicly known sequence be?
Depends on your definition of random.
Shawn.
------------------------------
From: [EMAIL PROTECTED]
Subject: Diffie Hellman Primes : Speed Tradeoff Q
Date: Thu, 29 Jun 2000 03:09:40 GMT
I'm implementing Diffie-Hellman for a client-server product. I
understand that in an ideal world, a new shared p and g are chosen for
each session. Generating the key pair is easy, but coming up with a
large (1024 or 2048 bit) p every time is prohibitively slow when we're
talking about potentially 100's of new sessions per hour.
Of the following options, which would the friends of sci.crypt
recommend?
1. Generate a new smaller prime (say, 128 bit) for each new session.
2. Choose randomly from a pool of 50 or so large (2048 bit) primes that
are hard-coded into the client and server... Assume that evil genius X
has access to this list of primes.
3. Why not just use the same extra-huge prime every time? Or change it
once a week when I take out the trash?
4. ...?
Thanks for any info.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Dynamical Cryptography algorithm
Date: Wed, 28 Jun 2000 20:09:18 -0700
Sylvain Martinez <[EMAIL PROTECTED]> wrote in message
news:8jd9t9$hjj$[EMAIL PROTECTED]...
>
>
> > Quick! Tell Bruce Schneier! I'm sure he'd be delighted to know that
> > Blowfish has a variable block size.
>
> :O)
> ok apparently not...
> Sorry I am not familiar with blowfish and thought it was the case.
> Is there any cryptography algorithm around allowing the user to change
> different value such as the size of the different blocks used in the
> crypt process ? (I am not speaking about the keylength, but the size of
> the block the algorithm will work with)
One of the parameters that you can adjust with RC6 is the block size. The
parameters selected for the version used as an AES finalist is 128 bits (of
course), but it can be set to a different multiple of 4 bits.
--
poncho
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Thoughts on "Cracking" of Genetic Code
Date: Thu, 29 Jun 2000 03:56:18 GMT
rick2 wrote:
>
> In article <mJ665.2341$[EMAIL PROTECTED]>, "Adam Durana"
> <[EMAIL PROTECTED]> wrote:
>
> > I'm no expert on this subject but I believed they used one method
> > cryptanalysists do use. ... produce the cipher text (the living creature)
> > and see what changes in the
> > cipher text resulted from the change in the plain text.
>
> True. You can make a mutation in a mouse ES cell that ablates or
> alters a gene, then generate a live mouse carrying that mutation
> in its germline to analyze the effects. Takes about 1-2 years and
> $50-100,000 for each different mutation. Talk about brute force!
======================
This is why Drosofila Melanogaster and Escerichia Coli are objects of
choice for genetic experiments. New generations follow in days or
even in hours.
BTW, imagine experiments on sequoias...
Best wishes BNk
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Thoughts on "Cracking" of Genetic Code
Date: Thu, 29 Jun 2000 03:54:00 GMT
On Wed, 28 Jun 2000 22:21:37 GMT, [EMAIL PROTECTED] (Steve
Roberts) wrote, in part:
>What I predict will occur is that nutters will now start to find
>messages in the genome sequence. It happened to Shakespeare and the
>Bible, why not this?
Yes, I think that's a pretty safe prediction.
Whether one will actually get a book published by a major publisher,
or whether it will be limited to crank USENET posts, however, is still
shrouded by the mists of time...
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Diffie Hellman Primes : Speed Tradeoff Q
Date: Wed, 28 Jun 2000 21:00:04 -0700
> 1. Generate a new smaller prime (say, 128 bit) for each new session.
No. Don't do this.
> 2. Choose randomly from a pool of 50 or so large (2048 bit) primes that
> are hard-coded into the client and server... Assume that evil genius X
> has access to this list of primes.
You could, but not really necessary.
> 3. Why not just use the same extra-huge prime every time? Or change it
> once a week when I take out the trash?
Just use one prime, and don't worry about it. If you are transmitting
ICBM launch codes, then changing the primes once a week might help
you sleep a little better.
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Another chaining mode
Date: Thu, 29 Jun 2000 04:21:14 GMT
Mark Wooding wrote:
> ... It halves the speed of a block cipher, and works
> best on ciphers with a large block size. It also propagates errors
> rather effectively (which probably isn't a good thing). Let's call it
> half-block chaining (HBC).
>
> We split the plaintext and ciphertext blocks into two halves, and I'll
> write (x', y') = E_k(x, y) to denote that the result of encrypting the
> plaintext half-pair (x, y) is (x', y').
>
> Let the plaintext to be encrypted be x_0, x_1, ... Choose a half-width
> initialization vector y_0. We then define the ciphertext z_0, z_1,
> ... and the remaining y_i by the simple relation:
>
> (z_i, y_{i+1}) = E_k(x_i, y_i) i >= 0
>
> Clearly, we need to decrypt *backwards* to get this to actually work
> properly.
>
> I can't see that this weakens the cipher in any particularly meaningful
> way: after all, any known- or chosen-plaintext attack translates
> immediately into a similar attack against the underlying cipher. Even
> so, I don't think doing silly things with chaining modes is a good idea.
>
> -- [mdw]
===================
My submission to the Crypto-contest MMBOOZE works exactly in this
manner
within the block.
It takes the 32-bit number for modular multiplication, and then, when
this original number is replaced with the modular product, advances
along the
block 16 bits, taking half of the last product into the new modular
multiplication. The block length can be any multiple of 32 bits (even
the
whole file), default is 128.
You are correct - the speed of avalanche is fantastic!
In case of file, it will make sense to encrypt the file twice in your
half
block chaining (HBC) mode, cyclically wrapping the index over the end of
the file to the beginning. This will give the infamous "All-Or-Nothing"
encryption, at the expense of slowing down 4 times.
Naturally, the decryption must be done in reverse direction.
Best wishes BNK
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Does anyone have code for generating primitive polynomials?
Date: 29 Jun 2000 04:59:58 GMT
>Do you want to work in GF(2^n) or GF(p^n) p>2? For GF(2^n) you can
>use an irreducible() routine to check if a polynomial is prime, then
>take x^d for all d|(2^n-1) modulo your polynomial and check to see
>if it's not 1. You can find code for this at
>http://www.terracom.net/~eresrch under "polynomial.c"
>
>Have fun!
>
>Patience, persistence, truth,
>Dr. mike
>
>
>
I am working in GF(2^n)
with n from 33 to 1050 or so
I will check out the pointer
The method you describe does not seem practical for
large n. Do you know of another method?
Checking for primality should be easy.
Checking for primitiveness seems a little harder.
Thanks
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Kurt Shoens)
Subject: Re: Compression & Encryption in FISHYLAND
Date: 28 Jun 2000 22:42:29 -0700
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
>[...] thus, it does make sense to take even the AES winner, and try to use
>it in such a way that *if* it did turn out to have a weakness, it
>would be impossible to exploit that weakness (i.e., use whitening or
>other measures to prevent known-plaintext attacks) to read the
>messages sent before the weakness became known.
OK, but if whitening is a good idea, shouldn't it be a part of the base
cryptosystem? It's in Twofish already, maybe in others.
And ... if a little plaintext obscuring (whitening) is good then lots
of obscuring (super encrypting with additional algorithms) is better,
as has been debated recently. Again, in aggregate, it's just another
cryptosystem.
Back to the AES thing: assume the winner has an as-yet-unknown
exploitable weakness. No one knows what the best defense against
the weakness will be. Work on the mundane aspects of security is
likely to pay off. Chasing shadows, while fun, isn't.
Since we don't know the weaknesses, the justification for avoiding
known plaintext comes back to brute force key search. I think the
community has developed a phobia about brute force key search, possibly
due to the years of worrying about 56-bit DES keys. Perhaps this
explains the baffling distributed.net attack on 64-bit RC5.
Only 1,112 days to go before the key space is exhausted!
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Remark on practical predictability of sequences
Date: 29 Jun 2000 05:37:19 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>> coefficients of the LCG but not its seed value. The masking of the
>> nonces by the DSS algorithm can be solved even though it seems nonce
>> recovery should require solving the discrete logarithm problem.
yes, this is a neat paper. thanks for reminding me of it.
>>
>> Paper's at http://www-cse.ucsd.edu/users/mihir/papers/dss-lcg.html
>>
> I'll look at the paper to see if it addresses directly the matter of my
> scheme (I hope I'll be able to understand the material). In the meanwhile
you should arm yourself with something like Joux & Stern "Lattice Basis
Reduction, A Toolbox for the Cryptanalyst" to read in concert with the DSS
paper. That paper is on Jacques Stern's web page whcih I can't recall at
the moment but a web search will turn up.
-dmolnar
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Variability of chaining modes of block ciphers
Date: Thu, 29 Jun 2000 09:14:22 +0200
Shawn Willden wrote:
> Mok-Kong Shen wrote:
>
> > You are right. Many thanks for the demonstration. This indeed clearly
> > shows that my view up till now that there could be chaining modes
> > among what I mentioned in the original article that offer more than
> > a few bits is wrong. Your demonstration simultaneously provides me
> > the insight that one should use non-linear values for chaining, if one
> > desires to do better. An idea that suggests itself is to use the square
> > of the sum as chaining value, for that evidently escapes your attack.
>
> It appears to escape this attack. To make it really good, you should probably make
>it
> some sort of keyed transform, with good avalanche and diffusion properties.
>
> Better yet, use a good cipher and don't rely on chaining to add security against key
> recovery attacks. Many chaining modes are very effective at what they are intended
>for --
> defeating block substitution/rearrangement attacks that are left open by ECB mode.
>
> Even better still, maybe you should use a well-studied, standard technique that
> effectively obscures the blocks and adds substantial security -- A stream cipher.
>ARCFOUR
> would be a good choice, since it's simple, free, small, efficient and secure. When
> combining a weak block cipher with a good stream cipher, I would be tempted to
>discard the
> weak block cipher, though :)
>
> Finally, you could get a good block cipher, *and* a good stream cipher and be quite
> certain that no one will read your e-mail unless they break into your house and
>steal your
> keys or hold a gun to your head and ask you what you wrote.
I did combine stream cipher and block cipher techniques into one in
a design of my own. There a PRNG is used to generate pseudo-
random numbers to do transpositions and select substitution tables
in the way of block encryption and also to add to the intermediate
text under processing in the way of stream processing. I used two
chaining modes. One of them is the sum of plaintext and ciphertext,
which has been shown by you to be able to gain only 1 bit and
needs to be updated. (Thanks once again.) The other mode consists
in taking a (simple) hash value of the block in the middle of its
processing and skips the output of the PRNG by an amount equal
to the hash value so that the encryption of the following block gets
influenced.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Another chaining mode
Date: Thu, 29 Jun 2000 09:14:30 +0200
Boris Kazak wrote:
> Mark Wooding wrote:
[snip]
> > (z_i, y_{i+1}) = E_k(x_i, y_i) i >= 0
> >
> > Clearly, we need to decrypt *backwards* to get this to actually work
> > properly.
> My submission to the Crypto-contest MMBOOZE works exactly in this
> manner
> within the block.
[snip]
> You are correct - the speed of avalanche is fantastic!
[snip]
> Naturally, the decryption must be done in reverse direction.
I have a question about this: If one decrpyts two consecutive pairs
to (x_i, y_i) and (x_(i+1), y_(i+1)), wouldn't one get (x_i, x_(i+1)),
i.e. one original block? So what do you mean by doing decryption
in the 'reverse direction' above? Another point: If one does with any
block cipher in double rounds and hence consumes double time,
wouldn't avalanche also improve substantailly as you noted? Thanks.
M. K. Shen
------------------------------
** 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
******************************
