Cryptography-Digest Digest #138, Volume #10 Mon, 30 Aug 99 02:13:03 EDT
Contents:
Re: What if RSA / factoring really breaks? ([EMAIL PROTECTED])
WinZip 7.0 (David Hamer)
Re: What if RSA / factoring really breaks? (Nicolas Bray)
Re: Q: Cross-covariance of independent RN sequences in practice (Terry Ritter)
Re: What if RSA / factoring really breaks? ("David J Whalen-Robinson")
Re: NEW THREAD on compression (SCOTT19U.ZIP_GUY)
Re: WT Shaw temporarily sidelined (SCOTT19U.ZIP_GUY)
Re: On employing message-decoys (SCOTT19U.ZIP_GUY)
Excerpts from the EAR & BXA Regs regarding Encryption Software (Anthony Stephen
Szopa)
Re: Can I export software that uses encryption as copy protection? ("Timur Tabi")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.math,sci.math
Subject: Re: What if RSA / factoring really breaks?
Date: Mon, 30 Aug 1999 01:05:26 GMT
>From [EMAIL PROTECTED] (Paul Rubin):
> In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> >Bill Payne, PhD, of Albuquerque, NM already broke RSA several years ago,
>
> No he didn't. He believed he did, but believing doesn't make it so.
> (Square the circle anyone?)
No Paul, you are mistaken.
------------------------------
Date: Sun, 29 Aug 1999 21:36:44 -0400
From: David Hamer <[EMAIL PROTECTED]>
Subject: WinZip 7.0
Can anyone point me towards a password-recovery utility - freeware
or shareware - for WinZip v7.0 ??
David
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
David Hamer The Crypto Simulations Group
[EMAIL PROTECTED] or [EMAIL PROTECTED]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
From: Nicolas Bray <[EMAIL PROTECTED]>
Crossposted-To: alt.math,sci.math
Subject: Re: What if RSA / factoring really breaks?
Date: Sun, 29 Aug 1999 18:36:19 -0700
On 30 Aug 1999 [EMAIL PROTECTED] wrote:
> : (obviously you can't just release it, every cracker would have an
> : info-looting-spree before anybody could react. )
>
> Actually, I think it is felt that the spree would be briefest if exactly
> that course of action were taken.
How so? It seems to me that there are a lot of institutions which would
require time to switch over to a new crypto system. It seems to me that
the best way would be demonstration that a method exists followed by total
secrecy(of course, a lot of people would probably start trying to kill
you...)
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Q: Cross-covariance of independent RN sequences in practice
Date: Mon, 30 Aug 1999 02:23:05 GMT
On Sun, 29 Aug 1999 10:15:42 +0200, in
<[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>If one has two independent sequences of uniformly distributed random
>numbers, their cross-covariance should theoretically (by definition)
>be zero. Because of imperfection in this world, e.g. impossibility of
>making objects of exact sizes or attaining the temperature of absolute
>zero, I suppose that there is a certain not too small lower bound of
>the (average) value of the cross-covariance obtainable in practice.
>Does anyone happen to have computed the cross-covariance of
>independent very good random number sequences?
>
>A related question concerns the auto-covariance. Does anyone
>happen to have such data, say, from sequences obtained from very
>good physical sources of noises?
I have recently done a fairly extensive experimental characterization
of a number of different analog noise sources by recording them in
CD-quality monaural using an ordinary sound card, then analyzing the
resulting .WAV files. Each .WAV analysis includes a wide range of
statistical measures, as well as detailed FFT frequency,
autocorrelation and distribution graphs. The actual .WAV files are
also available. While this may not be exactly what you want, it is
what I have. Start at:
http://www.io.com/~ritter/NOISE/NOISCHAR.HTM
If there is some additional measure which would be informative, I
would like to hear about it, with an argument about why it would be
interesting and worthwhile. When I started out, I expected that the
FFT would be tell all; now I see the autocorrelation and distribution
as more important.
Unfortunately, I have almost no time available to participate in a
discussion.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "David J Whalen-Robinson" <[EMAIL PROTECTED]>
Crossposted-To: alt.math,sci.math
Subject: Re: What if RSA / factoring really breaks?
Date: Sun, 29 Aug 1999 23:24:02 -0400
> How so? It seems to me that there are a lot of institutions which would
> require time to switch over to a new crypto system. It seems to me that
> the best way would be demonstration that a method exists followed by total
> secrecy(of course, a lot of people would probably start trying to kill
> you...)
It would have to be done anonymously...
If there is a solution, then it's just a matter of time before somebody gets
it.
It seems it would be better that good people find it and warn everybody
before
it fell into the hands of those who would use it in a bad way.
BTW: the best way to demonstrate it would be to show the factorization of a
huge key...
The second edition of "Applied Cryptography" states that a
2048 bit key would take 4*10^14 mips years, even with the Special Number
Field Sieve
(This may be slightly outdated)
In Seti at home's entire existance as of now they have only
59262.02 years of computer time, and they have had over 1000000 computer
participating.
RSA-617 is 2048 bits, if you ever see it's factor any time soon,
there's a real good change somebody has a new method.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NEW THREAD on compression
Date: Mon, 30 Aug 1999 05:23:34 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>[EMAIL PROTECTED] wrote:
>>
>> SCOTT19U.ZIP_GUY ([EMAIL PROTECTED]) wrote:
>> : At least if you always have a file that
>> : decompresses the attacker does not know for sure that you did not send
>> : a binary file.
>>
>> That is a valid point, but there is a flaw in your approach. There's
>> always the chance that somewhere in the decrypted message there will be a
>> string of too many zeroes in a row. Or, there might not be enough zeroes
>> at the end of the message, causing it to end in the middle of a symbol.
>
>Your comment above shows (independent to what you addressed) a
>trouble with my scheme. My scheme indeed fails if the file to be
>decompressed (outcome of decrytion with a wrong key) contains a
>sufficiently long sequence of 0's. (The chance of this occuring
>might be argued to be small but is certainly real.)
>
>Since Scott's scheme, if I don't err, also excludes certain
>bit sequences from being valid Huffman codes, I am yet unclear of
Actully it alwasy uses a full huffman table there are no invlaid
Huffman codes. I think if you look back I submittle a distilled messaage
with all the rules. THere are very few rules and I don't think there was
any inconsitences in the rules. But please look.
>how his program behaves if fed with a file containing such a bit
>sequence, say, at the very beginning of the file. Perhpas Mr. Scott
>would kindly say something about this in plain English, explaining
>the program logic for handling such situations.
Very one byte file compess to a one byte file. every 2 bytes file
compresses to either 2 bytes or 3 bytes. But some 2 byte files
decompress to 9 bytes. Just what situaation are you have trouble
with?
>
>On the other hand, on the assumption that a certain small defect
>to be described below is acceptable, I like to propose the following
>modification of my scheme:
>
>(1) Encode with the normal Huffman algorithm.
>
>(2) If the last bit output is not at byte boundary (or word boundary,
> if output is to be in whole words), fill with 0's to byte/word
> boundary.
>
>(3) Delete trailing zero bytes/words.
>
>(4) On decompressing, if the buffer is not empty at end of file,
> append as many 0's as are necessary to form a valid Huffman
> code.
>
>This evidently suffices to achieve Scott's 'one to one' property
It obviously does not fill the "one to one" requirement
since as you point out it may have spurious symbols at the
end of file. But it does allow every file to be uncompressable
so that the attacker can not out right reject the file. It is also
a form of lossy text compression in the since that in some cases
more than 1 files compress to the same file. Your message and the
same message with the spurious character that sometimes appears
on decompression. It is also very easy to code. The only draw backs
that I can think of is that you aren't saving space even though it seems
to use about the same space as mine. However I do like the idea of loss text
compression but I like it to occur more as a "all or nothing" in other
words it is lossy but on decompression you either have the whole
file or garbage to pick from. Instead of the guessing if last character
is correct.
>The aforesaid defect is that the legitimate communication partner
>under circumstances may obtain on decompressing some spurious symbols
>(corresponding to the Huffman code of all 0's) at the end of the
>message. If the message is a natural language text, the recipient
>should normally be able to recognize these spurious symbols. If the
>message is arbitrarily binary, a message length needs to transmitted
>to the communication partner. (In favourable cases, where for whole
>word transmission the spurious symbols occupy less than a full word,
>the length information is not necessary.) So the scheme is not
>perfect but seems to be usable nevertheless in practice.
>
>> Ensure that the Huffman code in use contains at least one symbol as
>> long as eight bits.
>
>> After the message is compressed, note how many bits remain in the last
>> byte. Pad those bits by filling them with the start of a symbol that
>> is at least one bit longer than the remaining bits.
>
>I am afraid that this doesn't work for the case where the file obtained
>is through decryption with a wrong key, for one doesn't have control
>of the bits at these filling positions.
>
>M. K. Shen
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: WT Shaw temporarily sidelined
Date: Mon, 30 Aug 1999 05:45:00 GMT
In article <[EMAIL PROTECTED]>, Jim Dunnett wrote:
>On Sat, 28 Aug 1999 19:57:15 GMT, [EMAIL PROTECTED] (don garrisan) wrote:
>
>>Bill has asked me to let you guys know that he will be off line for a
>>short while. Currently in the hospital, he will be back in touch with
>>the group as physical progress, time and laptop make it possible.
>>
>>In the mean time, hang in there........that is what he is doing.
>
>Please convey my best wishes for a speedy recovery to him.
>
Which hospital is he in. maybe I can drop by and cheer him up.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: On employing message-decoys
Date: Mon, 30 Aug 1999 05:43:37 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>On the assumption that absolute security is neither attainable nor
>(often) necessary/affordable, that no adversary is omnipotent (having
>infinite resources) and that no real-life message needs to be kept
>secret till eternity, let's consider the following scenario:
>
>Alice wants to send a message to Bob. The content of the message
>needs to be kept secret only within 24 hours (e.g. stuffs concerning
>decision making in commercial negotiations) and estimates that
>this time frame is just within the capability of the adversary. She
>sends in addition to the true message 9 dummy messages with random
>or bogous contents, employing different keys. Doesn't this increases
>the security of her message tenfold because the chance of analysis
>is reduced to 1/10 of the original? If she sends 99 dummy messages,
>doesn't she have a legitimate hope that the adversary would probably
>give up?
This is a good method the problem though is that one has to be
very careful of the content of the messages. Since it maybe possilbe
to weed out incorrect message. This can create other problems so
that the dummy message look the same from a mathematical viewpoint
does she send just random stuff. Or does she send bogus messages
so they really have to look at them carefully. But to many bogus messages
might give the attacker to much time to learn how to break the message.
My favorite way of sending messages. is to first lenght the file by many
thousand of bytes. have to bytes in the front of file that tells how
many thousands of bytes are added to the front and back of file besides
the fixed amount of random padding. With this you can send many
files that vary in size from 50k to 200k that contain zere message or
you can aqueezez a small message in. Like "hey son how is college"
do this with an offline porgraam and then use a all or nothing encryption
type of program like scott16u or scott19u.
The added advantage of this is it forces the NSA over a short period
of time to be forced to save millions of bytes of trash that can't be
decompressed.
>I believe that employing message-decoys is a fairly valuable means
>of achieving enhanced information security in practice, since higher
>message transmission cost is nowadays barely a matter of concern for
>materials requiring some nontrivial protections. Certainly the scheme
>can be subsumed by what has long been known in cryptology as the
>'busy channel'. But I think that this special case probably does
>deserve our mentioning separately to the common users of encryption
>algorithms.
>
>M. K. Shen
>-------------------------
>http://home.t-online.de/home/mok-kong.shen (new addr.)
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Excerpts from the EAR & BXA Regs regarding Encryption Software
Date: Sun, 29 Aug 1999 22:06:52 -0700
Reply-To: [EMAIL PROTECTED]
The most significant Excerpts from the EAR & BXA Regs I found.
located, searched, and posted to help all of you by Ciphile Software
OAP-L3: Original Absolute Privacy - Level3 Encryption Software
http://www.ciphile.com
(7) General Prohibition Seven � Support of
Proliferation Activities (U.S. Person
Proliferation Activity).
_(i) Support of Proliferation Activities (U.S.
Person Proliferation Activity).
(A) If you are a U.S. person as that term is
defined in �744.6(c) of the EAR, you may not
engage in any activities prohibited by �744.6(a)
or (b) of the EAR, which prohibits the
performance, without a license from BXA, of
certain financing, contracting, service, support,
transportation, freight forwarding, or employment
that you know will assist in certain proliferation
activities described further in part 744 of the
EAR. There are no License Exceptions to this
General Prohibition Seven in part 740 of the EAR
unless specifically authorized in that part.
(ii) You may not, without a license from BXA,
provide certain technical assistance to foreign
persons with respect to encryption items, as
described in �744.9 of the EAR.
�744.9
RESTRICTIONS ON TECHNICAL
ASSISTANCE BY U.S. PERSONS WITH
RESPECT TO ENCRYPTION ITEMS
(a) General prohibition
No U.S. person may, without a license from BXA,
provide technical assistance (including training) to
foreign persons with the intent to aid a foreign
person in the development or manufacture outside
the United States of encryption commodities and
software that, if of United States origin, would be
controlled for "EI" reasons under ECCN 5A002 or
5D002. Note that this prohibition does not apply
if the U.S. person providing the assistance has a
license or is otherwise entitled to export the
encryption commodities and software in question
to the foreign person(s) receiving the assistance.
Note in addition that the mere teaching or
discussion of information about cryptography,
including, for example, in an academic setting, by
itself would not establish the intent described in
this section, even where foreign persons are
present.
(b) Definition of U.S. person
For purposes of this section, the term U.S. person
includes:
(1) Any individual who is a citizen or permanent
resident alien of the United States;
(2) Any juridical person organized under the laws
of the United States or any jurisdiction within the
United States, including foreign branches; and
(3) Any person in the United States.
Definitions of Terms Part 772-page 6
Export Administration Regulations
"Cryptanalysis". (Cat 5)--The analysis of a
cryptographic system or its inputs and outputs to
derive confidential variables or sensitive data
including clear text. (ISO 7498-2-1988(E),
paragraph 3.3.18)
"Cryptography". (Cat 5)--The discipline that
embodies principles, means and methods for the
transformation of data in order to hide its
information content, prevent its undetected
modification or prevent its unauthorized use.
"Cryptography" is limited to the transformation of
information using one or more "secret
parameters" (e.g., crypto variables) and/or
associated key management.
Note: "Secret parameter": a constant or key
kept from the knowledge of others or shared only
within a group.
Encryption items. The phrase encryption items
includes all encryption commodities, software,
and technology that contain encryption features
and are subject to the EAR. This does not include
encryption items specifically designed,
developed, configured, adapted or modified for
military applications ( including command,
control and intelligence applications) which are
controlled by the Department of State on the U.S.
Munitions List.
Encryption licensing arrangement. A license
that allows the export of specified products to
specified destinations in unlimited quantities. In
certain cases, exports are limited to specified end-users
for specified end-uses. Generally, reporting
of all sales of the specified products is required at
six month intervals. This includes sales made
under distribution arrangements and distribution
and warehousing agreements that were previously
issued by the Department of State for encryption
items.
Encryption object code. Computer programs
containing an encryption source code that has
been compiled into a form of code that can be
directly executed by a computer to perform an
encryption function.
Encryption software. Computer programs that
provide capability of encryption functions or
confidentiality of information or information
systems. Such software includes source code,
object code, applications software, or system
software.
Encryption source code. A precise set of
operating instructions to a computer that, when
compiled, allows for the execution of an
encryption function on a computer.
Export Control Classification Number (ECCN).
The numbers used in Supplement No. 1 to part
774 of the EAR and throughout the EAR. The
Export Control Classification Number consists of
a set of digits and a letter. Reference �738.2(c) of
the EAR for a complete description of each
ECCN's composition.
"Object code". (or object language) (Cat 4)--An
equipment executable form of a convenient
expression of one or more processes ("source
code" (or source language)) that has been
converted by a programming system. (See also
"source code")
Foreign Terrorist Organizations (FTO). Any
organization that is determined by the Secretary
of the Treasury to be a foreign terrorist
organization under notices or regulations issued
by the Office of Foreign Assets Control (see 31
CFR chapter V).
D. Software
! 5D002 Information Security - "Software".
License Requirements
Reason for Control: NS, AT, EI
Control(s) Country Chart
NS applies to entire entry NS Column 1
AT applies to entire entry AT Column 1
EI applies to encryption items transferred from the
U.S. Munitions List to the Commerce Control List
consistent with E.O. 13026 of November 15, 1996
(61 FR 58767) and pursuant to the Presidential
Memorandum of that date. Refer to �742.15 of the
EAR.
Note: Encryption software is controlled
because of its functional capacity, and not
because of any informational value of such
software; such software is not accorded
the same treatment under the EAR as other
"software"; and for export licensing
purposes, encryption software is treated
under the EAR in the same manner as a
commodity included in ECCN 5A002.
License Exceptions for commodities are
not applicable.
Note: Encryption software controlled for
EI reasons under this entry remains
subject to the EAR even when made
publicly available in accordance with part
734 of the EAR, and it is not eligible for
the General Software Note ("mass market"
treatment under License Exception TSU
for mass market software). After a
technical review, certain encryption
software may be released from EI controls
and made eligible for the General Software
Note treatment as well as other provisions
of the EAR applicable to software. Refer
to �742.15(b)(1) of the EAR, and
Supplement No. 6 to part 742 of the EAR.
License Exceptions
CIV: N/A
TSR: N/A
! List of Items Controlled
Unit: $ value
Related Controls: See also 5D992. This entry
does not control "software" "required" for the
"use" of equipment excluded from control
under to 5A002 or "software" providing any of
the functions of equipment excluded from
control under 5A002.
Related Definitions: 5D002.a controls
"software" designed or modified to use
"cryptography" employing digital or analog
techniques to ensure "information security".
Items:
a. "Software" specially designed or modified for
the "development", "production" or "use" of
equipment or "software" controlled by 5A002,
5B002 or 5D002.
b. "Software" specially designed or modified to
support "technology" controlled by 5E002.
c. Specific "software" as follows:
c.1. "Software" having the characteristics, or
performing or simulating the functions of the
equipment controlled by 5A002 or 5B002;
c.2. "Software" to certify "software"
controlled by 5D002.c.1.
a. "Software", as follows:
a.1 "Software" specially designed or modified
for the "development", "production", or "use" of
telecommunications equipment containing
encryption (e.g., equipment controlled by
5A992.a);
a.2. "Software" specially designed or modified
for the "development", "production:, or "use" of
information security or cryptologic equipment (e.g.,
equipment controlled by 5A992.b);
b. "Software", as follows:
b.1. "Software" having the characteristics, or
performing or simulating the functions of the
equipment controlled by 5A992.a.
b.2. "Software having the characteristics, or
performing or simulating the functions of the
equipment controlled by 5A992.b.
c. "Software" designed or modified to protect
against malicious computer damage, e.g., viruses.
(9) Export of encryption source code and
object code software.
(i) For purposes of the EAR, the export of
encryption source code and object code software
means:
(A) An actual shipment, transfer, or
transmission out of the United States (see also
paragraph (b)(9)(ii) of this section); or
(B) A transfer of such software in the United
States to an embassy or affiliate of a foreign
country.
(ii) The export of encryption source code and
object code software controlled for EI reasons
under ECCN 5D002 on the Commerce Control
List (see Supplement No. 1 to part 774 of the
EAR) includes downloading, or causing the
downloading of, such software to locations
(including electronic bulletin boards, Internet file
transfer protocol, and World Wide Web sites)
outside the U.S. (except Canada), or making such
software available for transfer outside the United
States (except Canada), over wire, cable, radio,
electromagnetic, photo optical, photoelectric or
other comparable communications facilities
accessible to persons outside the United States
(except Canada), including transfers from
electronic bulletin boards, Internet file transfer
protocol and World Wide Web sites, unless the
person making the software available takes
precautions adequate to prevent unauthorized
transfer of such code outside the United States or
Canada. Such precautions shall include ensuring
that the facility from which the software is
available controls the access to and transfers of
such software through such measures as:
(A) The access control system, either through
automated means or human intervention, checks
the address of every system requesting or
receiving a transfer and verifies that such systems
are located within the United States or Canada;
(B) The access control system provides every
requesting or receiving party with notice that the
transfer includes or would include cryptographic
software subject to export controls under the
Export Administration Regulations, and that
anyone receiving such a transfer cannot export the
software without a license; and
(C) Every party requesting or receiving a
transfer of such software must acknowledge
affirmatively that he or she understands that the
cryptographic software is subject to export
controls under the Export Administration
Regulations and that anyone receiving the transfer
cannot export the software without a license.
BXA will consider acknowledgments in
electronic form provided that they are adequate to
assure legal undertakings similar to written
acknowledgments.
-- Perhaps we can discuss exactly what all this means after you all
have read this.
AS
------------------------------
From: "Timur Tabi" <[EMAIL PROTECTED]>
Reply-To: "Timur Tabi" <[EMAIL PROTECTED]>
Subject: Re: Can I export software that uses encryption as copy protection?
Date: Mon, 30 Aug 1999 04:48:06 GMT
On 29 Aug 1999 07:12:53 GMT, JPeschel wrote:
>Nope, he shouldn't have any problem exporting his software, as it only
>does decryption.
Do you have a reference for that statement? I'm trying to find where in the
law it says I can do that. I need hard proof before I can go ahead with it.
------------------------------
** 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
******************************
