Cryptography-Digest Digest #647, Volume #10 Mon, 29 Nov 99 13:13:02 EST
Contents:
Re: Random Noise Encryption Buffs (Look Here) (Simon Turner)
Re: Random Noise Encryption Buffs (Look Here) (James Felling)
Re: Random Noise Encryption Buffs (Look Here) (James Felling)
Re: A Truly Weird Double-DES Mode (Anton Stiglic)
Re: Is this "legal"??? Export concept presented ("John E. Kuslich")
Re: Is this "legal"??? Export concept presented ("John E. Kuslich")
----------------------------------------------------------------------------
From: Simon Turner <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Mon, 29 Nov 1999 17:14:21 +0000
Tom St Denis wrote:
> In article <81s4kb$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Guy Macon) wrote:
> > In article <81rdc8$ovn$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tom
> St Denis) wrote:
> >
> > >If things are to be randomly created, material must be randomly
> > >destroyed.
> >
> > Evidence, please.
>
> If atoms kept being added to earth [via spontaneous creation], we would
> eventually gain so much mass that the moon would collide with us. That
> would be bad.
>
Unfortunately, something being bad doesn't stop it being true.
On the plus side, spontaneous creation does imply the "evaporation" of
black holes, which is nice.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Mon, 29 Nov 1999 11:14:14 -0600
Tom St Denis wrote:
> In article <81oseq$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Guy Macon) wrote:
> > In article <81ogtv$upa$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tom
> St Denis) wrote:
> > >
> > >In article <[EMAIL PROTECTED]>,
> > > "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> > >> Tom St Denis wrote:
> > >> > Universially random should mean something which is random, and
> by NO
> > >> > MEANS at all predictable. However this cannot exist in nature.
> > >>
> > >> Who made you God?
> > >
> > >Ok, explain to me something that is truly random.
> > >
> >
> > The time it takes for an individual atom of potassium-40
> > to decay to Argon-40.
> >
>
> What is random about that? If you can model exactly every nick and
> nanny of the atom, then can't you recreate the decay?
>
> I would classify that as 'hard to model' thus 'random'. But it's not
> universially random.
>
> Tom
Why do you assume that such modeling is even possible?
Given that the present quantum theories are indeed accurate -- and we have
no convincing evidence that they are not. It is impossible to model an
atom so as to predict a decay.( you can make statistical assertions -like
on average there should have been 10 decay events by time t ), but you
cannot make definite predictions. The uncertianty principle prevents
that. This type of phenomena is fundamentally random.
True, if a paradigm shift occurs, and we come to understand these
phenomena on a more fundamental level, all bets are off, but until that
occurs(if ever it does), these events must be regarded as fundamentially
random.
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Mon, 29 Nov 1999 11:16:23 -0600
Tom St Denis wrote:
> In article <81q24c$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Guy Macon) wrote:
> > In article <81pn0e$n6g$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tom
> St Denis) wrote:
> > >> >Ok, explain to me something that is truly random.
> > >> >
> > >>
> > >> The time it takes for an individual atom of potassium-40
> > >> to decay to Argon-40.
> > >
> > >What is random about that? If you can model exactly every nick and
> > >nanny of the atom, then can't you recreate the decay?
> >
> > Because, according to Heisenberg's uncertainty principle, you can't
> > model the atom.
> >
> > >I would classify that as 'hard to model' thus 'random'. But it's not
> > >universially random.
> >
> > Quantum mechanics says that it is impossible to model and impossible
> > to predict, except statisticaly.
>
> Ok look at it another way.
>
> If I took two exact copies [leave the copying theory behind here] of an
> atom, and placed them in two exact same environments. Would they not
> decay the same way? If so, that's hardly random at all.
They would decay differently. Even if the environments they were in were
exactly identical to the best of our ability to determine.
Read up on quantum physics. It is a strange, strange world we live in.
>
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: A Truly Weird Double-DES Mode
Date: Mon, 29 Nov 1999 12:33:38 -0500
==============8E206FFF2B3C9701BEBB2A3C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
John Savard wrote:
> I recently noted that because CBC mode works like this:
>
> ciphertext = DES( plaintext XOR previous ciphertext)
>
> and CFB mode works like this:
>
> ciphertext = plaintext XOR DES( previous ciphertext )
>
> the two modes are very closely related -
>
> CBC mode can be thought of as
>
> ciphertext = DES( plaintext XOR DES( previous plaintext XOR ... ) )
>
> and CFB mode can be thought of as
>
> ciphertext = plaintext XOR DES( previous plaintext XOR ... )
>
> the two are really the same mode, but with the ciphertext taken off at
> different points in the process.
This produces a difference do. For example, you would
not be able to use CFB for public key encryption because
it demands the Encryption function (CBC mode only needs
the Decryption function).
A little off subject here, but I would have to say that
I agree with Scott on one thing. He talked about the
inherent error correcting code in the modes of operation.
For example, in both CBC and CFB mode, if an error is
produced in block i, it will affect the decryption of
block i and i+1 only. This *could* be used in some suspicious
way. It would be better to seperate error correcting from
encryption mode.
Cheers!,
Anton
==============8E206FFF2B3C9701BEBB2A3C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
John Savard wrote:
<blockquote TYPE=CITE>I recently noted that because CBC mode works like
this:
<p>ciphertext = DES( plaintext XOR previous ciphertext)
<p>and CFB mode works like this:
<p>ciphertext = plaintext XOR DES( previous ciphertext )
<p>the two modes are very closely related -
<p>CBC mode can be thought of as
<p>ciphertext = DES( plaintext XOR DES( previous plaintext XOR ... ) )
<p>and CFB mode can be thought of as
<p>ciphertext = plaintext XOR DES( previous plaintext XOR ... )
<p>the two are really the same mode, but with the ciphertext taken off
at
<br>different points in the process.</blockquote>
<pre>This produces a difference do. For example, you would</pre>
<pre>not be able to use CFB for public key encryption because</pre>
<pre>it demands the Encryption function (CBC mode only needs</pre>
<pre>the Decryption function).</pre>
<pre></pre>
<pre>A little off subject here, but I would have to say that</pre>
<pre>I agree with Scott on one thing. He talked about the</pre>
<pre>inherent error correcting code in the modes of operation.</pre>
<pre>For example, in both CBC and CFB mode, if an error is</pre>
<pre>produced in block i, it will affect the decryption of</pre>
<pre>block i and i+1 only. This *could* be used in some suspicious</pre>
<pre>way. It would be better to seperate error correcting from</pre>
<pre>encryption mode.</pre>
<pre></pre>
<pre>Cheers!,</pre>
<pre>Anton</pre>
</html>
==============8E206FFF2B3C9701BEBB2A3C==
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: Is this "legal"??? Export concept presented
Date: Mon, 29 Nov 1999 10:51:19 -0700
The restriction on export of code that is readily modified is very
curious indeed since there exists a very easily implemented means of
modifying ANY binary executable running under Windows.
Here is how it works:
Acme Cryptography writes some cryptographic code and follows all the
rules about not making the code easily changed to implement a longer key
or an auxiliary algorithm. They limit the key length to 40 bits or
whatever the key length du jour is at the time. They pass the one time
review.
Now, Let's suppose another company, El Cracko Software (a company
located in a FREE country, not the USA) does the following:
El Cracko Software disassembles the legal software written by Acme
Software and writes a program that attaches itself to the Acme Software
process while it runs under Windows. The El Cracko Software modifies
the executable in memory so that the Acme Software jumps to a patch that
implements a 1024 bit key instead of a 40 bit key. El Cracko software
does not alter a single bit of the Acme binary or any of its DLL's until
the Acme binary is loaded into Windows memory and is happily executing
itself.
This is EASILY done by any competent Windows programmer. The Windows
API is just chock full of routines that allow modification of a
process's memory space.
The result is that ANY Windows executable can be modified to add
arbitrary strength encryption. So why bother with the stupid
restrictions on modular code??? Why bother with a one time review? One
does not have to modify the released Acme executable until it is
resident in memory and running on a Windows machine. For an example of
this kind of code in a cryptographic setting (an encryption cracker) see
our QB99crak program ( http://www.crak.com ) which bypasses the
sophisticated password encryption used by QuickBooks99 to allow entry to
the not so sophisticated code protected by the password.
Could it be that the pointy headed bureaucrats who write these
regulations view software from the standpoint of the object oriented
programmer who sees software in terms of abstract, bloated,
encapsulated, polymorphic, inherited constructs and never sees the
underlying simplicity or vulnerabilities of the digital world?
This onetime review of code is completely feckless. There is no
protection against unauthorized encryption strength increase by a third
party that is prevented by a one time review. The whole policy is
STUPID on its face.
Yet, millions or perhaps billions of dollars will be spent enforcing
these ridiculous restrictions by hundreds or thousands of programmers
looking for modularity in source code that makes absolutely no
difference to anyone bent on adding strong encryption to any software
one could imagine that runs under Windows.
I could easily add 1024 bit encryption to a screen saver or a picture
viewer or a music composition program. So how does a one time review
prevent the spread of strong encryption?
The emperor has no clothes!!! I tell you no clothes, naked as a Jay
bird! Does anyone not see that the USA crypto restrictions are without
any foundation in reason?
JK Http://wwww.crak.com
Stefek Zaba wrote:
>
> In sci.crypt, albert ([EMAIL PROTECTED]) sang, to the tune of "Baby, baby,
> baby, you're out of time":
> > Algorithms such as RC6 are parameterized.
> > 40bit crypto algorithms are exportable.
>
> > So what if I export code that is RC6 as 32 bit key, 32 bit block, and 1
> > round? Would it them be considered exportable??? Since it's
> > parameterized, then I can email it to someone, and they can in turn
> > change it to 128bits.
>
> In the era where keylength was a distinguishing attribute for US export
> approval (formally, that era still persists; supposed to be going away
> within about three weeks, with the Understanding being that export
> approvals right now are likely to be granted in anticipation of the new
> control regime), your question would have had some grounds. Its answer,
> however, would be "no, it would not be exportable" (or rather, would
> not be classified as qualifying for a licence exemption), since one of the
> tests is whether or not what you propose to export is "readily modifiable".
> In the "new era", keylength and similar restrictions aren't part of the
> criteria. So, on the basis of what BXA have said to date, a *binary*
> package with an interface that allows you to modify the RC6 parameters
> as you suggest would be granted licence exemption (after our old friend
> the 'one-time review').
>
> *Source* code in electronic form does *not*, under the proposed revised
> regs, get the same treatment - that would still require licencing. Yes,
> even if it's in the public domain. No, that's not compatible with the
> Wassenar agreement which the US Government uses as part justification for
> the current control regime. Yes, the inconsistency is under active review.
> No, neither is "foreign availability" a relevant criterion for *source*
> export. No, this doesn't make a great deal of sense; why did you think it
> would?
>
> > I think crypto policies are a joke, especially when you can export
> > Bruce's Applied Crypto book, which contains code in the back..
>
> Laugh all you like - the policies exist and get in the way. Note that
> there's at least one example of the US development community being
> *frozen out* of an otherwise global co-operative crypto open-source
> effort - www.xs4all.nl/~freeswan - because of the potential "contamination"
> from even a one-line bugfix or detailed problem report from a US citizen
> being construed as "technical assistance". Just when the export regulators
> had been persuaded that crypto has moved from military through dual-use to
> overwhelmingly civilian/commercial/individual, they now get to wrap their
> heads around "export" not being for direct commercial gain when it's done
> as open-source joint development. Who'd be a regulator, eh?
>
> Stefek
--
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.com
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: Is this "legal"??? Export concept presented
Date: Mon, 29 Nov 1999 10:49:51 -0700
The restriction on export of code that is readily modified is very
curious indeed since there exists a very easily implemented means of
modifying ANY binary executable running under Windows.
Here is how it works:
Acme Cryptography writes some cryptographic code and follows all the
rules about not making the code easily changed to implement a longer key
or an auxiliary algorithm. They limit the key length to 40 bits or
whatever the key length du jour is at the time. They pass the one time
review.
Now, Let's suppose another company, El Cracko Software (a company
located in a FREE country, not the USA) does the following:
El Cracko Software disassembles the legal software written by Acme
Software and writes a program that attaches itself to the Acme Software
process while it runs under Windows. The El Cracko Software modifies
the executable in memory so that the Acme Software jumps to a patch that
implements a 1024 bit key instead of a 40 bit key. El Cracko software
does not alter a single bit of the Acme binary or any of its DLL's until
the Acme binary is loaded into Windows memory and is happily executing
itself.
This is EASILY done by any competent Windows programmer. The Windows
API is just chock full of routines that allow modification of a
process's memory space.
The result is that ANY Windows executable can be modified to add
arbitrary strength encryption. So why bother with the stupid
restrictions on modular code??? Why bother with a one time review? One
does not have to modify the released Acme executable until it is
resident in memory and running on a Windows machine. For an example of
this kind of code in a cryptographic setting (an encryption cracker) see
our QB99crak program ( http://www.crak.com ) which bypasses the
sophisticated password encryption used by QuickBooks99 to allow entry to
the not so sophisticated code protected by the password.
Could it be that the pointy headed bureaucrats who write these
regulations view software from the standpoint of the object oriented
programmer who sees software in terms of abstract, bloated,
encapsulated, polymorphic, inherited constructs and never sees the
underlying simplicity or vulnerabilities of the digital world?
This onetime review of code is completely feckless. There is no
protection against unauthorized encryption strength increase by a third
party that is prevented by a one time review. The whole policy is
STUPID on its face.
Yet, millions or perhaps billions of dollars will be spent enforcing
these ridiculous restrictions by hundreds or thousands of programmers
looking for modularity in source code that makes absolutely no
difference to anyone bent on adding strong encryption to any software
one could imagine that runs under Windows.
I could easily add 1024 bit encryption to a screen saver or a picture
viewer or a music composition program. So how does a one time review
prevent the spread of strong encryption?
The emperor has no clothes!!! I tell you no clothes, naked as a Jay
bird! Does anyone not see that the USA crypto restrictions are without
any foundation in reason?
JK Http://wwww.crak.com
Stefek Zaba wrote:
>
> In sci.crypt, albert ([EMAIL PROTECTED]) sang, to the tune of "Baby, baby,
> baby, you're out of time":
> > Algorithms such as RC6 are parameterized.
> > 40bit crypto algorithms are exportable.
>
> > So what if I export code that is RC6 as 32 bit key, 32 bit block, and 1
> > round? Would it them be considered exportable??? Since it's
> > parameterized, then I can email it to someone, and they can in turn
> > change it to 128bits.
>
> In the era where keylength was a distinguishing attribute for US export
> approval (formally, that era still persists; supposed to be going away
> within about three weeks, with the Understanding being that export
> approvals right now are likely to be granted in anticipation of the new
> control regime), your question would have had some grounds. Its answer,
> however, would be "no, it would not be exportable" (or rather, would
> not be classified as qualifying for a licence exemption), since one of the
> tests is whether or not what you propose to export is "readily modifiable".
> In the "new era", keylength and similar restrictions aren't part of the
> criteria. So, on the basis of what BXA have said to date, a *binary*
> package with an interface that allows you to modify the RC6 parameters
> as you suggest would be granted licence exemption (after our old friend
> the 'one-time review').
>
> *Source* code in electronic form does *not*, under the proposed revised
> regs, get the same treatment - that would still require licencing. Yes,
> even if it's in the public domain. No, that's not compatible with the
> Wassenar agreement which the US Government uses as part justification for
> the current control regime. Yes, the inconsistency is under active review.
> No, neither is "foreign availability" a relevant criterion for *source*
> export. No, this doesn't make a great deal of sense; why did you think it
> would?
>
> > I think crypto policies are a joke, especially when you can export
> > Bruce's Applied Crypto book, which contains code in the back..
>
> Laugh all you like - the policies exist and get in the way. Note that
> there's at least one example of the US development community being
> *frozen out* of an otherwise global co-operative crypto open-source
> effort - www.xs4all.nl/~freeswan - because of the potential "contamination"
> from even a one-line bugfix or detailed problem report from a US citizen
> being construed as "technical assistance". Just when the export regulators
> had been persuaded that crypto has moved from military through dual-use to
> overwhelmingly civilian/commercial/individual, they now get to wrap their
> heads around "export" not being for direct commercial gain when it's done
> as open-source joint development. Who'd be a regulator, eh?
>
> Stefek
--
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.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
******************************
