Cryptography-Digest Digest #179, Volume #11 Tue, 22 Feb 00 01:13:02 EST
Contents:
Re: Processor speeds. ("Clockwork")
Site Updates: (JPeschel)
Re: Swapfile Overwriter: R.I.P. (Steve K)
Re: How Useful is Encryption as Long as NSA Exists? ("John E. Kuslich")
Re: role of Prime Numbers in cryptography (DJohn37050)
Re: Keys & Passwords. (wtshaw)
Re: How Useful is Encryption as Long as NSA Exists? ("Scott Fluhrer")
Re: How Useful is Encryption as Long as NSA Exists? ([EMAIL PROTECTED])
Re: code still unbroken (MEGstir)
Re: role of Prime Numbers in cryptography (Ralph Hilton)
Re: Swapfile Overwriter: R.I.P. (Dave Hazelwood)
----------------------------------------------------------------------------
Reply-To: "Clockwork" <[EMAIL PROTECTED]>
From: "Clockwork" <[EMAIL PROTECTED]>
Subject: Re: Processor speeds.
Date: Tue, 22 Feb 2000 01:25:12 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Mok-Kong Shen wrote:
> > I am convinced that the Cray type is out even though I am personally
> > acquainted with persons who are still 'fans' for that for reasons
> > comprehensible (as well as uncomprehensible) for me.
>
> Re-read my previous posting. Supercomputers, like PCs, evolve.
> Some problems simply do not benefit much from massively parallel
> processing. And some problems that are highly parallelizable
> also require coordination among the processing units that is
> hard or impossible to achieve effectively with networked PCs.
> So networked PCs cannot totally replace true supercomputing.
People talk about developing distributed super-computers using standard PC
chips, but here is an excellent idea: Why not use the newer, 128-bit game
consoles instead of PC-based systems? I see several advantages of doing
such a thing:
1. Cost Effective: For the price of one complete PC system, you can purchase
more than 10 console systems. (The networking hardware is trivial and
built-in to most of these systems. Additionally, the console manufacturer
takes a hit on the cost of the hardware :)
2. Performance: A single 128-bit, console system outperforms a PC system
because it is optimized for what we are interested in -- high-performance
vector calculations. (FYI, MHz is not the true measure of performance.)
3. OS Overhead: Your algorithms run happily without any operating system
overhead.
4. Bus Bandwidth: The PC is limited to 200 MHz bus components at 32-bits.
The consoles blow that away at 128-bits wide (amazing).
5. Size and Heat: Most new console systems are self-contained and
liquid-cooled. You can place upwards of 5 stripped consoles in the same
space as a rack-mounted PC.
Robert L. Sitton
Software Engineer
ICQ: 28332295
Fax: 303-975-6336
[EMAIL PROTECTED]
The problems of the world cannot possibly be solved by skeptics or cynics
whose horizons are limited by the obvious realities. We need men who can
dream of things that never were.
John F. Kennedy
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Site Updates:
Date: 22 Feb 2000 02:05:02 GMT
To my site I've added a new CuteFTP cracker, cuteftp11-99,
by Apis, as well as a link to the description of CuteFTP's
password insecurity by SecuiTeam. Thsese are on the "Key
Recovery" page.
I've revised the link to Alex's description of solver00.
This is currently on the "Key Recovery" page, but I'll likely
be moving it, and other classical cryptanalysis
tools, to the "Historical" page.
I've also added a link on the "Resources" page to a mirror
of the site of my Russian friend Pavel S. (If you are on AOL,
you will need to use a proxy to get to this mirror.)
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (Steve K)
Subject: Re: Swapfile Overwriter: R.I.P.
Date: Tue, 22 Feb 2000 02:19:53 GMT
On Mon, 21 Feb 2000 03:01:38 GMT, [EMAIL PROTECTED] (Dave
Hazelwood) wrote:
>Go get Scramdisk....it has one to wipe both freespace and
>the swapfile.
Got Scramdisk & like it a lot. The "wipe swapfile slack" dingus is
probably OK, but the manual only says:
"Any slack left when the swapfile contracts may contain data,
overwriting the slack securely clears any data in it."
Judging by the info displayed during the Scramdisk overwrite process,
and the (very brief) time it takes to finish, I am assuming that there
is one overwrite with a fixed pattern, done by overflowing the system
RAM with data in the wiping pattern. Then when the maximum amount of
data that can be written is in there, Scramdisk closes, freeing up the
space that it just ate in the swap file. That's OK as far as it goes
and lots better than nothing.
But I still like having a little dedicated app that eats the entire
swapfile, with multiple overwrites. This is not possible during a
Windows session, hence the "slack" that is overwritten by Scramdisk,
not the whole "swap file". Anything in there that is "in use" by an
application, won't be touched. That's probably nothing to panic
about, but some crypto nuts just hate loose ends... especially when
there are easy ways to avoid leaving them.
It's possible to recover data from overwritten disk space, but the
process is expensive and uncertain. The better the overwriting
method, the more expensive and less certain the recovery becomes. I
always like to make worst case assumptions where crypto stuff is
involved, so I put the "wipe swapfile slack" function of Scramdisk in
a whole other category than overwriting with (for instance) Scorch.
So I still want a Swapfile Overwriter replacement to point the newbies
at...
:o)
Steve
---Continuing freedom of speech brought to you by---
http://www.eff.org/ http://www.epic.org/
http://www.cdt.org/
PGP key 0x5D016218
All others have been revoked.
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: How Useful is Encryption as Long as NSA Exists?
Date: Mon, 21 Feb 2000 19:47:26 -0700
A while ago, we developed a process for exhaustively searching the 40 bit
RC4 key used by Microsoft Word and Excel. There are 40 bits of entropy, the
RC4 engine is re-keyed periodically and 8 bits of counter are added to make
a 48 bit key. The original 40 bits are hacked from a 128 bit MD5 hash of
the password and some other data.
In the process of working out this encryption, we noticed a very suspicious
constant used to salt the password hash. While this constant was not always
the same number, the numbers used had a very suspicious regularity that I
believe may be exploited to shortcut the key search. Even though 40 bits is
not a long key by today's standards, it still takes a lot of computer
resources if one is engaged in production code breaking so a backdoor like
this would come in very handy.
We briefly discuss this constant in our article on Word encryption which may
be purchased from our web site at http://www.crak.com
I do not fully understand the implications of the regularity we discovered
but it certainly makes one wonder about the possibility that a backdoor
exists.
I dun, maybe I'm just paranoid...
JK
<[EMAIL PROTECTED]> wrote in message news:88s99s$lhu$[EMAIL PROTECTED]...
> As you all know there are rumors that Microsoft Windows products have
> an NSA backdoor. Why not, if throught history the NSA has always
> convinced foreign crypto companies to have one too. Check out an
> interesting article on:
>
> http://mediafilter.org/caq/cryptogate/
>
> Currently, U.S. companies can export strong crypto but the product must
> continuously go through government "review," whatever that means. Many
> argue that these domestic requirements are useless because someone
> could buy strong crypto from Israel, Ireland, etc., that has not
> been "touched" by the U.S. government. But can we say for sure that the
> NSA's fingers have not been all over these products as well, especially
> when there is plenty of evidence to the contrary?
>
> Maybe a drug dealer living in Costa Rica, who has fled the U.S. years
> before, is using encryption software from a non-U.S. country in some of
> his daily operations, thinking that nobody is listening, when the U.S.
> actually has the key. What protection is a safe with an infinite number
> of combinations if your enemy has the secret code? Code breaking ceases
> to become an issue.
>
> Furthermore, even if the drug dealer in question is lucky enough to be
> using crypto from a country that has not been pursuaded by the U.S. to
> cough up the key, he is probably still using Windows, and might still
> have some of his data vulnerable.
>
> Even though all this is a big "what if" scenario, can someone (say,
> living outside of the U.S.) using a Windows operating system be
> positively sure that the U.S. cannot decrypt his encrypted
> communication or the encrypted information inside his computer, except
> by guessing the password (which is the most difficult way)? how about
> access his/her files through Microsoft?
>
> Thanks.
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: role of Prime Numbers in cryptography
Date: 22 Feb 2000 02:50:06 GMT
Check out IEEE P1363, there is lots of discussion, pseudocode, security
analysis, etc. Use any search engine to find it.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Keys & Passwords.
Date: Mon, 21 Feb 2000 20:23:55 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (wtshaw) wrote:
> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
>
> >.... Suppose I want to limit the input characters to the set
> > {A-Z, a-z, 0-9), consisting of 62 allowable characters, what should
> > I 'best' do to the hex sequence obtained from my hashing program
> > for the purpose? (If mapping, how is that mapping to be done?)
OK, I did some more thinking on the subject, went over my archive of base
transormation charts and came up with two solutions. You know when I get
out the magnifying glass and atlases as a last step, you are abt to get
something strange.
These two algorithms give bits as 6 per characters in base 64 as a solved
sequence, so the handy dandy letter you enter cannot entirely range over
the whole number of possibilities for them, just almost all of it:
Nal, no typo here, produces blocks of 24 bits in 4 characters base 64.
Input in more handy characters is from base 28, I suppose the alphabet and
two more characters, maybe + and -. Five characters in base 28 give all
combinations of 4 characters in base 64. This is because 64^4 =
16,777,216 and 28^5 = 17,210,368. The efficiency of Nal is 97.48%, not
too shabby.
The best case for Nal is increments of 24 bits, but you could harvest the
necessary number for your key from 24, 48, 72, etc. bits.
Another that is promising is Maimana, that uses base 36 as a reasonable
set for entry. The other base is 65, which means that an end character
could be used to define which base 64 characters would be used. As it
happens, 7 characters in base 36 give 6 characters in base 65. Looking at
the output block, it could represent a maximum of 36 bits per block, or
any increment of 6 bits as ended with that 65th character, and you coulod
use several blocks concatenated to get really longer keys.
The fit for Maimana is 98.1% for 65 characters, a little less in base 64
subset. The numbers use a clean base 6 to 36 conversion, and the
relationships 65^3 = 274,627 and 6^7 = 279,936. Aside for possible
substitution in both of these algorithms, the 14 hexit stage could be
modified by a transposition key, or increment if more blocks are used to
fit your needs.
--
Arianna Huffington for sainthood; I would say for President, but
she has a heart, and...she was born outside of the country. ...Better to finally get
your eyes open and try to do the just thing.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: How Useful is Encryption as Long as NSA Exists?
Date: Mon, 21 Feb 2000 19:30:00 -0800
John E. Kuslich <[EMAIL PROTECTED]> wrote in message
news:lMms4.538$[EMAIL PROTECTED]...
> In the process of working out this encryption, we noticed a very
suspicious
> constant used to salt the password hash. While this constant was not
always
> the same number, the numbers used had a very suspicious regularity that I
> believe may be exploited to shortcut the key search. Even though 40 bits
is
> not a long key by today's standards, it still takes a lot of computer
> resources if one is engaged in production code breaking so a backdoor like
> this would come in very handy.
>
> I do not fully understand the implications of the regularity we discovered
> but it certainly makes one wonder about the possibility that a backdoor
> exists.
It sounds more like a programming mistake on MS's part. If it was a
deliberate backdoor, you'd expect it to be rather better hidden (such as,
having a guessable salt based on the something obscure in the ciphertext, or
better yet, hiding the key somewhere in the ciphertext in an obfuscated
format). Besides, unless you were going through a huge number of encrypted
documents compared to your available computing power, would you really need
to risk a back door other than the 40-bit encryption?
--
poncho
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How Useful is Encryption as Long as NSA Exists?
Date: Tue, 22 Feb 2000 04:04:01 GMT
In article <88s99s$lhu$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> As you all know there are rumors that Microsoft Windows products have
> an NSA backdoor. Why not, if throught history the NSA has always
> convinced foreign crypto companies to have one too. Check out an
> interesting article on:
>
> http://mediafilter.org/caq/cryptogate/
>
> Currently, U.S. companies can export strong crypto but the product must
> continuously go through government "review," whatever that means. Many
> argue that these domestic requirements are useless because someone
> could buy strong crypto from Israel, Ireland, etc., that has not
> been "touched" by the U.S. government. But can we say for sure that the
> NSA's fingers have not been all over these products as well, especially
> when there is plenty of evidence to the contrary?
>
> Maybe a drug dealer living in Costa Rica, who has fled the U.S. years
> before, is using encryption software from a non-U.S. country in some of
> his daily operations, thinking that nobody is listening, when the U.S.
> actually has the key. What protection is a safe with an infinite number
> of combinations if your enemy has the secret code? Code breaking ceases
> to become an issue.
>
> Furthermore, even if the drug dealer in question is lucky enough to be
> using crypto from a country that has not been pursuaded by the U.S. to
> cough up the key, he is probably still using Windows, and might still
> have some of his data vulnerable.
>
> Even though all this is a big "what if" scenario, can someone (say,
> living outside of the U.S.) using a Windows operating system be
> positively sure that the U.S. cannot decrypt his encrypted
> communication or the encrypted information inside his computer, except
> by guessing the password (which is the most difficult way)? how about
> access his/her files through Microsoft?
>
> Thanks.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
As I mentioned earlier in this forum it is
already possible to set up quantum encryption
via a fiber optic network and this system so
far appears immune to eavesdropping.
Encryption will continue to be important but
the significance of the encrypted data depends
entirely on the specific circumstances. In
general, it is likely that the weakest link in a
"secure" system could be the people who use
it. The former director of the CIA put highly
classified documents on his home pc which
was then used to surf the web. The CIA, etc.
have operatives trained in interogation and
former U.S. Army Seargent Clifford Stone has
admitted that the U.S. Goverment has quietly
assassinated innocent American civilians to
prevent critical security leaks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (MEGstir)
Subject: Re: code still unbroken
Date: 22 Feb 2000 05:29:51 GMT
>Subject: Re: code still unbroken
>From: "Chuck Davis" [EMAIL PROTECTED]
>Date: 2/18/00 1:56 PM Pacific Standard Time
>Message-id: <38adc069$0$[EMAIL PROTECTED]>
>
>Hi, Geoff: The download problem is a puzzler, and the first time I've seen
>it mentioned. I'll alert the webmaster to the date problem, it's likely he
>hasn't even noticed it. And as for nobody caring, for a chance to win $3,000
>I think I could learn to care! Here's the puzzle..
>
> <CODE author="Chuck Davis">
> The solution is a single sentence taken at random from a
>renowned
>
> English language encyclopedia.
> Punctuation is ignored.
>
> 82 44 22 67 83 11 35 93 52 11 51 64 71 45 15 31 94 51 66 32
>58 93
>
> 83 15 52 77 94 21 47 96 34 22 71 56 22 63 82 48 23 31 85 73
>16 39
>
> 72 15 11 55 47 96 34 22 71 51 26 91 95 12 16 92 91 19 12 35
>71 54
>
> 33 23 11 96 31 31 73 82 91 33 79 82 34 52 81 78 52 75 31 27
>72 93
>
> 95 22 57 92 93 79 22 59 17 96 35 11 73 51 27 93 96 15 35 37
>87 18
>
> 54 71 54 14 33 92 76 71 16 67 95 71 37 39 95 46 11 93 82 44
>29 57
>
> 44 71 91 13 15 56 23 35 71 14 55 94 66 35 17 54 13 91 71 72
>26 39
>
> 85 17 58 87 91 18 46 84 51 47 17 58 48 96 66 21 47 77 33 33
>72 52
>
> 27 38 95 71 37 51 46 82 33 24 59 31 85 14 53 87 38 33 13 84
>53 44
>
> 16 66 77 15 57 85 35 11 71 94 98 51 83 11 33 91 94 15 27 92
>51 27
>
> 42 93 65
>
> Send your answer to: [EMAIL PROTECTED]
> </CODE>
>
>
>Geoff Lane <[EMAIL PROTECTED]> wrote in message
>news:88jffe$lio$[EMAIL PROTECTED]...
>> > Chuck Davis wrote:
>> >
>> >> Most of the correspondence I get from cryptanalysis folk about the code
>I
>> >> devised at discovervancouver.com sneers at its triviality.
>>
>> Perhaps nobody cares?
>> Perhaps nobody has the patience to wait for the discovervancouver.com
>> page to down load.
>> Perhaps nobody can stop laughing at the Y2K bug the page still displays
>> (Saturday, February 19, 100 indeed!)
>>
>> --
>> Geoff. Lane. |
>>
>> In case of fire, yell FIRE!
>
>
>
>
>
>
>
>
------------------------------
From: Ralph Hilton <[EMAIL PROTECTED]>
Subject: Re: role of Prime Numbers in cryptography
Date: Tue, 22 Feb 2000 06:12:58 +0100
Reply-To: [EMAIL PROTECTED]
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
On Tue, 22 Feb 2000 00:30:59 GMT, in sci.crypt you wrote:
>Hello,
> I'm assisting with research for a High School Math project focusing
>on the role of prime numbers in cryptography. No, I'm not a math or
>crypto guy, but I do believe that demonstrating how prime numbers are
>used in cryptography can spark the interest of young students.
> Someone once showed me how an initial key exchange can be negotiated
>in plaintext by using formulas and prime numbers, but I can't remember
>who, or enough of the examples to make sense. This was in the context
>of ssl, Diffie-Hellman, or something along the line of PKI.
> If you can point me in the right direction, I'd appreciate it!
I posted this on another thread a little while back. I wrote it a little
program to do the calculations for small numbers which I can mail on
request. (Borland C++).
Alice and Bob wish to establish a key.
They agree on a large prime p and a root r. Alice chooses secretly a large
number a and Bob chooses a large number b. (both < the prime).
Alice calculates r^a mod p and publishes it.
Bob calculates r^b mod p and publishes it.
Alice computes (r^b )^a mod p and obtains the key s.
Bob computes (r^a )^b mod p and obtains the key s.
So - for some small numbers -
p = 7 r=3
Alice chooses 3 and Bob chooses 5
Alice calculates 3^3 = 27 . mod 7 = 6
Bob calculates 3^5 = 243 . mod 7 = 5
Both are published.
Alice calculates 5^3 = 125 . mod 7 = 6.
Bob calculates 6^5 = 7776 . mod 7 = 6.
or for a bit larger numbers:
p = 46337 r=71
Alice chooses 537 and Bob chooses 197
Alice calculates 71^ 537 mod 46337 = 16906
Bob calculates 71^197 = mod 46337 = 12543
Both are published.
Alice calculates 12543^537 mod 46337 = 37289
Bob calculates 16906^197 mod 46337 = 37289
Without knowing the numbers Alice and Bob chose it is quite difficult for
him to derive s although doable. With larger numbers s would be secure.
s might be an unusable result so prior agreement would have to deal with
such cases.
The method was developed in 1976 by Whitfield Diffie and Martin Hellman in
1976.
=====BEGIN PGP SIGNATURE=====
Version: 6.5.1ckt
Comment: KeyID 0xACEC0DE1 19.2.00 http://pgpkeys.mit.edu:11371
iQA/AwUBOLILs2kmQi6s7A3hEQLZBgCeM9TjBWaGuaARWxl/seRobylQqnQAn2Va
b/hyg2e+uPBH4Jn0xCgLsqZN
=RTmn
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Dave Hazelwood)
Subject: Re: Swapfile Overwriter: R.I.P.
Date: Tue, 22 Feb 2000 05:48:54 GMT
Steve,
Then SecureClean is what you want. It does it all including
shutting down to DOS to clean the swap file.
www.AccessData.com
[EMAIL PROTECTED] (Steve K) wrote:
>On Mon, 21 Feb 2000 03:01:38 GMT, [EMAIL PROTECTED] (Dave
>Hazelwood) wrote:
>
>>Go get Scramdisk....it has one to wipe both freespace and
>>the swapfile.
>
>Got Scramdisk & like it a lot. The "wipe swapfile slack" dingus is
>probably OK, but the manual only says:
>
>"Any slack left when the swapfile contracts may contain data,
>overwriting the slack securely clears any data in it."
>
>Judging by the info displayed during the Scramdisk overwrite process,
>and the (very brief) time it takes to finish, I am assuming that there
>is one overwrite with a fixed pattern, done by overflowing the system
>RAM with data in the wiping pattern. Then when the maximum amount of
>data that can be written is in there, Scramdisk closes, freeing up the
>space that it just ate in the swap file. That's OK as far as it goes
>and lots better than nothing.
>
>But I still like having a little dedicated app that eats the entire
>swapfile, with multiple overwrites. This is not possible during a
>Windows session, hence the "slack" that is overwritten by Scramdisk,
>not the whole "swap file". Anything in there that is "in use" by an
>application, won't be touched. That's probably nothing to panic
>about, but some crypto nuts just hate loose ends... especially when
>there are easy ways to avoid leaving them.
>
>It's possible to recover data from overwritten disk space, but the
>process is expensive and uncertain. The better the overwriting
>method, the more expensive and less certain the recovery becomes. I
>always like to make worst case assumptions where crypto stuff is
>involved, so I put the "wipe swapfile slack" function of Scramdisk in
>a whole other category than overwriting with (for instance) Scorch.
>
>So I still want a Swapfile Overwriter replacement to point the newbies
>at...
>
>:o)
>
>
>Steve
>
>---Continuing freedom of speech brought to you by---
> http://www.eff.org/ http://www.epic.org/
> http://www.cdt.org/
>
>PGP key 0x5D016218
>All others have been revoked.
------------------------------
** 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
******************************
