Cryptography-Digest Digest #265, Volume #13 Sun, 3 Dec 00 16:13:00 EST
Contents:
Re: I need to crack a key ([EMAIL PROTECTED])
Re: The Next Step After OTP ("Scott Fluhrer")
Re: Q: Discrete transforms in practice (Mok-Kong Shen)
Re: On mutation of crypto algorithms (Mok-Kong Shen)
Re: Secure Passwords On The Cheap (Mok-Kong Shen)
Re: Self Shrinking Additive Generators? (Tim Tyler)
Re: hardware RNG's (Tim Tyler)
Re: hardware RNG's (Tim Tyler)
Re: Secure Passwords On The Cheap (John Savard)
Re: hardware RNG's (Tim Tyler)
Re: keysize for equivalent security for symmetric and asymmetric keys (DJohn37050)
Re: hardware RNG's (David Schwartz)
Re: File Deleter/Nuker ? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: I need to crack a key
Date: Sun, 03 Dec 2000 16:57:49 GMT
Thanx for all the math, guys. I really don't know what you are talking
about, but in its own mad-scientist-kind-of-way it all makes a little
sense.
Thanx also for the brand info.
I'll have to take my chances.... and a lot of time it seems....
Best of the best
D
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: The Next Step After OTP
Date: Sun, 3 Dec 2000 09:15:30 -0800
John Savard <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Sun, 3 Dec 2000 00:07:42 -0800, "Scott Fluhrer"
> <[EMAIL PROTECTED]> wrote, in part:
>
> >Actually, the usual approach to avoid bit-flipping (or any other form of
> >active attack) is to add a MAC (message authentication code).
>
> That's certainly true, and that can be combined with public-key
> methods to make a digital signature and so on as well.
(Actually, you're thinking of a secure hash. A secure hash and a MAC are
two different things)
>
> I am sorry if, by neglecting to mention that possibility, my post
> appeared misleading. I was simply noting that the OTP is sometimes
> considered inadequate _as a cipher_ because it is vulnerable to
> bit-flipping, while other ciphers (i.e. DES in CBC mode) are not, and
> therefore I was concerned with showing how the OTP could be adapted,
> with minimal alteration, to correct this.
If "they" consider CBC mode to be invulnerable to active attacks, they are
wrong. In addition to injecting garbage into the decrypted data stream, an
attacker can, with sufficient amount of data, do splicing attacks to
generate plausible decryptions.
Unless active attacks are not a part of the threat model, or you cannot
abide any ciphertext expansion, it seems foolish not to do message
authentication[1] (either by a MAC, or by a transform that encrypts and
authenticates).
[1] By message authentication, I mean adding redundancy to the message so
that the receiver can reject messages that are not from the sender, and in
an manner such that a forged message from someone else has an extremely low
probability of being accepted.
--
poncho
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Discrete transforms in practice
Date: Sun, 03 Dec 2000 18:40:39 +0100
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.)
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On mutation of crypto algorithms
Date: Sun, 03 Dec 2000 18:45:37 +0100
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?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Secure Passwords On The Cheap
Date: Sun, 03 Dec 2000 18:59:34 +0100
John Savard wrote:
>
> In an earlier series of posts, I expressed concern with SRP and PAK,
> because they did not really eliminate the possibility of a 'dictionary
> attack' on passwords if the password file in the server was
> compromised.
>
> Such an attack would be slowed by involving public key computations,
> but not public-key cracking as in the simple passive attack on EKE
> communications.
>
> I tried to address the problem using a hierarchical model inspired by
> Kerberos; a secure machine, in effect, types a second 'password' for
> the user at the host end. I learned about the Kaliski-Ford method,
> which uses multiple hosts at an equal level, but maintains security as
> long as they are not all compromised.
>
> Well, given the assumption that ongoing processes and RAM aren't
> compromised, because if they can be, no security could be obtained,
> but everything left on a hard drive is subject to compromise, I have
> come up with a 'solution' to the problem which stretches this
> assumption to its limit - by making one item kept in memory a very
> attractive target - but which does provide the level of cryptographic
> security I think is needed, even if it is dubious from the larger
> computer security viewpoint - while not requiring the users to
> memorize better passwords, or requiring any special hardware to be put
> in.
>
> It's really quite simple.
>
> 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.
>
> 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.
If the computer has a virus, then what the operator types
in could be compromised. If the computer is well-protected
and the OS is sain, then of course everything is o.k. Or
do I miss something? Thanks.
M. K. Shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Self Shrinking Additive Generators?
Reply-To: [EMAIL PROTECTED]
Date: Sun, 3 Dec 2000 18:13:01 GMT
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.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Reply-To: [EMAIL PROTECTED]
Date: Sun, 3 Dec 2000 18:19:42 GMT
David Schwartz <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> However, I'm sure "random" is used in the sense you describe sometimes.
:>
:> It doesn't seem to be used that way very often within cryptography.
:> "Random" streams have the property of being hard to predict - and they
:> pass tests for randomness. 5:1 biased streams do not appear to qualify.
:> They don't fit Chaitin's notion of randomness, or Golombs, or any that I
:> know of - short of the rather loose definition of not being completely
:> predicatble.
: So then you would you have to say that it is possible to
: deterministically convert a non-random stream into a random stream.
No I would not. Unpredictable in this context would mean unpredictable
to all attackers, not just to ones ignorant of the deterministic process
used.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Reply-To: [EMAIL PROTECTED]
Date: Sun, 3 Dec 2000 18:29:35 GMT
Dan Oetting <[EMAIL PROTECTED]> wrote:
[definitions of randomness]
: Is radio-active decay a "random" event?
It has a large random component - but at least one measurable non-random one.
: Can we select a bead "at random" from a pot containing 20% white and
: 80% black beads?
Yes, to the extent that we can do anything at random, we can do this.
: If we have random variations in the frequency domain do we not have
: random variations in the time domain?
It's not clear what "random variations in the frequency domain" might
mean. You are talking about unboundedly large frequencies?!?
Or just a frequency that wobbles about a bit?
: The term "random" has a generic meaning of being uncontrolled,
: uncorrelated with other events. In statistics the term "random" has been
: given the specific meaning of equal probability of each possible value.
That's fair enough.
: If you continue to insist that "random" can only have the definition
: from statistics we will continue to beat it out of you.
Um, I'm not insisting on that. I'm saying that describing a stream of
5/6ths 1s and 1/6th 0s as "random" or "unpredictable" without
qualification has great scope for confusion. "Relatively non-random"
and "relatively predictable" would probably be closer to the mark.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Free gift.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Secure Passwords On The Cheap
Date: Sun, 03 Dec 2000 19:07:19 GMT
On Sun, 03 Dec 2000 18:59:34 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>If the computer has a virus, then what the operator types
>in could be compromised. If the computer is well-protected
>and the OS is sain, then of course everything is o.k. Or
>do I miss something? Thanks.
The idea is that while the computer may not have a virus, it still
can't be made completely invulnerable to root compromises, or to being
booted up with a floppy, so that even a shadow password file on the
hard disk can still be _read_.
The threat model _isn't_ totally realistic, as I admit, but since
everything can be compromised in the case of a virus, it does make
sense to look at how to achieve security in all cases short of that.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Reply-To: [EMAIL PROTECTED]
Date: Sun, 3 Dec 2000 19:00:45 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Certainly I think if you describe such biased streams as "random",
:> then you are likely to cause confusion in discussions with many people.
: Only amateurs who use a term only on the basis of a
: vague, fuzzy feeling instead of a precise definition.
Doubtful. Show a professional lots of binary strings where the 1s
outnumber the 0s five to one, and ask him to discuss whether thay are
"random". I expect he'll either say "no", or ask you to clarify your
question.
: The pros are well aware that random processes can
: produce biased distributions.
That is not the issue. The discussion centres around a description
of sequences themselves, not the process that generates them.
It is obvious that a random source can contribute to a biased sequence -
but that is not what is being discussed.
: The unadorned term "random" covers a wide gamut of
: intrinsically imperfectly predictable behavior.
: A typical example of a professional definition is
: http://www.stats.gla.ac.uk/steps/glossary/probability_distributions.html
: wherein it is immediately made clear that a random
: variable has an associated probability distribution
: or density function [...]
The word does not have the universal precise meaning you seem to think.
For example, try http://www.io.com/~ritter/GLOSSARY.HTM#Random for another
definition of "random".
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 03 Dec 2000 19:57:23 GMT
Subject: Re: keysize for equivalent security for symmetric and asymmetric keys
Bob discussed it, but the presentation expected was not made. I do not
remember if Bob had joined RSA at the time of the vote.
Don Johnson
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Date: Sun, 03 Dec 2000 12:20:42 -0800
Tim Tyler wrote:
> David Schwartz <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote:
> :> However, I'm sure "random" is used in the sense you describe sometimes.
> :>
> :> It doesn't seem to be used that way very often within cryptography.
> :> "Random" streams have the property of being hard to predict - and they
> :> pass tests for randomness. 5:1 biased streams do not appear to qualify.
> :> They don't fit Chaitin's notion of randomness, or Golombs, or any that I
> :> know of - short of the rather loose definition of not being completely
> :> predicatble.
> : So then you would you have to say that it is possible to
> : deterministically convert a non-random stream into a random stream.
> No I would not. Unpredictable in this context would mean unpredictable
> to all attackers, not just to ones ignorant of the deterministic process
> used.
You have just asserted an outright contradiction.
Suppose I have a bit stream that indicates whether or not a radioactive
decay was detected in a given millisecond. The stream is biased -- say a
decay is only detected every 100 milliseconds on average. You would say
that this stream is neither predictable nor random, since it's so
heavily biased.
Now I feed 100,000 bits of this stream into a SHA1 hash and throw out
all but the first bit. This first bit is both unpredictable and unbiased
even by the most stringent definition, it's random. Yet it was produced
by a determinstic process from a non-random stream. This is something
you said was impossible.
You can't have it both ways. If you're going to insist on an absurd
definition of "random", you will have to live with the consequences.
DS
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: File Deleter/Nuker ?
Date: Sun, 03 Dec 2000 20:27:39 GMT
Neil Sluman <[EMAIL PROTECTED]> wrote:
> A related question for others - How do these things work. Is it simply a
> matter of generating random numbers and writing them to the same place
> repeatedly or is it more complicated than that? Do most filesystems
> move data around, and risk leaving traces in the old locations or
> anything awkward like that. Is a predictable random pattern a bad
> thing in this case?
It's basically that, plus however more complicated you want to make
it. ;)
Few filesystems actually move data that's been written, instead opting
to try and position files where they won't be fragmented in the first
place. The one example I can think of offhand is ISO9660, which I
believe requires every file to be contiguous. Of course, since it's
only in widespread use on read-only media, it's not much concern here.
You really should go back and overwrite the inode (FAT entry,
whatever's applicable) after the file, to remove the file name and
size, and discourage relinking. After that, however, you're down to
much more specific problems, such as turning off caching on the
controller, looking for bab blocks, etc. All of which generate quickly
diminishing returns.
As to the single-pass, multi-pass question, it depends on what attack
you want to try and protect against. Essentially, you can recover data
three ways:
1. By a regular application running on the machine. For that,
overwriting the file once is sufficient. (provided the overwrite makes
it to the disk surface)
2. By removing the drive and installing it on a custom controller and
moving the heads by hand. In this case, you might actually pick up
some old resonance here and there, as well as gain access to some
unreliabe blocks the disk had mapped away. But it's probably nothing a
couple overwrites won't mask. As far as I know, the FBI is the best at
this particular technique, but mum's the word on how much success
they've had.
3. By taking the drive into a clean room (or glove box, if your garage
is actually for housing cars ;), taking it apart, and examining the
platters directly. (Preferably with an electron microscope of some
flavor, or other high-resolution device). Because this attack actually
allows you to strip away surface material and tunnel deeper into the
platter than with the non-contact heads, you can recover large amounts
of overwritten data. Unfortunatly, the only real-world data here is
whatever success various three-letter agencies have had, so there's no
real way to say how many overwrites are safe. Or even if safe actually
exists.
The best middle-of the road approach I could find when writing srm was
to use a series of random and nonrandom passes, designed to come as
close as possible to flipping every bit within the file a few
times. (That's the slightly more complicated part, since bits are
never written to disk in the same order they're stored.) Or, as an
option, to just dump random data over it once, making things much
faster.
That seems to prevent any command-line recovery of information, and
goes as far as I feel it's reasonable to go protecting against stolen
media. (ie, if your laptop is stolen, the thief won't recover anything
you erased with it.) It's a convient utility for people who work under
an NDA occasionally, removing email you'd rather you'd never read,
etc. It's not, however, any substitute for an encrypted file system
and media destruction where such measures are warranted.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
** 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
******************************
