Cryptography-Digest Digest #50, Volume #14 Sat, 31 Mar 01 11:13:00 EST
Contents:
Re: conferences? (David A Molnar)
Re: Question on the Quadratic Sieve ("Matt Timmermans")
Re: conferences? (Stefan Katzenbeisser)
Re: How good are ... ? (Frank Gerlach)
Re: Idea - (LONG) ("Douglas A. Gwyn")
Re: Idea - (LONG) (Paul Crowley)
Re: conferences? (Paul Crowley)
AES - yet another question :-) (Marc)
Simple private key encryptions (Darryl Wagoner - WA1GON)
Re: conferences? ("Henrick Hellström")
Re: conferences? ("Tom St Denis")
Re: AES - yet another question :-) (SCOTT19U.ZIP_GUY)
simple stream cipher (hehehe) ("Tom St Denis")
Very little support for 1536 bit RSA keys (was Re: Support for 1536 bit RSA keys?)
(texica)
dumb question 47 (Yechuri)
Re: simple stream cipher (hehehe) ("Scott Fluhrer")
Symmetric cipher security of GnuPG 1.0.4 (jtnews)
----------------------------------------------------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: conferences?
Date: 31 Mar 2001 06:29:40 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> True, but two problems. a) I lack the math to make a "new break" and b)
> nobody cares about a break that's been done before. I can't really attack
> Twofish for example since it's been designed against all the attacks I know
> off and well... my level of math makes designing new attacks hard (not to
> mention my isolation from other cryptographers...)
Yes, these are good reasons not to attack Twofish -- but there are more
ciphers in the world than Twofish. There are lots of proprietary or
limited-use ciphers out there. Some of them will be trivial. Some will be
really good - but most probably fall somewhere in between. Some of these
ciphers might be interesting to break, depending on what the application is.
Better yet, take a look at emerging standards for things like Bluetooth and
3rd generation cell phones. These take on much harder problems than just
block cipher design and are that much more likely to screw up. Plus some of
them maybe have medium bad proprietary ciphers involved. In general, anything
that looks like it's trying to reinvent SSL is probably a good target because
version 1.0 is likely to have bugs in it...
-David
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: Question on the Quadratic Sieve
Date: Sat, 31 Mar 2001 06:35:13 GMT
"Stefan Katzenbeisser" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> OK; here is a "quick and dirty" introduction to the QS:
> [...snip...]
That was truly beautiful.
Uhm.. I don't suppose you could do the same for GNFS?
------------------------------
Date: Sat, 31 Mar 2001 09:44:22 +0200
From: Stefan Katzenbeisser <[EMAIL PROTECTED]>
Subject: Re: conferences?
Tom St Denis wrote:
> I was wondering what conferences this type of cipher would be relevant too.
http://www.dice.ucl.ac.be/crypto/call_for_papers.html
always contains a large list of conferences on cryptography,
data security, etc...
--Stefan.
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: How good are ... ?
Date: Sat, 31 Mar 2001 10:41:11 +0200
Peter Engehausen wrote:
> Hi!
>
> How strong are chiphers who work *only* with pseudorandom numbers...?
> It surely depends on the generator, but if it's an average one,
> initialized by a good pass phrase?
>
> How can they be broken? Any usefull links or papers known?
>
> Thanks,
> Peter
RC4 can be considered a PRNG, but is unbroken yet.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Idea - (LONG)
Date: Sat, 31 Mar 2001 10:06:20 GMT
Rob Warnock wrote:
> Is there some way to quantify the added "work" for each primitive
> operation (as a function of, "k", "m", how the bits & substitutions &
> permutations are chosen, existing redundancy of the text at each step,
> etc.), as well as assign an "increase in work" to the *composition* of
> such primitives[*], so that (in theory) one could start from the identity
> transformation and proceed stepwise all the way up to (say) Rijndael
> (or the like), thereby quantifying the total "work" that has been
> introduced? If so, this might be a basis for a formal discipline of
> cipher design.
Very doubtful. What that would accomplish is an estimate for
the amount of work necessary for the designed scheme of
encryption ("in the forward direction") but that's not even a
lower bound for the work needed for an optimal attack.
The whole is radically different form the sum of the parts.
------------------------------
Subject: Re: Idea - (LONG)
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Sat, 31 Mar 2001 12:12:37 GMT
[EMAIL PROTECTED] (David Wagner) writes:
> By the way, as a curiousity: If you have any such block
> cipher, each key can be broken with 2^{n/2} work (after
> a precomputation of 2^n steps). It is a fun puzzle to
> see why.
Can you specify the puzzle more precisely? If I can choose the
plaintext block, I can break any block cipher with an n-bit key
instantly, so long as I can have 2^n precomuptation and 2^n storage
:-)
cheers,
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
Subject: Re: conferences?
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Sat, 31 Mar 2001 12:12:40 GMT
"Tom St Denis" <[EMAIL PROTECTED]> writes:
> I just finished a design for a simple cipher based on MDS matrices and a FFT
> like network (like CS-Cipher) the idea is to make the encryption really
> simple and use it in CTR mode. The cipher takes a 192-bit key and a 64-bit
> block (i.e you encrypt the 64-bit counter and xor it against the msg as
> required).
I'd guess there would have to be something really stunning about a new
64-bit block cipher to get published. I suspect I got Mercy published
mainly because it tried to attack a relatively unexplored problem
domain, though it's hard to know for sure.
While I agree with Paul Rubin that you'll find it much easier to get
an attack published, if you want to get a cipher published, I
recommend trying to solve something that isn't well solved. If large
blocks don't take your fancy, how about small ones? We keep getting
calls on sci.crypt for a 32-bit or 16-bit block cipher for
applications like PID generation, and I don't know of a solution in
the literature - come up with a reasonably fast and conservative
solution, write it up really well, and publication might follow. Or
fast seekable stream ciphers? The distingushers for Leviathan means
this is still needing solved.
Best of luck,
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: [EMAIL PROTECTED] (Marc)
Subject: AES - yet another question :-)
Date: 31 Mar 2001 01:32:56 GMT
Thank you for your patience with the test vectors, I now understand
how to use them.
I have one further question if you don't mind. I notice that the
AES decryption (in software) tends to be slower than the encryption.
In my particular application I prefer fast decryption and slow
encryption. Is there any security drawback when I simply swap both
functions? In other words I plan to _De_crypt() the plaintext to
get ciphertext, and to _En_crypt() the ciphertext to get plaintext.
This way I have the speed advantage where I need it, and of course
I'm not compatible to other AES implementations anymore, but this
aside - do the AES security evaluations still apply?
------------------------------
From: [EMAIL PROTECTED] (Darryl Wagoner - WA1GON)
Subject: Simple private key encryptions
Date: Sat, 31 Mar 2001 13:01:09 -0000
Greetings,
Keep in mind that the TrustedQSL tool is mainly to keep
honest people honest.
What seem to me as an easy way to encrypt the DSA private key
is to take sha1 hash of the passphrase and xor it with
the private key. Same number of bits.
Then as a sanity check for the user I return the first
2 bytes of a sha1 hash of the uncrypted private key.
Which is passed back on the decryption call and it
has to match the decrypted private key. I started
out by passing back all of the hash, but that was too
insecure for my liking and I think the 2 bytes is enough
for the sanity check.
Input?
--
Darryl Wagoner - WA1GON
Join the TrustedQSL mailing list. An Open Source solution.
Post message: [EMAIL PROTECTED]
Subscribe: [EMAIL PROTECTED]
List owner: [EMAIL PROTECTED]
http://www.trustedQSL.org
------------------------------
From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: conferences?
Date: Sat, 31 Mar 2001 15:44:27 +0200
"Paul Crowley" <[EMAIL PROTECTED]> skrev i meddelandet
> While I agree with Paul Rubin that you'll find it much easier to get
> an attack published, if you want to get a cipher published, I
> recommend trying to solve something that isn't well solved. If large
> blocks don't take your fancy, how about small ones? We keep getting
> calls on sci.crypt for a 32-bit or 16-bit block cipher for
> applications like PID generation, and I don't know of a solution in
> the literature - come up with a reasonably fast and conservative
> solution, write it up really well, and publication might follow.
Steak is a cipher with an 8-bit block. It encrypts one byte at approximately
the same speed as most 128-bit block ciphers (TwoFish, Rijndael etc). This
is achieved by using a weak (but fast and sufficiently complex in its
context) block cipher in PCFB-8/256 mode. I would call that a fairly
conservative design, but perhaps you are of a different opinion?
> Or
> fast seekable stream ciphers? The distingushers for Leviathan means
> this is still needing solved.
Well, just for the record, Steak is not seekable.
--
Henrick Hellström [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: conferences?
Date: Sat, 31 Mar 2001 13:55:07 GMT
"Paul Crowley" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> writes:
>
> > I just finished a design for a simple cipher based on MDS matrices and a
FFT
> > like network (like CS-Cipher) the idea is to make the encryption really
> > simple and use it in CTR mode. The cipher takes a 192-bit key and a
64-bit
> > block (i.e you encrypt the 64-bit counter and xor it against the msg as
> > required).
>
> I'd guess there would have to be something really stunning about a new
> 64-bit block cipher to get published. I suspect I got Mercy published
> mainly because it tried to attack a relatively unexplored problem
> domain, though it's hard to know for sure.
How about provably secure against linear and differential attacks? Because
of the use of multipermutations I know that diffusion is optimal and since I
use really swell sboxes I have very low dp/lp maxes. This obviously doesn't
shut the door on other attacks. My cipher can be implemented in about 350
bytes on an 8-bit mcu (give or take) considering it has 280 byte tables (8x8
sbox and a 24-byte lut). The idea is to make a cool fast cipher
specifically for embedded platforms.
Tom
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: AES - yet another question :-)
Date: 31 Mar 2001 13:44:31 GMT
[EMAIL PROTECTED] (Marc) wrote in <[EMAIL PROTECTED]>:
>Thank you for your patience with the test vectors, I now understand
>how to use them.
>
>I have one further question if you don't mind. I notice that the
>AES decryption (in software) tends to be slower than the encryption.
>In my particular application I prefer fast decryption and slow
>encryption. Is there any security drawback when I simply swap both
>functions? In other words I plan to _De_crypt() the plaintext to
>get ciphertext, and to _En_crypt() the ciphertext to get plaintext.
>This way I have the speed advantage where I need it, and of course
>I'm not compatible to other AES implementations anymore, but this
>aside - do the AES security evaluations still apply?
>
First of all for the general kind of use Rijndeal is suppose to
be designed for there should be little difference from a security
point of view which way its used. If its "broken" by the NSA in the
forward directoin. Its broken if you use it in the reverse direction
so if you trust it one way no reason not to trust it the other way.
Someone correct me if this is all wrong.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.nbci.com/ecil/index.htm
Scott LATEST UPDATED sources for scott*u.zip
http://radiusnet.net/crypto/archive/scott/
Scott famous Compression Page
http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
A final thought from President Bill: "The road to tyranny,
we must never forget, begins with the destruction of the truth."
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: simple stream cipher (hehehe)
Date: Sat, 31 Mar 2001 14:38:30 GMT
Take a LFSR (of multiple of 8-bits in len... 64-bits for example). Take an
8x8 transform that is one long single cycle convolution (i.e repeated calls
will cycle thru all values 0..255) that is also decently non-linear and
differentially well distributed.
To generate a byte of output do this
1. Clock the LFSR once (e.g new bit). Forget the output of the LFSR since
it's actually the state of the LFSR we care about.
2. Divide the LFSR into an array of bytes (starting with the lsb of LFSR I
used the lfsr in galois mode for speed...)
3. r <= 0
4. for i = 0 to len_lfsr/8 do
4.1 r <= sbox[LFSR[i] xor r]
5. Output r
It's somewhat fast, requires only 10 bytes of ram (8 for key, two for loop
variables) and can be computed with a small piece of code.
The way I see step 4.1 is as random 8x8 encryptions of "r". So basically
you encrypt r eight times with diff parts of the LFSR. Since all of the
bytes of the LFSR change in each step the output isn't a single cycle of
0..255.
Any attacks? Obviously the last application of the sbox is not required
since it can be undone. So really it's 7 encryptions and 1 whitening.
Another obvious attack is to simply guess the last lfsr byte. If you get it
right you will know 7 of the 8 bits used in the next output byte. I dunno
how you would use that...
Please comment,
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
From: texica <[EMAIL PROTECTED]>
Subject: Very little support for 1536 bit RSA keys (was Re: Support for 1536 bit RSA
keys?)
Date: Sat, 31 Mar 2001 14:55:16 GMT
>According to the citations you provide, 1536-bits will not give you security
>for 20 years!
Yes I know. We are actually talking about 10+ years.
FYI I have contacted a number of software vendors about this issue and it looks
like 1536-bit keys are not well supported. Therefore it is likely we will have
to use 2048-bit RSA keys.
This is overkill since we will also use SHA-1 and SHA-1 is actually weaker than
2048-bit RSA... (it is expected that SHA-1 will be broken around 2012)
Anyway thanks for your help.
Regards
texica
------------------------------
From: [EMAIL PROTECTED] (Yechuri)
Date: 31 Mar 2001 15:01:18 GMT
Subject: dumb question 47
What's a free way to protect software on say a Sun
Sparc running either solaris or linux, using both
RSA and the hostid of the processor.
I'm guessing that if the machine is intel running
linux, you can't tie it to a specific machine ?
(without a dongle)
Also, is RSA really free to use i.e. I heard the patent
expired but is there any fine print about what you
can't do with the algorithm
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: simple stream cipher (hehehe)
Date: Sat, 31 Mar 2001 07:40:41 -0800
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:GZlx6.171921$[EMAIL PROTECTED]...
> Take a LFSR (of multiple of 8-bits in len... 64-bits for example). Take an
> 8x8 transform that is one long single cycle convolution (i.e repeated
calls
> will cycle thru all values 0..255) that is also decently non-linear and
> differentially well distributed.
Why do you care about it being a convolution?
>
> To generate a byte of output do this
>
> 1. Clock the LFSR once (e.g new bit). Forget the output of the LFSR
since
> it's actually the state of the LFSR we care about.
>
> 2. Divide the LFSR into an array of bytes (starting with the lsb of LFSR
I
> used the lfsr in galois mode for speed...)
> 3. r <= 0
> 4. for i = 0 to len_lfsr/8 do
> 4.1 r <= sbox[LFSR[i] xor r]
> 5. Output r
>
> It's somewhat fast, requires only 10 bytes of ram (8 for key, two for loop
> variables) and can be computed with a small piece of code.
>
> The way I see step 4.1 is as random 8x8 encryptions of "r". So basically
> you encrypt r eight times with diff parts of the LFSR. Since all of the
> bytes of the LFSR change in each step the output isn't a single cycle of
> 0..255.
>
> Any attacks? Obviously the last application of the sbox is not required
> since it can be undone. So really it's 7 encryptions and 1 whitening.
>
> Another obvious attack is to simply guess the last lfsr byte. If you get
it
> right you will know 7 of the 8 bits used in the next output byte. I dunno
> how you would use that...
Well, I'm not sure if this will work out to a full attack (and I don't have
the time to work out all the details), but one approach might be a
meet-in-the-middle attack:
- Divide the LSFR into two equal halves, LFSR[0..3] and LFSR[4..7]
- For LFSR[0..3], list for every LFSR contents the value of 'r' at
iteration 4 of the loop for the next N bytes. Because you'll need to assume
the LSFR bits coming in, that should be 2**(32+N) possibilities, so you
don't want to make N too large
- For LFSR[4..7], list for every LFSR contents the mapping between the value
of 'r' at iteration 4 of the loop and the keystream output. Again, because
you'll need to assume the LFSR bits shifting in, that should be 2**(32+N)
possibilities.
Now, go through the lists, and search for items that are compatible (that
is, jointly predict the correct keystream, and predicts the right bits being
shifted in). For each compatible set, run that set in the full cipher, and
see if it produces the correct keystream longterm. There'll be a lot of
possibilities, but if you are able to pick N large enough so that there are
no more than 2**(32+N) of them (N=4 looks about right), then (assuming the
search can be done efficiently, which is not immediately obvious), you have
an O(2**36) attack.
--
poncho
------------------------------
From: jtnews <[EMAIL PROTECTED]>
Crossposted-To: gnu.misc.discuss
Subject: Symmetric cipher security of GnuPG 1.0.4
Date: Sat, 31 Mar 2001 15:49:29 GMT
Does anyone know if there any limit
on passphrase length in GnuPG 1.0.4?
Is there a limit on the effectiveness
of very long passphrases due to the
implementation of the cipher algorithm?
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
