Cryptography-Digest Digest #818, Volume #10 Sat, 1 Jan 00 16:13:01 EST
Contents:
Re: HD encryption passphrase cracked! (Lincoln Yeoh)
Wagner et Al. (Tom St Denis)
Re: Hash algorithms (MD5 vs SHA1/RIPEMD-160) ("Thomas J. Boschloo")
Re: Adobe Acrobat File Encryption...AAARGH!! (Kyler Laird)
Re: The Cipher Challenge from the Code Book (wtshaw)
Re: Encryption: Do Not Be Complacent (James Redfern)
Re: File format for CipheSaber-2? (Paul Crowley)
Re: File format for CipheSaber-2? (Paul Crowley)
cracking Triple DES ("P. Daniel Suberviola, II")
vigenere decrypt routine - help needed (Mike Todd)
Re: meet-in-the-middle attack for triple DES (Scott Fluhrer)
Re: how good is RC4? (David Hopwood)
Re: Secure Delete Not Smart (ghq)
Re: stupid question (No Spam)
Re: More idiot "security problems" (Xcott Craver)
Re: Secure Delete Not Smart (Guy Macon)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Crossposted-To: misc.misc
Subject: Re: HD encryption passphrase cracked!
Date: Sat, 01 Jan 2000 08:43:35 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 27 Dec 1999 12:07:24 -0800, Matthew Montchalin
<[EMAIL PROTECTED]> wrote:
>Have you ever opened up your hard drive and pulled out the magnetic
>medium with a pair of tweezers? Sure, they say that microscopic
>particles of dirt get into the hard drive, substantially compromising the
>storage capabilities, but if you really wanted to eradicate every last
>trace of the data, and yet still be able to use the medium (that is the
>important part), you can swipe a kitchen magnetic over and around and
>around the medium before replacing it again. Of course, after doing
What's the point? After opening up the drive you can't rely on the drive.
If you are going to do that, you might as well blowtorch the entire drive
and buy a new one. Drives are cheap nowadays.
Cheerio,
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Wagner et Al.
Date: Sat, 01 Jan 2000 13:34:52 GMT
Happy new year and all,
Anyways to my point. Can someone please take sometime to peek at
Peekboo. I would love to see some cryptanalysis/suggestions/etc from
the 'pros'. Please and thank you :)
http://peekboo.dasoft.org
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: Hash algorithms (MD5 vs SHA1/RIPEMD-160)
Date: Sat, 01 Jan 2000 14:59:35 +0100
[X-posted to sci.crypt for an expert opinion on the security of MD5]
adam wrote:
>
> The document says RSA keys use the MD5 hash algorithm to generate the
> message digest that is used to make a signature.
>
> On the other hand, DH and DSS keys use the SHA1 or RIPEMD-160
> algorithm.
>
> The RSA algorithm is only used to generate the public/private key
> pair, encrypt, and decrypt (both signatures, and message
> encrypt/decrypt). The hash algorithms are only used to generate the
> message digest (hash), right? So, is the MD5 (or SHA1/RIPEMD-160)
> hash algorithm separate? Or, are they intertwined in the code.
The MD5 hash is also used to hash the passphrase when using conventional
encryption or passphraseprotecting your secret key. So if there are a
lot of collitions, your 128 bit phrase might only be worth e.g. 64 bit
due to the hashing, which would be crackable by large organizations and
intelligence agencies, but I don't think the loss of strenght would be
anywhere near that bad. Only a tiny bit worse, right?
Thomas
--
Boycot Intel Pentium III <http://www.bigbrotherinside.com/>
PGP key: http://x11.dejanews.com/getdoc.xp?AN=453727376
Email: boschloo_at_multiweb_dot_nl
------------------------------
From: [EMAIL PROTECTED] (Kyler Laird)
Subject: Re: Adobe Acrobat File Encryption...AAARGH!!
Date: 1 Jan 2000 15:05:14 GMT
>On Sun, 26 Dec 1999 13:09:42 -0000, "Piff" <[EMAIL PROTECTED]> wrote:
>>I've spent the last two weeks trying to find more information on the
>>encryption method used by Adobe Acrobat but can't seem to find anything.
Amazing. How could you *not* find information? I'd
have a terribly difficult time coming up with a
reasonable query that doesn't pick up any of the
many PDF resources in Usenet and on the Web.
Anyway...
At the bottom of
http://www.ecn.purdue.edu/~laird/PDF/
is a link to the most significant source,
http://partners.adobe.com/asn/developer/acrosdk/docs.html
In particular,
http://partners.adobe.com/asn/developer/acrosdk/DOCS/pdfspec.pdf
sections 5.18 (page 62) and 6.13 (page 124).
--kyler
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: The Cipher Challenge from the Code Book
Date: Sat, 01 Jan 2000 09:45:57 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (wtshaw) wrote:
> In article <84hmf1$ema$[EMAIL PROTECTED]>, "Chris Williams"
> <[EMAIL PROTECTED]> wrote:
>
> > You may wish to visit http://www.onelist.com/community/CipherChallenge for
> > some hints.
> >
> > > my main question is, what does "Monoalphabetic Cipher with Homophones"
> > > mean? is it Homophonic substitution (p52)? if it is, why is the example
> > > of the book numerical, and why when put through frequency analycist Q
> > > has 18.4%?
> >
> > It is, just using letters and the asterisk instead of numbers. One cipher
> > letter is very frequent, perhaps it is not a plain letter at all!
>
> Technically, a series of digits could be replaced one-for-one with a
> monoalphabet of any ten characters, even just digits. When people say
> alphabet they usually mean only one thing, a character set of 26, or so,
> letters. But, monoalphabetic substitution can be done with any sized
> character set, even digits or any other base. The idea you have a
> question about seems to be a poor choice of words to describe a cipher,
> misleading, ambiguous, and characteristic of the less than clearly defined
> way lots of things are done.
>
> Determinative homophonic substitution may indicate more than one character
> set is in play. If you say monoalphabetic, what does that mean if two
> sized character sets are in use? Which one? Internal states to a cipher
> do matter, so just a different length in one set, as can be done, seen or
> unseen, is misleading.
>
> Monoalphabetic substitution suggests no change in length or difference in
> plaintext and cipher text sets, as the could be different, is used, and
> that each plaintext character of a given type is going to be replace in
> the same position by one ciphertext character according to one simple
> list; anything else isn't.
In the past I have pointed out that merely staggered alphabets are not the
same as unrelated alphabets in a polyalphabetic substitution scheme. The
staggered alphabets in the classic homophonic cipher also qualify. For
the those that qualify such categories, a staggered alphabet might be
called monoalphabetic and polyalphabetic at the same time. This is
probably OK as long as the word substitution is left out, since
monoalphabetic substitution and polyalphabetic substitution are mutually
exclusive primatives.
When a staggered alphabet is used, something on the order of a separate
primative could be defined. If you like fuzzy logic, then you are not
feeling warm about this notion.
--
Only a little over a year left to go in this centrury....
Knowing this, figure that a year from now, we will
resale of the hoopla we are getting ready to see now.
------------------------------
From: James Redfern <[EMAIL PROTECTED]>
Subject: Re: Encryption: Do Not Be Complacent
Date: Sat, 01 Jan 2000 15:27:42 +0000
Reply-To: redfern<AT>privacyx<DOT>com
On 31 Dec 1999 17:13:36 EST, [EMAIL PROTECTED] (Guy Macon) wrote:
| "So I'm all like, you know and then he's like totally DUH and i'm like,
| you know NOT a he gets SO two weeks ago so now I'M all duh, and he
| spazes like totally but still kinda tubular, you know?"
ROFLMFSO!
JR.
--
James Redfern <[EMAIL PROTECTED]> The Redfern Organization
PGP key ID 0x8244C43A from <mailto:[EMAIL PROTECTED]?subject=0x8244C43A>
...ActiveNames delivers my undeliverable mail at <www.ActiveNames.com>
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: File format for CipheSaber-2?
Date: 1 Jan 2000 13:23:59 -0000
[EMAIL PROTECTED] (Guy Macon) writes:
> Actually, I have two problems with including known plaintext.
> The first is an argument from ignorance - I have no way of knowing
> how much this weakens CS. I lack the expertise. The second is that
> your proposed magic sequence could occur in a plaintext, or in an
> improperly decoded (wrong key or repeat number) result. At first I
> thought that this would be very unlikely (1 out ot 2^80 bit patterns),
> but I have no idea whether or not all of those 2^80 patterns are
> equally probable when I try different repeat values or keys.
I know RC4 pretty well, and I'm pretty sure neither of these are problems.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: File format for CipheSaber-2?
Date: 1 Jan 2000 13:27:01 -0000
[EMAIL PROTECTED] (Guy Macon) writes:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul
>Crowley) wrote:
>
> >So what I meant to specify was that CipherSaber-3 mandate that at
> >least 256 bytes of output be discarded, to avoid Andrew Roos' weak key
> >problems.
>
> I can see the advantage to that. Wouldn't it be just as effective
> to place 256 bytes of random bytes at the start of the plaintext
> and discard them when decoding?
That pads the ciphertext out with 256 unnecessary bytes, though.
Remember that RC4's keystream generation is independent of the
plaintext.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: "P. Daniel Suberviola, II" <[EMAIL PROTECTED]>
Subject: cracking Triple DES
Date: Sat, 1 Jan 2000 12:09:24 -0600
Hello.
How would a meet-in-the-middle attack against three-key triple DES work?
Schneier asserts that there is one on page 360 of the second edition of
Applied Cryptography. I do not have access to the Merkle and Hellman
reference.
Thanks much.
--Dan Suberviola
------------------------------
From: Mike Todd <[EMAIL PROTECTED]>
Subject: vigenere decrypt routine - help needed
Date: Sat, 01 Jan 2000 17:44:37 +0000
hi,
I`m trying to write a vigenere-polyalphabetic decrypt routine in Java,
but I`m having bother getting the probable length of the key. If anyone
knows/has a routine to decrypt the vigenere that I could refer to I`d be
grateful.
thanks
Mike
------------------------------
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: meet-in-the-middle attack for triple DES
Date: Sat, 01 Jan 2000 18:57:15 GMT
In article <386d279e$0$[EMAIL PROTECTED]>,
"P. Daniel Suberviola, II" <[EMAIL PROTECTED]> wrote:
>Hello, everyone.
>
>I am a high school senior working on an independent DES project. I posted
>here last week, so some of you may have seen my earlier post. I have been
>reading Bruce Schneier's _Applied Cryptography_ and am having difficulty
>understanding his explanations of cryptanalysis. Specifically, I do not
>understand how a meet-in-the-middle attack works for triple DES.
>
>According to Schneier,
>
>C = EK3(DK2(EK1(P))) and P = DK1(EK2(DK3(C))).
>
>That part makes sense. However, he claims that there is a meet-in-the-middle
>attack to break this. Could someone please briefly explain to me how this
>would be done?
Simple. Rewrite the equations like so:
DK3(C) = DK2(EK1(P))
Compute the decryption of the known C with all possible K3's, and put them
into a (2**56 size) list.
Then, go through all possible K2,K1 pairs, and compute DK2(EK1(P)). Search
to see if that value appears in the list. If it does, use that K1,K2,K3
triplet to decrypt some more ciphertext. If that works, you just found it.
Time taken = O(2**56) -- to compute the DK3(C) list
+ O(2**127) -- expected time to go through the K1,K2 until we
find the right one.
Searching through the list can be made practical by sorting the list first
and then searching with several DK2(DK1(P)) values at once. You also
probably want to make the C,P two blocks, to reduce the number of false
hits to a managable number.
>
>Further, I have a more general question regarding the meet-in-the-middle
>attack described for triple encryption using only two keys.
>
>On page 358, according to Schneier,
>
>"In this attack, the cryptanalyst knows P1, C1, P2, C2, such that C1 =
>EK2(DK1(P1)) and C2 = EK2(DK1(P2))."
>
>This is wonderful, but how would it help in the real world? It seems to me
>like circular logic; if you already know the plaintext and ciphertext, what
>good is it to know the keys?
Maybe you have a couple blocks of the message (say, a known header), but
don't know the rest of it. Or, several messages were sent using the same
key, and you have (or guess) the plaintext for one of them.
> Further, how would this help you in real life
>over a brute-force attack, since when you really need to break something you
>will know absolutely nothing except for the ciphertext and the keys are sure
>to be different?
In real life, the attacker often does have knowledge beyond the ciphertext.
In fact, he *must* have additional knowledge -- if he is unable to recognize
the correct plaintext, even a brute-force attack does not work.
--
poncho
------------------------------
Date: Sat, 01 Jan 2000 18:15:19 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: how good is RC4?
=====BEGIN PGP SIGNED MESSAGE=====
Tom St Denis wrote:
>
> In article <[EMAIL PROTECTED]>,
> fungus <[EMAIL PROTECTED]> wrote:
> > RC4(tm) is really good, but has a couple of problems:
>
> RC4 is not a trademark.
RC4 *is* a trademark (as are RC2, RC5, RC6, MD2, MD4, MD5, DESX,
CAST-128, IDEA, and several other algorithms for which there's really
no need to write "(tm)", at least on Usenet).
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOG5EHDkCAxeYt5gVAQG85wgAtb9KAAHeylnlnVlT5WpXPc3k2Pch+IfS
4puBsaQBEkSD59OHruBi6QeDb7jEP11xSl18vMkQoB365F1SZXfCY6EQ75sPAih0
3MQBPGX20q0DTaQyp8XYyaheInH6m+hf5/RAjpRCzt9Qn+EwYDcabSnDmz72L2nQ
64SBzyQEFwne7Aii8Dmro9FO6X1hCoF5WXdeq16IMEeMatufcmQ6Aji/pwS9aWH1
TaQWCj8Dm34dIpERv1v42S9xtnsKZlj+qTBmhNdGfHWFlAHvRP/t8mq4EWu70j3O
1fs9MEMUUNYaifdfRNvQ8tl3dpG8KHKbxZ2ZSNcbZTYiv4aZvGNmeA==
=xr9T
=====END PGP SIGNATURE=====
------------------------------
From: ghq <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: Secure Delete Not Smart
Date: Sat, 01 Jan 2000 13:55:17 -0500
On Wed, 29 Dec 1999 15:52:53 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>
>
>Mark D wrote:
>
>> Guy Macon wrote:
>> >
>> > In article <84b21n$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Frank
>Gifford) wrote:
>> >
>> > >All this stuff about overwriting files assumes that the drive is working
>> > >properly. Suppose that after you had put your top secret formula for
>> > >Coca-Cola on your hard drive, it started to go bad. The read/write head,
>> > >being a physical device, starts to drift away from the proper track and now
>> > >it is a little more to the outside than it used to be. Now when you write
>> > >data, it's writing a little towards one side of the track, but the other
>> > >side of the track still contains your Coca-Cola formula.
>> >
>> > Minor correction; modern drives do not depend on mechanical tolerances.
>> > They servo to the center of the track. Everything else you said is 100%
>> > correct, because servos can go bad and be off to one side of the track.
>>
>> So here's your solution: burn all your information to cd, and if you
>> want to 'secure delete' it, you just smash the cd. Since they're only
>> about a buck a piece, it would be fairly inexpensive.
>
>And fruitless. Recovering a smashed CD would be no trouble given the right optical
>equipment.
>
>It might be better to "reburn" the CD several times with data that forced every bit
>into the
>burned state. This may be a research topic for a paper equivalent to the one
>analyzing
>megnetic media and semiconductor RAM.
how about just encrypting the data on the cd in the first place
------------------------------
From: No Spam <[EMAIL PROTECTED]>
Subject: Re: stupid question
Date: Sat, 01 Jan 2000 15:48:16 -0500
Reply-To: [EMAIL PROTECTED]
Joseph Ashwood wrote:
>
> > I have a stupid question. But what is the difference between a key of a
> > stream cipher and a key of an one-time-pad ???
> The basic difference is where in the process they are used.
> The basic algorithm is:
>
> data--|
> |
> RNG------Cipher-----output
>
> The difference is where the key is used. In the case of a one time pad the
> key replaces the RNG (the RNG having been run prior, and being a true Random
> Number Generator). In a stream cipher the key is used as a seed to a
> _pseudo_ Random Number Generator (called a pseudo RNG because it does not
> generate truly random numbers). That is the current typical usage, a while
> back there was actually some discussion about what constitues a stream
> cipher and what constitutes a block cipher, and I can extend it to include
> OTP easily. My personal opinion is that a stream cipher function has as it's
> inputs data, key, and the previous data (although the effect of the previous
> data is often limited to the length), a block cipher inputs only data and
> key, an OTP is simply a block cipher where the key is exactly as long as the
> data (we have actually discussed some other issues here but that's the
> basics).
> Joseph
Joseph,
I too have a stupid question I hope you will answer for me.
It seems that most of the postings in this news group view the use of
PRNG in encryption as very poor.
If create a key pass phrase: "ABCDEGGH" and use the first three, two
byte pairs (AB, CD, and EF) as 16 bit seeds for a PRNG.
Taking the ouput streams fron the PRNG for each of the three seeds, and
XORing the output into a 10K buffer. So the PRNG's output was XORed
into the 10k buffer three times.. each with a different seed (AB, CD,
EF).
Then I take the last key pair GH, seed the PRNG and use the PRNG to pick
the bytes from the 10K buffer to use as a streaming encryption XOR .
Is there any attack that can be used to break the code other than a
brute force key phrase attack?
If a large amount of the plain text was know.. say 100K of a 100,100
byte message, is there an attack the will decrypt the last 100 bytes?
Green in New Hampshire
Reply2 [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Subject: Re: More idiot "security problems"
Date: 1 Jan 2000 20:37:17 GMT
Dan Day <[EMAIL PROTECTED]> wrote:
>On 17 Dec 1999 19:24:47 GMT, [EMAIL PROTECTED] (Xcott Craver) wrote:
>> Well-spotted! Now, can we think of a character who embodies
>> all four properties?
>
>Lucy Ricardo? (That's Lucille Ball in "I Love Lucy")
>
>Gilligan?
>
I got it!!
Daffy Duck.
-Scott
[Not the "hoo-hoo! hoo-hoo!" Daffy Duck, but the "on account
of _I_ am greedy" Daffy Duck.]
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: alt.privacy
Subject: Re: Secure Delete Not Smart
Date: 01 Jan 2000 15:59:45 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (ghq) wrote:
>
>On Wed, 29 Dec 1999 15:52:53 -0500, "Trevor Jackson, III"
><[EMAIL PROTECTED]> wrote:
>>It might be better to "reburn" the CD several times with data that forced every bit
>into the
>>burned state. This may be a research topic for a paper equivalent to the one
>analyzing
>>megnetic media and semiconductor RAM.
>
>how about just encrypting the data on the cd in the first place
>
Think about this for a moment. Imagine yourself encrypting
an important message. The chances are pretty good that you
are not willing to type your message right into your encryption
software (although in high security environments you might!).
You usually have some plaintext somewhere on your computer
that you wish to encrypt. Fine. You encrypt it. What about
the original plaintext? O.K. You delete it. Oops! There are
undelete programs. Great. You overwrite it. Uh-uh. It is
possible to recover overwritten files. I could go on, but the
end conclusion is that being able to destroy data is an important
part of a complete security policy. The best crypto in the world
will not help you if someone gets the data from your hard disk,
gets a copy of your plaintext out of your garbage, reads what is
on your screen or what your printer is printing with radio
eavesdropping, gets the info from yourvswap file, plants a bug
in your keyboard or phone, etc. Destroying the plaintext is an
important part of any practical crypto system. Depending on
the threat, much more may be needed.
------------------------------
** 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
******************************
