Cryptography-Digest Digest #286, Volume #12 Tue, 25 Jul 00 16:13:00 EDT
Contents:
Re: WinZip (stanislav shalunov)
Re: Database encryption ("Kevin Crosbie")
Re: Database encryption (Larry Kilgallen)
Re: CD destruction (Dave Hazelwood)
Re: Proving continued possession of a file (Andru Luvisi)
Re: WinZip (stanislav shalunov)
Re: Rabin's information dispersal algorithm (Volker Hetzer)
Re: Rabin's information dispersal algorithm (Mike Rosing)
Re: Question.How to avoid weak curves? (Mike Rosing)
Re: Rabin's information dispersal algorithm (David Hopwood)
Re: Idea - quantum crypto + chaffing & winnowing (David Hopwood)
Re: School question for you regulars. (James Pate Williams, Jr.)
Incremental Hashing (Steve Weis)
Re: School question for you regulars. ("The Gorf")
----------------------------------------------------------------------------
From: stanislav shalunov <[EMAIL PROTECTED]>
Subject: Re: WinZip
Date: 25 Jul 2000 12:26:12 -0400
"Martin 'SirDystic' Wolters" <[EMAIL PROTECTED]> writes:
> I just wanted to ask what algorithm WinZip uses to encrypt its
> archives.
It uses its own algorithm.
There's a very large number of crackers for this algorithm on the net.
Most of them just do a dictionary attack. Use your favorite search
engine.
There's also a known-plaintext cryptoanalytic attack by Eli Biham and
Paul Kocher, which is probably what you're asking about.
Paper about the attack:
ftp://utopia.hacktic.nl/pub/replay/pub/cracking/pkzip.ps.gz
(ZedZ site is down at the moment, so you'll have to wait to get this...)
Source (compilable on Unix) plus some executables are available from
http://www.unix-ag.uni-kl.de/~conrad/krypto/pkcrack.html
It requires that you have one of the files from the archive in plaintext.
------------------------------
From: "Kevin Crosbie" <[EMAIL PROTECTED]>
Subject: Re: Database encryption
Date: 25 Jul 2000 12:46:56 EDT
I was not very clear before:
I have data that I wish to encrypt and then enter into a database. The
data is provided by users, but must be extracted by the system, thus the
system must enter the data. The data will only be used on the system side
after entry.
The data is submitted by the users over SSL, so it is relatively safe here.
The data to be encrypted is for system use only, as the system needs to be
able to extract the information. Therefore, it will use the systems secret
key. I wanted to know if this could be a security risk, having your
database dependant on a single security key that is built into the system.
The only entity who can decrypt the data is the system.
Encryption is not a problem, the problem is in the storage of the primary
key... Where do I store such a sensitive piece of data. I don't want it
possible to have my system compromised by someone find the single system
secret.
I figured a smart-card or dongle would be a viable storage area for such a
key.
I can use a database environment like oracle. Has this got any built in
solutions?
Has anyone ever dealt with such a problem before?
Thanks,
Kevin
"Kevin Crosbie" <[EMAIL PROTECTED]> wrote in message
news:8liuob$[EMAIL PROTECTED]...
> Has anyone got any ideas on this:
>
> I need to secure data inside an oracle database. The data can be
> manipulated(encrypted) before entry, and can then be decrypted on access.
>
> Basically I don't want to need to store a secret key on the system that
> someone can get access to and see all of the sensitive data. I also need
> this to be quite fast.
>
> Every way I look, I see that there is a single system secret which will be
> the hole in the system.
>
> My system takes in requests which I must store, in encrypted form.
Hashing
> is useless, because I still need the data afterwards.
>
> Is a hardware solution the only real secure solution? or is there a
> protocol out there which would solve what I'm trying to do?
>
> Regards,
>
> Kevin
>
>
>
>
------------------------------
From: [EMAIL PROTECTED] (Larry Kilgallen)
Subject: Re: Database encryption
Date: 25 Jul 2000 14:07:46 -0500
In article <8lkga0$[EMAIL PROTECTED]>, "Kevin Crosbie"
<[EMAIL PROTECTED]> writes:
> Encryption is not a problem, the problem is in the storage of the primary
> key... Where do I store such a sensitive piece of data. I don't want it
> possible to have my system compromised by someone find the single system
> secret.
>
> I figured a smart-card or dongle would be a viable storage area for such a
> key.
Yes, hardware is required. Make sure description happens on the card,
so the key never leaves the card.
> I can use a database environment like oracle. Has this got any built in
> solutions?
Both Oracle Rdb and Legacy Oracle are software-only products,
so they cannot solve the key storage problem. Hardware is
required.
------------------------------
From: Dave Hazelwood <[EMAIL PROTECTED]>
Subject: Re: CD destruction
Date: Wed, 26 Jul 2000 01:16:41 +0800
What material are CD's made out of ? Polycyanate?
Whatever it is there must be a solvent for it.
MEK? TCE? Gasoline?
Get the solvent and dissolve the CD!
Once the plastic is gone the backing should be
easily disposed of with a small flame as it is
so thin or dissolve it as well in a bit of HCL.
[EMAIL PROTECTED] (Paul Rubin) wrote:
>In article <[EMAIL PROTECTED]>,
>Sundial Services <[EMAIL PROTECTED]> wrote:
>>Come to think of it, the way I'd destroy a CD-R or CD-RW disk is with a
>>buffing wheel or polishing wheel. If the NSA can reconstruct the data
>>in that little pile of green plastic dust on the floor of the workshop,
>>they can be my guest. So to speak.
>
>I tried that (wire wheel on CD-R). You don't get little pieces of
>dust. You get big slabs of mylar-like data layer with sharp edges to
>poke your fingers when you try to pick them up. It is a mess. I
>don't recommend it. Further, the pieces are big enough to read data
>from with a microscope. I'd expect about the same results from fine
>grained sandpaper since the data layer simply isn't held on that tight.
>If I have to destroy a CD-R again, I'll use a torch.
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Re: Proving continued possession of a file
Date: 25 Jul 2000 10:02:29 -0700
[EMAIL PROTECTED] (Mark Wooding) writes:
[snip]
> Efficiency tweak: modular inversions aren't ever-so cheap, so it's
> probably easier to take the summary S and compute S^r mod n and compare
> that. In fact, she can do this separately mod p and q again, and
> compare residues. Not to mention that Alice can do this while she's
> waiting for Bob's answer.
Good idea. Wish I'd thought of it...
It's still important that Bob not know Phi(n), or he'll be able to
solve for b and i after two exchanges of the protocol, and figure out
r on future exchanges.
> Each of the x_i must be smaller than n, otherwise Bob can reduce them
> mod n. I assume that b and i are large too. Assuming that \phi(n) is
> approximately the same size as n, the total length of the exponents is
> about the same size as the entire message x, only there's also some
> extra multiplications. Slightly larger, in fact, since Bob can't reduce
> b r + k i r mod \phi(n). I suspect, then, that this is actually more
> effort than simply computing g^x mod n (especially since keen Bobs can
> do serious precomputation on the exponent if they feel like it). Or
> have I misunderstood something?
But all of that can be computed as it is done. Bob only needs a few
accumulators. Let's say Alice sends bob b', i', and n. Bob can:
let response = 1
let exponent = b' + i'
while block = read_block_from_file_with_suitable_padding_if_needed()
let response = response * (block ^ exponent) mod n
let exponent = exponent + i'
end while
send alice response
For a given block size, varying file size:
Alice's memory needs are constant.
Alice's storage needs for summary information are constant.
Alice's work is constant.
Network bandwidth is constant.
Bob's RAM needs are constant.
Bob's work is linear.
I admit, the constants are large and the line is steep, but I think
it's easier for Bob than trying to exponentiate the entire file as one
big ole integer.
As for sizes, I figured I'd let that be implementation dependant ;-)
but I was envisioning something like n being 129 bytes and b, i, and
the block size being 128 bytes. The ultimate response would be 129
bytes.
> If m is small, we can be clever because Bob can use the simultaneous
> exponentiation trick described for ElGamal and DSA verification in HAC
> chapter 13; for large m this trick is a loser because it uses O(2^m)
> storage for precomputed values.
I'll have to check that out...
> (Oh, by the way, your definition of Gen reuses the variable n; I assume
> that this is actually a completely separate variable.)
Sorry about that. In Gen it is just a function parameter. The global
n is the product of p and q, large primes.
Andru
--
Andru Luvisi, Programmer/Analyst
------------------------------
From: stanislav shalunov <[EMAIL PROTECTED]>
Subject: Re: WinZip
Date: 25 Jul 2000 13:34:49 -0400
stanislav shalunov <[EMAIL PROTECTED]> writes:
> (ZedZ site is down at the moment, so you'll have to wait to get this...)
Sorry to follow-up to myself, but I've accidentally posted a
no-longer-working URL.
ZedZ is back up, the URL is actually
ftp://ftp.zedz.net/pub/crypto/cracking/pkzip.ps.gz
The tool apparently can be gotten off
ftp://ftp.zedz.net/pub/crypto/cracking/pkcrack-1.2.1.tar.gz
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: Rabin's information dispersal algorithm
Date: Tue, 25 Jul 2000 19:36:36 +0200
Looks like it is rather susceptible to active attacks, i.e. maliciously
modifying the contents.
Greetings!
Volker
--
The early bird gets the worm. If you want something else for
breakfast, get up later.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Rabin's information dispersal algorithm
Date: Tue, 25 Jul 2000 12:42:24 -0500
Wei Dai wrote:
> I'm not sure I understand your question. During recovery, you know
> which points are missing because the pieces they represent are not
> available to participate in the recovery. During generation, the
> coefficients are not explicitly determined, because it's faster to
> interpolate new values of the polynomial directly from its values at
> 0,...,n-1 rather than to compute the coefficients and then evaluate the
> polynomial at the new points using the coefficients. (Knuth's
> Seminumerical Algorithms has a nice discussion of the interpolation
> algorithms.) These two issues don't seem to be related, which is why
> I'm confused.
:-) No, obviously I'm the one confused. I usually use data points
to find the coefficients of polynomials. Since you don't need to
do that for this to work, I'll have to do some more homework. My
confusion comes from thinking in terms of continuous functions, which
isn't the case here.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Question.How to avoid weak curves?
Date: Tue, 25 Jul 2000 12:59:19 -0500
Sergio Arrojo wrote:
>
> Are any other conditions to be considered, apart from the MOV and Anomalous
> conditions (and the recently discovered of m not being a composite), for an
> elliptic curve in order not to be efficiently attacked (to show weaknesses)?
> Are there any further attack I should know about in order to prevent
> weaknesses in the chosen elliptic curve?
Your security goes as sqrt(point order) for all curves except Koblitz curves.
These can be attacked in sqrt((point order)/log m) where m is the field size.
So for 160 bit field size, your point order will be ~2^156, security ~2^78/13.
So you might want to go for 164 bits instead. I don't consider this much of
a "weakness", but you didn't mention it.
Patience, persistence, truth,
Dr. mike
------------------------------
Date: Tue, 25 Jul 2000 04:46:08 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Rabin's information dispersal algorithm
=====BEGIN PGP SIGNED MESSAGE=====
Wei Dai wrote:
> Here is an idea to make Rabin's information dispersal algorithm (IDA)
> more efficient, especially when the expected number of missing pieces
> is small. If it's already published somewhere, a reference would be
> greatly appreciated.
>
> IDA is a method of producing k pieces from a message such that any n of
> them can be used to recover the message. [...]
>
> The new method treats the message as the values of a degree n-1
> polynomial evaluated at points 0,...,n-1. The first n pieces are
> produced simply by cutting the message into n equal sized chunks. The
> other k-n pieces are produced by interpolating the polynomial at k-n
> other points.
Generally it's desirable for no information about the message to be
leaked if the attacker has less than n pieces, which is obviously not
the case for this method. However, that could still be achieved with the
same efficiency by applying an AONT to the message before splitting it.
Alternatively, create a temporary random "message" R of size 128*n bits,
split R as described above, and make public the real message encrypted
under hash(R). (This is not quite the same as an information dispersal
algorithm because of the extra public data, but it can be used for some
of the same applications.)
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOX0NVTkCAxeYt5gVAQFwvgf8DHhl7oE/hSI/lTUHoEyE7Ys9MJuQDt5U
tKo+OLke9dzN5USE/pbwz7ubuXTmAiucDRyVWiTezHHeW8pJjXYFPo1VhSGT3QSL
GQuQtGESJ0pkGWncrgPRxMjEwRXmc+Kf9WerOeImjYOZ+sWmxlz36jz35C1n0Jdx
wfweSTWdpsOAaYt6ONnWANU++OPHXpQvL5OnDdbLVCOdj7z2i4Jdv8aU8VbudeR0
a1VMp8KVPPiwqGAGlfl/d+YHvUQJZzFTgvsdxDWqJHUxAWke70ghm4gYjnz0VzM9
z3sZPpMuBRsSvc8/N5ELq3b3UzlfIXsKRWCeg4UNHAHw/u5UDPJ4ww==
=z0dN
=====END PGP SIGNATURE=====
------------------------------
Date: Tue, 25 Jul 2000 06:48:33 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Idea - quantum crypto + chaffing & winnowing
=====BEGIN PGP SIGNED MESSAGE=====
Benjamin Goldberg wrote:
> Each message from A to B could contain the following information:
>
> t = time-of-measured-keybit
> i = bit-index-of-file
> d = direction {45deg, 90deg, left-circular, right-circular}
> c = keybit XOR databit
>
> Message-packet = t || i || HMAC( d || c || t || i )
[...]
> Does this idea make any sense, or is it completely useless?
I'm not sure what this gains you over Chaffing and Winnowing on
a bit-by-bit basis over a conventional channel - both have security
provably dependent only on the unforgeability of the MAC.
[The repeated "signature virus" is just annoying, BTW.]
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOX0qIjkCAxeYt5gVAQEkcQf/RBLGxuTTNI40U8cWzgL2cXZIQ7/pH2ov
B3C2dLbyrq90Y2kj1tKLaH1x4j27EzZYWiAyyBF0OEzMXZsTHmRjBQ4cyTKEYRue
PB3X1FgGBmlSk0hI1IcEwf41LL4FyTuIdoc1OtMKDdwIZ5B1fo3hGSmsXAM2Pwqq
fujdo7jwqgJXnwmTjcFSpag0sl4RJmh+SosyprUOIYns0DkqtLTrlDrfVo7Qw5YX
33AE9VqYXqh1scew8t+HnNSaIXUqQhjsAdXxebNEKPvld4DZo7p59mugwwBnk7Vy
3UNWhQQPo7xcjayX3ya4a2OUIYZIIYiTV/JjUjZZFmZGFgZ2mnCbpA==
=+9Um
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (James Pate Williams, Jr.)
Subject: Re: School question for you regulars.
Date: Tue, 25 Jul 2000 19:50:37 GMT
On Tue, 25 Jul 2000 03:24:12 -0400, "Trevor L. Jackson, III"
<[EMAIL PROTECTED]> wrote:
>The Gorf wrote:
>
>> I hope this is acceptable to post, but if I offend I apologize in advance.
>> I am eager to start my Coolege career but am unsure of what direction to go.
>> I am very interested in Computer Science, but I fear that while I will build
>> strong programming skills, I might not gain the solid math I want. On the
>> other hand if I go Mathemtaics I may lose programming skills
.
>Schools are _much_ better at teaching mathematics than they are at teaching
>programming skills. Thus majoring in math is quite likely to give you a
>reasonable grounding in mathematics. Majoring in CS is unlikely to give you a
>reasonable grounding in programming skills.
>
>Note that programming skills are not the same as computer science.
>
If not in a computer science cirriculum, where the heck do people
learn programming skills? Do you expect technical schools or on the
job training to be used to teach programming skills? Software
engineering is a science not a black art passed down by practitioners
to apprentices. Most techical school computer programming graduates
have very limited knowledge of modern software engineering practices.
==Pate Williams==
[EMAIL PROTECTED]
http://www.mindspring.com
------------------------------
From: Steve Weis <[EMAIL PROTECTED]>
Subject: Incremental Hashing
Date: Tue, 25 Jul 2000 12:42:48 -0700
I am curious about implementations of incremental hash functions.
Specifically, Bellare & Miccianchio's AdHash function*. What would
be an appropriate choice for an underlying hash function? It is defined
as being "assumed ideal" and chosen randomly. Would any universal hash
function suffice? Any references or examples of implementation would be
appreciated.
* - Reference:
"A New Paradigm for Collision-free Hashing: Incrementality at Reduced
Cost", Advances in Cryptology - Eurocrypt '97 Proceedings, LNCS V.1233
------------------------------
From: "The Gorf" <[EMAIL PROTECTED]>
Subject: Re: School question for you regulars.
Date: Tue, 25 Jul 2000 12:57:38 -0700
I have found that to be pretty consistent. But when I said "programming
skills" I more accurately should have said knowledge. Computer Science is
an ideal major for learning different programming languages, and the
fundamentals of good software engineering. I agree that the refinement will
come from on the job. As it is, I believe that my best bet is Mathematics
at the University of Washington, with a alot of side concentration in
computer science. That way I will get very solid (and advanced later with a
Masters) math knowledge, while getting the programming languages that I will
need to use. Thanks for all the input guys.
Geoff
"James Pate Williams, Jr." <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Tue, 25 Jul 2000 03:24:12 -0400, "Trevor L. Jackson, III"
> <[EMAIL PROTECTED]> wrote:
>
> >The Gorf wrote:
> >
> >> I hope this is acceptable to post, but if I offend I apologize in
advance.
> >> I am eager to start my Coolege career but am unsure of what direction
to go.
> >> I am very interested in Computer Science, but I fear that while I will
build
> >> strong programming skills, I might not gain the solid math I want. On
the
> >> other hand if I go Mathemtaics I may lose programming skills
> .
> >Schools are _much_ better at teaching mathematics than they are at
teaching
> >programming skills. Thus majoring in math is quite likely to give you a
> >reasonable grounding in mathematics. Majoring in CS is unlikely to give
you a
> >reasonable grounding in programming skills.
> >
> >Note that programming skills are not the same as computer science.
> >
> If not in a computer science cirriculum, where the heck do people
> learn programming skills? Do you expect technical schools or on the
> job training to be used to teach programming skills? Software
> engineering is a science not a black art passed down by practitioners
> to apprentices. Most techical school computer programming graduates
> have very limited knowledge of modern software engineering practices.
>
> ==Pate Williams==
> [EMAIL PROTECTED]
> http://www.mindspring.com
------------------------------
** 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
******************************
