Cryptography-Digest Digest #266, Volume #13 Sun, 3 Dec 00 21:13:01 EST
Contents:
Re: Self Shrinking Additive Generators? (Simon Johnson)
Re: The Next Step After OTP (Bryan Olson)
Re: Secure Passwords On The Cheap (Thomas Wu)
Re: Pentium 4 and modular exponential (Jason Stratos Papadopoulos)
Re: Pentium 4 and modular exponential (Paul Rubin)
Re: Rudimentary Encryption ("Potyanimal")
Re: On mutation of crypto algorithms (Tom St Denis)
Re: Q: Discrete transforms in practice (Tom St Denis)
Re: Rudimentary Encryption ("Potyanimal")
Re: The Next Step After OTP (Steve Portly)
which algorithm ("Carl Egil Monstad")
Re: which algorithm (David Schwartz)
Re: which algorithm (Tom St Denis)
Hole in MCRYPT_TripleDES ("Randy Sofia")
Re: which algorithm (csybrandy)
Re: File Deleter/Nuker ? (g4rga)
Re: Hole in MCRYPT_TripleDES ("John A. Malley")
Re: Hole in MCRYPT_TripleDES ("Scott Fluhrer")
----------------------------------------------------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Self Shrinking Additive Generators?
Date: Sun, 03 Dec 2000 21:11:16 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Simon Johnson <[EMAIL PROTECTED]> wrote:
>
> : We know the LFSR's that are ran in the self shrinking configuration
> : are secure provided a dense polynomial is used.
>
> Do we?
> --
> __________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
> |im |yler The Mandala Centre http://mandala.co.uk/ Free gift.
>
Okay, we don't *know* that it will remain secure forever.....
But at this time...... There are no feasible attacks to recover the key
from an SS-LSFR 'random' stream generator.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: The Next Step After OTP
Date: Sun, 03 Dec 2000 21:33:38 GMT
I wrote:
> Some authors adopt a more general notion of universal
> hash functions, in which the ones I'm talking about
> are called "2-universal".
I find the definition of a 2-universal hash function is
stronger than the one I gave for a universal hash function.
The 2-universal hash is ideal for authentication using a
one-time key.
The definition of an n-universal hash function (adapted from
Cormen, Leiserson and Rivest's /Introduction to Algorithms/)
is:
Given a message space M, a key space K and a
signature space S, an n-universal hash function
is a function H: KxM -> S, such that:
For any n messages in M that are all distinct,
call them m1, m2, ... mn,
if k is chosen so that all members of K are equally
likely,
then the sequence:
H(k, m1), H(k, m2), ... H(k, mn)
is equally likely to be any of the |S|^n
sequences of length n with elements drawn from S.
Note that a universal hash function is not a cryptographic
hash. In crypto terms, it's a kind of MAC; it maps a key
and message to a signature.
A 2-universal hash function is exactly what we want in order
to obtain provable authentication using a one-time random
key. For any two distinct messages m1 and m2, the sequence
H(k, m1), H(k, m2)
could be any two signatures (not necessarily distinct). If
our attacker wants to sign a message, he has no information
on which signature is correct. When we use the key one
time, the attacker may obtain H(k, x), possibly for known x.
But the signature on any other message could still be
anything. Since we use each key only once, the attack never
gets any more information that would help him sign.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: Secure Passwords On The Cheap
Date: 03 Dec 2000 14:04:36 -0800
[EMAIL PROTECTED] (John Savard) writes:
>
> Use a long, secure, PGP-style pass-phrase...to encrypt the password
> file. Require the system operator to type it in when starting up the
> system.
>
> Then, the secret key for each user, kept in the password file,
> corresponding to the public key for the user which is on the user's
> computer, encrypted by his little password, is now well enough
> protected that we actually have security.
The EPS password database in the SRP distribution is a natural place
to implement this idea, especially if you want your code to be Open
Source and reach a broad audience. I'm planning to release an
update release (1.7.1) soon.
> Of course, that does *not* mean it isn't a very good idea to have a
> separate computer, that users don't run their own programs on, to
> handle the encryption and user authentication, it just means that a
> halfway decent solution that really does eliminate the dictionary
> attack is possible without extra hardware.
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/
------------------------------
From: Jason Stratos Papadopoulos <[EMAIL PROTECTED]>
Subject: Re: Pentium 4 and modular exponential
Date: 3 Dec 2000 22:14:56 GMT
Paul Rubin <[EMAIL PROTECTED]> wrote:
: What makes you say that??? If it were made for big-integer arithmetic
: it would have a wide carry register or large accumlator. The best
: architecture I've seen yet for modexp is the Motorola 56000 series DSP.
: This can start a 24x24 multiply-accumulate every cycle, with a 56 bit
: accumulator, so you can add up to 256 partial products before you
: have to worry about carry overflow.
Analog Devices' DSP chips now have 32-bit multiply-accumulates into
an 80-bit register. The 21160 DSP has two separate execution units that
can each do a 32-bit multiply-accumulate every clock.
jasonp
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Pentium 4 and modular exponential
Date: 03 Dec 2000 14:23:11 -0800
Jason Stratos Papadopoulos <[EMAIL PROTECTED]> writes:
> Analog Devices' DSP chips now have 32-bit multiply-accumulates into
> an 80-bit register. The 21160 DSP has two separate execution units that
> can each do a 32-bit multiply-accumulate every clock.
Woo hoo! What clock speed does it run at, and how much does it cost?
Sounds like it's *built* for modexp.
------------------------------
From: "Potyanimal" <[EMAIL PROTECTED]>
Subject: Re: Rudimentary Encryption
Date: Sun, 03 Dec 2000 22:31:24 GMT
Simon Johnson wrote...
> If you don't need to use this program, Don't. Counterpane security have
> a little freeware program called 'Password Safe' to handle the task of
> storing passwords.
The point wasn't to secure these passwords. The point is that in my job, I
help computer-illeterate people most of my job is configuring mail clients
for users. Since these settings are being stored on the network in each
users homedirectory, its easier for me to edit these settings from my
computer. Entering all the username, host, and e-mail information is easy,
but the password is encrypted. That's why I would like to know how the
password is encrypted relatively to each key, so that I could write a
program, that for a password, would spit out the encrypted value and its
key.
Right now i've been entering the key into MY client, and copy/paste the
encrypted password from MY .ini file, to their .ini file, and then going
back to fix MY client for me. I think that was the point of confusion.
I'm feeling a little disapointed now though that it appears to a replace
this charcter in this position with this other character type thing, which
sounds alot like Stephen Anthony Uy's paper about AIM password encryption.
Maybe there is somthing that I can apply from there.
Thanks for the help.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: On mutation of crypto algorithms
Date: Sun, 03 Dec 2000 22:27:01 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> Tom St Denis wrote:
> >
> > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > Tom St Denis wrote:
> > > >
> > > > [EMAIL PROTECTED] wrote
> > > > >
> > >
> > > > > The Rijndael state doesn't have to be square. Either a 2x4
array
> > > > > (Nb = 2, word size 4 bytes, and shift offsets C1 = 1, C2 = 0,
C3
> > = 1,
> > > > > for example) or a 4x2 array (Nb = 4, word size 2 bytes, C1 =
1)
> > appear
> > > > > to work.
> > > >
> > > > Wouldn't it have to be a 4x2 to work? The C(x) column
transform is
> > a
> > > > 4x4 MDS is it not?
> > >
> > > But you can use a 2*2 matrix. (On scaling-down, one normally
> > > has to twist a little bit.)
> >
> > You can't perform the C(x) on a 2x2, only on a 4x1. Otherwise it is
> > NOT rijndael.
>
> If you want to talk rigorously, then ANY modification to
> what described in Rijndeal is NOT Rijndael. You can
> define a analogous 2*2 matrix to do the column combination,
> can't you?
My math skills are that of a high school student, but I am not aware of
being able to turn a 4x4 matrix into an equivalent 2x2 matrix. The c
(x) transform is really a 4x4 matrix multiplied by a 4x1. That is why
modifications to Rijndael modify the number of columns not rows. If
you make rijndael use 4x2 blocks it should work compared to 2x4 blocks.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Q: Discrete transforms in practice
Date: Sun, 03 Dec 2000 22:29:12 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> Tom St Denis wrote:
> >
> > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > >
> > > I like very much to know whether, which kinds of, and to
> > > what extent and success, if any, discrete transforms (other
> > > than PHT used in some algorithms) have occured in actual
> > > practical applications. Thanks in advance.
> >
> > Things like the DFT and DCT are not normally "invertable" in
practice.
> > The Fast Fourier Transform is used in numerous designs such as the
CS-
> > Cipher and FFT-HASH (and TC2 out of my personal collection).
>
> The invertibility can be assured with sufficient
> computational precision, I suppose. The Hadarmard transform
> is in any case invertible with ease. (BTW, what I mean is
> transfomations applied to a larger group of bits, not like
> locally in a block encryption algorithm.)
I fail to see the distinction between "group of bits" and "local group
of bits". If your algorithm works on n-bits of data p-bits at a time
it's still a n-bit cipher not a p-bit one.
Also transforms such as the DCT/DFT are often lossy because you would
require infinite bits of precision otherwise...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Potyanimal" <[EMAIL PROTECTED]>
Subject: Re: Rudimentary Encryption
Date: Sun, 03 Dec 2000 22:45:05 GMT
John Savard wrote...
> Well, it can feed the seed into a random number generator, and call it
> for random numbers as it builds a rotor machine - so it can simulate
> thousands of different rotor machines, but only one at a time.
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
So if that is the case, then I would need to know what method that this
program goes about generating random numbers from the seed and how that is
then applied to the rotor machine, right? That's what I am looking for.
What you're saying makes sense though.
------------------------------
From: Steve Portly <[EMAIL PROTECTED]>
Subject: Re: The Next Step After OTP
Date: Sun, 03 Dec 2000 18:07:39 -0500
John Savard wrote:
> On Sun, 03 Dec 2000 16:00:44 GMT, [EMAIL PROTECTED]
> (John Savard) wrote, in part:
>
> >(i.e., eliminate known plaintext by picking 160 random bits, then use
> >the OTP to encipher the message consisting of the 160 random bits, the
> >160 random bits XOR the hash of the message, and the 160 random bits
> >repeatedly XORed with the plaintext of the message)
>
> Oops. That would NOT work.
>
> Change that to: 'the message consisting of the 160 random bits, the
> plaintext of the message XORed repeatedly with the 160 random bits,
> and the hash of the message as so modified', and it will work.
>
> With a known plaintext and a known hash, bit flipping isn't prevented
> if what one does is equivalent to just using a different OTP - which
> is what my imperfect proposal would be.
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
If you use enough different random key elements xored together, and chain
them in a reasonable fashion the security of your system is ((character set
^( Number of key elements - 1) + character set )) isn't it? encrypting a
sufficiently long signature at the end of each message will verify the
message without any birthday attack possible. If the message cannot be
decrypted it cannot be bit flipped into any other meaningful message.
------------------------------
From: "Carl Egil Monstad" <[EMAIL PROTECTED]>
Subject: which algorithm
Date: Mon, 4 Dec 2000 00:01:44 -0500
I have one single line of ciphertext.
Does anybody know how I can find out which algorithm is used?
thanks
Carl Egil Monstad
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: which algorithm
Date: Sun, 03 Dec 2000 15:17:03 -0800
Carl Egil Monstad wrote:
>
> I have one single line of ciphertext.
> Does anybody know how I can find out which algorithm is used?
Ideally, ciphertext should look entirely random to someone who doesn't
know they key. Since you don't know the key, if a good cipher was
chosen, the output should be indistinguishable from random. So there
would be no information from which you could divine the algorithm. On
the otherhand, if the algorithm is weak (say, simple substitution) it
will leave clues to that in the output, which will resemble the input in
subtle ways.
DS
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: which algorithm
Date: Sun, 03 Dec 2000 23:34:17 GMT
In article <LjAW5.1164$[EMAIL PROTECTED]>,
"Carl Egil Monstad" <[EMAIL PROTECTED]> wrote:
> I have one single line of ciphertext.
> Does anybody know how I can find out which algorithm is used?
>
> thanks
No. Unless there is a header there is practically no way.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Randy Sofia" <[EMAIL PROTECTED]>
Subject: Hole in MCRYPT_TripleDES
Date: Sun, 3 Dec 2000 19:13:19 -0500
Listen to this... I'm writing a backend for a site that requires tight
security... being a novice to cryptography I decided to use MCRYPT_TripleDES
and changing the key each hour depending on the hour.. so for example if its
7:00 the key would be "19 2000-12-03cheese" if its 8:00 the key would be "20
2000-12-03cheese" cheese is the password, so the password is also used in
the key.
During my testing phases I noticed that sometimes two different hours would
give me the same encrypted password. Let me show you...
I'm encrypting the password "cheese" the following is a long list of
encrypted versions of cheese -- the key used to encrypt it:
81dc31f6d6139ed2 -- 19 2000-12-03cheese
81dc31f6d6139ed2 -- 18 2000-12-03cheese
bcd7f6e6f2986639 -- 17 2000-12-03cheese
bcd7f6e6f2986639 -- 16 2000-12-03cheese
eab3a333ef5051eb -- 15 2000-12-03cheese
eab3a333ef5051eb -- 14 2000-12-03cheese
c93d913fc87e6ec8 -- 13 2000-12-03cheese
c93d913fc87e6ec8 -- 12 2000-12-03cheese
dca38d8d8eaf50b4 -- 11 2000-12-03cheese
dca38d8d8eaf50b4 -- 10 2000-12-03cheese
02c39858203aeb6f -- 9 2000-12-03cheese
02c39858203aeb6f -- 8 2000-12-03cheese
5d028682eb17fb30 -- 7 2000-12-03cheese
5d028682eb17fb30 -- 6 2000-12-03cheese
b52cfd438d53662b -- 5 2000-12-03cheese
b52cfd438d53662b -- 4 2000-12-03cheese
Now take a look at that... Why does the encypted password recur even though
the key changes by 1?
In order to fix this I took the square of the time rather then the time
itself. But still, why would it recur even though I incremented a number in
the key by 1? Isn't that odd?
Thanks,
~Randy
------------------------------
From: csybrandy <[EMAIL PROTECTED]>
Subject: Re: which algorithm
Date: Sun, 03 Dec 2000 19:22:03 -0500
Carl Egil Monstad wrote:
> I have one single line of ciphertext.
> Does anybody know how I can find out which algorithm is used?
>
> thanks
>
> Carl Egil Monstad
If the ciphertext is only alphabetic characters, you may be able to try
some statistical analysis. Of course, the line of ciphertext would have
to be long enough depending on the algorithm that was used to create it.
csybrandy
------------------------------
From: [EMAIL PROTECTED] (g4rga)
Subject: Re: File Deleter/Nuker ?
Reply-To: Jim
Date: Mon, 04 Dec 2000 00:49:41 GMT
On Sat, 02 Dec 2000 20:15:19 GMT, Tom St Denis <[EMAIL PROTECTED]> wrote:
>Most of the time hard disks are so dense that writing over the data
>once is often enough. "Multi-pass" file wipers are just plain paranoia
>food. On floppy disks your best bet is to burn them since they are
>cheap. But because hard disks store information so densely the
>probability of left over data is next to nill.
Really? Have you read the Gutman paper on disc/memory
contents recovery, Tom?
--
______________________________
Posted by Jim Dunnett
dynastic at cwcom.net
nordland at lineone.net
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Hole in MCRYPT_TripleDES
Date: Sun, 03 Dec 2000 17:03:25 -0800
Randy Sofia wrote:
>
[snip]
>
> Now take a look at that... Why does the encypted password recur even though
> the key changes by 1?
>
> In order to fix this I took the square of the time rather then the time
> itself. But still, why would it recur even though I incremented a number in
> the key by 1? Isn't that odd?
A piece of information is missing - how does the string convert into a
key value?
The string-to-key conversion is the first place I'd look to rule it out
as a problem.
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Hole in MCRYPT_TripleDES
Date: Sun, 3 Dec 2000 17:06:24 -0800
Randy Sofia <[EMAIL PROTECTED]> wrote in message
news:90enfm$b93g$[EMAIL PROTECTED]...
> Listen to this... I'm writing a backend for a site that requires tight
> security... being a novice to cryptography I decided to use
MCRYPT_TripleDES
> and changing the key each hour depending on the hour.. so for example if
its
> 7:00 the key would be "19 2000-12-03cheese" if its 8:00 the key would be
"20
> 2000-12-03cheese" cheese is the password, so the password is also used in
> the key.
>
> During my testing phases I noticed that sometimes two different hours
would
> give me the same encrypted password. Let me show you...
>
> In order to fix this I took the square of the time rather then the time
> itself. But still, why would it recur even though I incremented a number
in
> the key by 1? Isn't that odd?
What's happening is because of the precise definition of DES. It is
officially defined using 64 bit keys, of which the LSBits are ignored[1] --
they do not contribute anything to the defined transform. That is, two
separate DES keys (and because 3DES is based on DES, two separate 3DES keys)
that differ only in the least significant bits will act exactly the same --
they will encrypt the same plaintext into the same ciphertext.
The obvious fix to your problem is to do a bit rearrangement to make sure
that all the bits that make up significant parts of the timestamp (and the
password) are in bits 7-1.
However, if the attacker gets your log file, and knows the timestamp that it
was encrypted under, his knows a significant number of the key bits -- he
knows all of one of the DES keys, and over half of the middle key. If the
attacker can manage to find one known plaintext block within the log file,
then he should be able to use a meet-in-the-middle attack on the rest of the
key to break this with O(2**56) effort. Surely, (IMHO) this is not
acceptable for something that requires "tight security".
My first recommendation is that, if you really do have tight security
requirements, is to hire a professional, rather than trying to do it
yourself. My second recommendation (in case you don't take the first) is to
hash the timestamp and the password together, and use that hash as the 3DES
key. I'm not familiar with MCRYPT, but there should be some hash function
in there with an output of at least 192 bits.
[1] Actually, they were originally defined as parity bits, to aid in error
checking on manually entered keys. In current practice, keys are generated
automatically, and so error checking is irrelevant, and so the "parity bits"
are ignored.
--
poncho
------------------------------
** 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
******************************
