Cryptography-Digest Digest #912, Volume #10 Sat, 15 Jan 00 23:13:01 EST
Contents:
Security, Privacy, and Encryption (wtshaw)
Re: Weakened cryptosystems (JPeschel)
Re: New Crypto Regulations (JPeschel)
Re: anyone heard of DDEZI encryption? (HeuyWorld)
Re: RANT New Crypto Regulations (Guy Macon)
Re: Cracking DES (Paul Schlyter)
Amateur Stream Cipher Algo (Peter Raddatz)
DDEZI samples before/after --- ?supposedly? (HeuyWorld)
Re: Forward secrecy for public key encryption (lcs Mixmaster Remailer)
Re: Cracking DES ([EMAIL PROTECTED])
Re: Forward secrecy for public key encryption (David Wagner)
Re: Cracking DES (fvw)
Re: Cracking DES (JPeschel)
Re: HD encryption passphrase cracked! ("Douglas A. Gwyn")
Re: Cracking DES ("Douglas A. Gwyn")
Re: LSFR ("Douglas A. Gwyn")
Re: AES & satellite example ("Trevor Jackson, III")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: alt.privacy,alt.security,talk.politics.crypto
Subject: Security, Privacy, and Encryption
Date: Sat, 15 Jan 2000 17:34:47 -0600
I have had some requests for the slides I used in a presentation in
October in Security, Privacy, and Encryption. They represent at worst an
outline, but not the witty ;) commentary that accompanied them.
The slides are in low color, GIF format:
http://www.radiofreetexas.com/wts/spe/
--
To prevent the comprimise of with the most common configuration
of computers is something like preventing a sculptor from being too original. If a
computer design is corruptable, it will be.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Weakened cryptosystems
Date: 15 Jan 2000 23:22:32 GMT
[EMAIL PROTECTED] (mnemo) writes:
>I'm learning the basics of cryptoanalyzing, mostly by studying normal
>books and documents available through the web. Many sources indicates
>that the best way to learn is to get right to it and start analyzing
>weakened cipher-texts. My problem is that I dont know where to find
>these 'weakened ciphertexts', I need, for example, to get a hold of:
>
> 8-round RC5 without any rotations.
> 8-round RC5 with the rotation equal to the round number.
>12-round DES without any s-boxes.
> 8-rounds of Skipjack's rule B.
> 4-round DES
> 6-round DES
> 4-rounds of Skipjack's rule A,
> followed by 4-rounds of Skipjack's rule B
I think you should be able to find the C source code for most
of these ciphers (in full strength) on the net. After finding
the source you should be able to play with, make the
appropriate changes, and compile it.
Aslo, I think James Pate Williams has some code of weakened
DES, with a known-plaintext attack incorporated. Could
be useful. He often posts here, and he might repsond with
his e-mail address.
Good luck.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: New Crypto Regulations
Date: 15 Jan 2000 23:26:33 GMT
Douglas A. Gwyn" [EMAIL PROTECTED] writes:
>Too bad we don't have any great leaders these days.
We do, but we also have too many great whiners.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (HeuyWorld)
Subject: Re: anyone heard of DDEZI encryption?
Date: 15 Jan 2000 23:27:44 GMT
>
>HeuyWorld wrote:
>> supposedly produces text output where each byte displayed as 0 thru
>> 9, represents between 28 and 51 characters with the majority being
>> displayed as 0 thru 5. ?the final output can also be 'spun' in
>> simulated-geometric patterns
>
>I think someone was pulling your leg.
>
>
Why?? could this NOT be able to be produced? ..
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: alt.dev.null
Subject: Re: RANT New Crypto Regulations
Date: 15 Jan 2000 18:33:59 EST
>but what's all this got to do with crypto?
(I will not read or respond to replies to this. It's in my killfile)
Good question, but adding an argument concerning <deleted>
makes you part of the problem. I advise limiting any replies
to this off-topic subject to comments about topicality only,
with followups set, and a limit of one per person.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Cracking DES
Date: 16 Jan 2000 00:24:26 +0100
In article <85qpb6$9l2$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> There is talk of cracking triple DES. All I want to know is how to
> crack single DES (I thought it hadn't been done til not that long ago),
> I've only got a small computer and not much codetext.
The only known way to crack single DES is by brute force: if you have
one cleartext-cryptotext pair, try all possible keys until you
encounter the correct key. On custom built hardware, which is quite
expensive, this can be acheived in a few days. On a normal small
computer, it would take more than a lifetime.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Peter Raddatz <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Amateur Stream Cipher Algo
Date: Sun, 16 Jan 2000 00:22:54 GMT
A while ago I invited people on this NG to test out my Stream Cipher
algo in a program that I wrote, but nobody nibbled. So what can a rank
amateur come up with? Ok, here is the crux of my algo. (PR2 Cipher)
1) zip the plaintext file
2) read in 16k at a time and perform all operations on that buffer
a) create a 1k array from the supplied password - pwKey(1k)
b) generate a 1k array - mixture of Rnd XOR pwKey() - Key(1k)
c) generate a 16k array - mixture of Rnd XOR Key() - sbox(16k)
d) generate a 16k MixArray - #0-->#16383 - mbox(16k)
all arrays are mixed around in ARC4 fashion...
k=(k+Key(x)+pwKey(x))mod 1024 (or mod 16383)
mbox() looks something like this...
5843, 11384, 2117, 47, 13859, 8462...
ptxt = 16k PlainText
sl = 16k ByteArray holding ASCII vals of ptxt
sn = cipher ByteArray
l=len(ptxt)
--- ENCRYPT ---
Sub Encrypt(ptxt)
k = Key(427) 'or something
for x=0 to l
i=x mod 1024
k=(k+mbox(x))mod l+1
j=(j+k)mod 1024
sn(x)=(sl(mbox(x))+((sbox(k)+sbox(x)) XOR Key(i) + (pwKey(i%)+pwKey(j))
XOR Key(j)) AND HFF) AND HFF
swap pwKey(i), pwKey(j)
swap sbox(x), sbox(k), sbox(j)
next
for x = 0 to 1024
Key(x)=Key(x) XOR pwKey(x)
next
k=Key(125) 'or something
for x=k+1 to l
swap mbox(x), mbox(x-k)
next
End Sub
Decryption follows similar lines.
Because of the mbox rearranging the BYTES from the ptxt it does not
matter which ZIPPER was used to compress the PlainText because the
header IS NOT in the first couple of positions.
All arrays are constantly mixed so that no 2 16k buffers are encrypted
alike.
In my view this seems fairly solid, that is why I wanted you guys and
gals to give it the once-over. Although written in VBasic 6.0 it is not
too slow. I manage 6.6 Megs in ~9 secs on my 300 including compression.
If you are interested in giving PR2 a workout please e-mail me.
Thx... Peter Rabbit
------------------------------
From: [EMAIL PROTECTED] (HeuyWorld)
Subject: DDEZI samples before/after --- ?supposedly?
Date: 16 Jan 2000 01:12:21 GMT
hey,
previous Q was if DDEZI was known/possible .. below examples are supposed
before/after examples ... anyone ever see stuff like this b4? i found on server
in late '96.... .. read ''after:'' with hex-editor ... pretty strange stuff
... :|
before:
"It never rains in southern california, but when it rains it washes away the
poor." -MrMixit, 08-Jun-96
after:
------------------------------
Date: 16 Jan 2000 02:00:01 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: Forward secrecy for public key encryption
David Hopwood writes, regarding forward secrecy for public key
encryption:
> I'm considering two basic approaches: describing a forward-secure
> encryption scheme directly, or constructing one from an identity-
> based public key encryption (or key pre-distribution) scheme.
The latter idea was proposed by Adam Back on the Cypherpunks list on
May 31, 1998:
http://www.inet-one.com/cypherpunks/dir.1998.05.25-1998.05.31/msg00171.html
The ensuing discussion did not seem very promising, though. It was hard
to find a scheme where the key holder had a significant edge.
He needs to be able to compute discrete logs efficiently while making
sure that an attacker who may have vastly greater resources could not
factor the modulus or compute discrete logs.
See the thread at
http://www.inet-one.com/cypherpunks/dir.1998.06.01-1998.06.07/index.html
under the topic "Re: non-interactive forward secrecy / identity based
crypto".
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cracking DES
Date: Sun, 16 Jan 2000 02:44:37 GMT
> The only known way to crack single DES is by brute force: if you have
> one cleartext-cryptotext pair, try all possible keys until you
> encounter the correct key.
Maybe a silly question:
How do we know what the right key is by non-cleartext-cryptotext?
If we think a right key has been found, maybe there is another
possible key with another possible solution.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Forward secrecy for public key encryption
Date: 15 Jan 2000 18:39:25 -0800
In article <[EMAIL PROTECTED]>,
lcs Mixmaster Remailer <[EMAIL PROTECTED]> wrote:
> The latter idea was proposed by Adam Back on the Cypherpunks list on
> May 31, 1998:
> http://www.inet-one.com/cypherpunks/dir.1998.05.25-1998.05.31/msg00171.html
>
> The ensuing discussion did not seem very promising, though. It was hard
> to find a scheme where the key holder had a significant edge.
>
> He needs to be able to compute discrete logs efficiently while making
> sure that an attacker who may have vastly greater resources could not
> factor the modulus or compute discrete logs.
Here is an idea for an improvement which I didn't see on cypherpunks.
Adam's original scheme exploits the gap in complexity between factoring
n=pq and taking discrete logs mod p,q. The problem is that there's
not a big enough gap between the two: we'd like to use a 1024-bit n for
adequate security, but then taking discrete logs mod 512-bit primes is
too hard for routine use.
But what if we choose n as the product of, say, four primes, n=pqrs?
I *think* that known factoring algorithms aren't any better at factoring
product-of-four-prime composites than they are at factoring RSA-composites
of the same size. If I got that right, we'd only need to do discrete
logs mod 256-bit primes to use a 1024-bit n, and that sounds a little
more realistic.
Can any of our resident factoring experts confirm or refute this?
Just how far can we push this before we start running into trouble?
------------------------------
From: [EMAIL PROTECTED] (fvw)
Subject: Re: Cracking DES
Reply-To: [EMAIL PROTECTED]
Date: Sun, 16 Jan 2000 03:07:44 GMT
In <85rbaj$ll1$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
>> The only known way to crack single DES is by brute force: if you have
>> one cleartext-cryptotext pair, try all possible keys until you
>> encounter the correct key.
>
>Maybe a silly question:
>How do we know what the right key is by non-cleartext-cryptotext?
>If we think a right key has been found, maybe there is another
>possible key with another possible solution.
Ehm, the post says: A cleartext-cryptotext *PAIR*. That is, you have both...
Without that, your either have to going to run some algorithm on the produced
plaintext to see if it could be valid plaintext, or know about some checksum
in the plaintext...
--
Frank v Waveren
[EMAIL PROTECTED]
ICQ# 10074100
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Cracking DES
Date: 16 Jan 2000 03:24:56 GMT
[EMAIL PROTECTED] (Paul Schlyter) writes:
>The only known way to crack single DES is by brute force: if you have
>one cleartext-cryptotext pair, try all possible keys until you
>encounter the correct key.
It's not always necessary for an attacker to possess one cleartext-cryptotext
pair.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: misc.misc
Subject: Re: HD encryption passphrase cracked!
Date: Sun, 16 Jan 2000 03:45:26 GMT
[EMAIL PROTECTED] wrote:
> -Why not simply overwrite all sectors of your HD ?!
Because that doesn't remove all traces of the previous data.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Cracking DES
Date: Sun, 16 Jan 2000 03:49:19 GMT
[EMAIL PROTECTED] wrote:
> If we think a right key has been found, maybe there is another
> possible key with another possible solution.
Compute the odds of that happening.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: LSFR
Date: Sun, 16 Jan 2000 03:53:48 GMT
Marty wrote:
> A fairly easy approach that keeps the logic fairly simple is to use a
> group of LSFR's that have relatively prime periods and are short
> enough to have reasonable sized lookup tables. Just clock them
> in parallel. Knuth, Vol 2 gives an algoritm for reconstructing the
> original count in the section on modular arithmetic.
As far as that goes, you could run a bunch of rings each of which
circulates a single "1" bit one position per tick. If the rings
have relatively prime sizes, and sampling determines where the
"1" bit is in each ring, the CRT will tell you how many ticks
since the previous sample.
------------------------------
Date: Sat, 15 Jan 2000 23:10:18 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: AES & satellite example
==============E812873C9E9BE84DD95B5269
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"Trevor Jackson, III" wrote:
> Paul Crowley wrote:
>
> > Jerry Coffin <[EMAIL PROTECTED]> writes:
> > > > If people are so helpless that, upon discovering that the "official
> > > > standard" cipher is no good, they cannot switch to another cipher
> > > > unless it, too, has become an "official standard", they have little
> > > > hope of achieving secure communications in any event.
> > >
> > > It's not really a question of helplessness. When the US government
> > > makes something a standard, they often mean that literally: people
> > > working with government data are often _required_ to follow all the
> > > government standards relevant to their situation. Just for example,
> > > even though DES is pretty thoroughly broken, there are still agencies
> > > that have NO choice but to continue using it. They'll only be
> > > _allowed_ to switch to 3DES when FIPS 46-3 gets approved.
> >
> > Can NIST choose to designate more than one winner, but nominate only
> > one as the "winner among winners" that should always be used first and
> > should always be an option when choosing between AES candidates?
> >
> > In which case, can't we all have what we want? Or rather, can we move
> > the discussion of whether a protocol should allow multiple ciphers or
> > just one out of the range of things NIST need worry about?
>
> The selection of a preferred choice among the "winners" is not a one-time
> event. The preference may evolve over time due to a number of
> considerations. In addition to the possibility of discovered weaknesses,
> we may find preferences changing as platforms evolve. For instance, the
> preference might change as 64-bit computing becomes ubiquitous the way
> 32-bit computing is now.
>
> Whatever criteria NIST uses, including the covert ones, involves tradeoffs
> among various crypto usages. It is very difficult to select a single
> "best" that is invariant with respect to technological, sociological, and
> cryptological changes. Thus the one-time designation of multiple
> "selectees" (let's avoid the term winners) allows for later expressions of
> preference in light of information not now available.
>
> Also, a twelve standard (approved and preferred) allows for a smooth
I think my spell checker has gone bananas. That should read "... a dual
standard..."
>
> upgrade path. If 15 years from now another contest is held the selectees
> from that contest could be added to the approved list without an indication
> of preference. Five years after that, in light of the inevitable post
> approval analysis, the new ciphers could be moved to the preferred status,
> and the aging ciphers deprecated by downgrading them from preferred to
> approved.
>
> A review of preference among approved ciphers might be useful every 3-5
> years.
==============E812873C9E9BE84DD95B5269
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
"Trevor Jackson, III" wrote:
<blockquote TYPE=CITE>Paul Crowley wrote:
<p>> Jerry Coffin <[EMAIL PROTECTED]> writes:
<br>> > > If people are so helpless that, upon discovering that the "official
<br>> > > standard" cipher is no good, they cannot switch to another cipher
<br>> > > unless it, too, has become an "official standard", they have
little
<br>> > > hope of achieving secure communications in any event.
<br>> >
<br>> > It's not really a question of helplessness. When the US government
<br>> > makes something a standard, they often mean that literally: people
<br>> > working with government data are often _required_ to follow all
the
<br>> > government standards relevant to their situation. Just for
example,
<br>> > even though DES is pretty thoroughly broken, there are still agencies
<br>> > that have NO choice but to continue using it. They'll only
be
<br>> > _allowed_ to switch to 3DES when FIPS 46-3 gets approved.
<br>>
<br>> Can NIST choose to designate more than one winner, but nominate only
<br>> one as the "winner among winners" that should always be used first
and
<br>> should always be an option when choosing between AES candidates?
<br>>
<br>> In which case, can't we all have what we want? Or rather, can
we move
<br>> the discussion of whether a protocol should allow multiple ciphers
or
<br>> just one out of the range of things NIST need worry about?
<p>The selection of a preferred choice among the "winners" is not a one-time
<br>event. The preference may evolve over time due to a number of
<br>considerations. In addition to the possibility of discovered
weaknesses,
<br>we may find preferences changing as platforms evolve. For instance,
the
<br>preference might change as 64-bit computing becomes ubiquitous the
way
<br>32-bit computing is now.
<p>Whatever criteria NIST uses, including the covert ones, involves tradeoffs
<br>among various crypto usages. It is very difficult to select a
single
<br>"best" that is invariant with respect to technological, sociological,
and
<br>cryptological changes. Thus the one-time designation of multiple
<br>"selectees" (let's avoid the term winners) allows for later expressions
of
<br>preference in light of information not now available.
<p>Also, a twelve standard (approved and preferred) allows for a smooth</blockquote>
<i>I think my spell checker has gone bananas. That should read "...
a dual standard..."</i>
<blockquote TYPE=CITE>
<br>upgrade path. If 15 years from now another contest is held the
selectees
<br>from that contest could be added to the approved list without an indication
<br>of preference. Five years after that, in light of the inevitable
post
<br>approval analysis, the new ciphers could be moved to the preferred
status,
<br>and the aging ciphers deprecated by downgrading them from preferred
to
<br>approved.
<p>A review of preference among approved ciphers might be useful every
3-5
<br>years.</blockquote>
<br> </html>
==============E812873C9E9BE84DD95B5269==
------------------------------
** 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
******************************
