Cryptography-Digest Digest #76
Cryptography-Digest Digest #76, Volume #14Wed, 4 Apr 01 14:13:01 EDT
Contents:
Re: patent this and patent that (Vernon Schryver)
PGP Private key cracking service ("Peter")
Re: Security of IAPM, alone. (Shai Halevi)
Re: PGP Private key cracking service ("Tom St Denis")
Re: PGP Private key cracking service ("James Wyatt")
Re: PGP Private key cracking service (Jim Gillogly)
Re: PGP Private key cracking service ("Sam Simpson")
Re: PGP Private key cracking service ("Tom St Denis")
Re: PGP Private key cracking service (Roman Katzer)
Encrypted Swap in Linux 2.4 - Was supposed to work since 2.4.2ac8 or something...
Anyone have any luck with this? (~JennyDriver)
Re: How do I exchange the values of A and B (Mikito Harakiri)
Re: keys and random (David Wagner)
Re: Security of IAPM, alone. (David Wagner)
Re: Factoring (Stefan Katzenbeisser)
Re: Matrix PK idea? (Mike Rosing)
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: patent this and patent that
Date: 4 Apr 2001 09:18:32 -0600
In article [EMAIL PROTECTED], Terry Ritter [EMAIL PROTECTED] wrote:
...
Patents are complex legal documents constructed by humans, granted by
humans, and administered by humans. Of course there are going to be
problems. Legal systems are inherently inconsistent. Do you really
imagine that we should not be overjoyed by any legal ownership process
which has problems in only 1 in a million cases? Wouldn't life be
nice if everything was perfect?
Yes, that's what patent lawyers tell suckers buying their tickets
in the patent lottery.
In reality, I expect there are lots more examples of patent problems.
But, in general, the system creaks along, despite having what I think
is our major government example of an "old-world-style bureaucracy."
Yes, but those who are intellectually honest ask what the system is
trying to accomplish as it creaks along. The history of of software
patents demonstrates that fostering innovation is not only not one
of its goals, but one of the things that it tries to stop and prevent.
Other great examples include the Motorola-Codex patent on TCP/IP
header compression whose only problem was that it was filed after
that stuff was already shipping,
Unless things have changed recently, as far as I know it is perfectly
reasonable to file for US patent up to a year after implementations
are shipped.
In this case the "shipping" had nothing to do with Codex, but included
the discussion and publication in a standards committee. Those facts
might be why Motorola-Codex conveniently ignored TCP/IP header
compression while it was trying to stop the standardization of PPP
data compression by the IETF, and why that patent faded.
or the other Motorola-Codex patent
that essentially patents x.25 only 20+ years too late.
Well, "essentially" is the problem. To know what a patent really is,
one has to examine the actual claims in detail. It is very
appropriate to take prior art, modify it, and then patent the modified
scheme. Patenting individual ciphers is sort of like that.
Yes, that's what the patent lawyers tell suckers buying tickets in
the patent lottery. It's also what big companies' patent lawyers
tell courts when fielding blocking patents.
I have seen patents that I think were worthwhile. For example, I
disagree with many and think the infamous LZW patent was about a
genuinely novel idea. However, the existence of the IBM patent on
the same idea, the earlier date on the IBM patent, the history of
Unisys's efforts to profit from the Welch patent are eloquent
statements about other evils of the system.
I wonder how many patents are as bad as those or the various "blocking"
patents seen in the 19th Century history of firearms and the late 20th
Century history of ink jet printers.
The whole point of the ideal patent document is to construct a
limited-term monopoly. Unless a patent is a monopoly, it does not
force someone to license it. When a patent can be "engineered
around," some people are not paying for the research which lead to the
patent.
The point of those blocking patents was to prevent innovation. They
had nothing to do with compensating inventors or fostering the development
of science and technology. The idea is that while you're setting up
your factory, your look for and patent all of the other ways you can
find to make your product as well as products that serve similar purposes.
You don't do any real research or inventing, but merely try think of
all of the obvious ways that a competitor could compete. The idea is
to create a monoploy, but it is antithetical to the nominal purpose of
patents, which is something about fostering innovation.
...
Normally, assuming basic requirements are met, the PTO just grants the
patent. If the patented thing
Cryptography-Digest Digest #76
Cryptography-Digest Digest #76, Volume #13Thu, 2 Nov 00 15:13:00 EST
Contents:
Re: Crypto Export Restrictions (Anthony Stephen Szopa)
Re: Crypto Export Restrictions (Anthony Stephen Szopa)
Re: Is RSA provably secure under some conditions? (Philip MacKenzie)
Re: 3-dimensional Playfair? (Mok-Kong Shen)
Re: Newbie about Rijndael ("Brian Gladman")
Re: BENNY AND THE MTB? ([EMAIL PROTECTED])
Re: Certicom's ECC Implementation (DJohn37050)
Re: Is RSA provably secure under some conditions? (Jan Fedak)
Re: Open Request to Dr. Kaliski, Jr. at RSA Research - looking for your Thesis!
([EMAIL PROTECTED])
Re: Crypto Export Restrictions (Scott Craver)
Re: BENNY AND THE MTB? (Bryan Olson)
Re: Give it up? (Tom St Denis)
From: Anthony Stephen Szopa [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech,alt.hacker
Subject: Re: Crypto Export Restrictions
Date: Thu, 02 Nov 2000 10:40:32 -0800
David Schwartz wrote:
Anthony Stephen Szopa wrote:
Suspect?
Anyone who would make such a claim and not support it is clearly a
nasty person.
I'll let people judge for themselves, but the following statements on
your web site are not exactly encouraging:
"Uses no mathematical equations"
"We claim that messages properly encrypted using the full implementation
of OAP-L3: Original
Absolute Privacy - Level3 © (patent pending) encryption software are
practicably unbreakable. If you
can demonstrate a generally practicable systematic method for
consistantly breaking these encrypted
messages within 180 days from your date of purchase you will recieve a
full refund."
"The next upgrade, Version 4.3, will include three new routines to
process the random array files called
MixFiles: 1) a shift routine where the user may decide to shift each
element value within an array left or
right by 1 to 9 elements, 2) a "flip" routine that will reverse the
order of array element values in each
array, 3) an add routine where each array element value consisting of a
digit from 0 - 9 will have a user
determined number from 1 - 9 added to it, with any result exceeding 9
having 10 subtracted from it."
"Let me emphasize again using the first example above: your key will
generate 2920 data bytes. And
these 2920 data bytes will have a security level equivalent to 2000 bits
and enable you to encrypt
9.2E15 bytes. Can you spare the space on your hard drive to store 2920
bytes?"
"Okay. So now you have generated the original encryption data file
containing all 3,628,800 possible
ten-digit permutations of the digits 0 - 9 with no repeats in ascending
order. How will this file be used?
To generate the random numbers that will ultimately be used to create
the OTP files, three files
containing 3,628,800 ten-digit permutations of the digits 0 - 9 with no
repeats are required. They will
be called MixFile1.otp, MixFile2.otp, and MixFile3.otp. Each of these
files must be thoroughly shuffled.
That is to say, the permutation order must be randomly rearranged in
each file. There are several
processes the software uses to shuffle the permutation order in each
MixFile(X) individually, and one
that shuffles the MixFile(X)s all together."
If course, the biggest problem is that no explanation is given of where
the randomness actually comes from. You can mix numbers to get random
numbers, but you need randomness in order to mix. Where does the initial
randomness come from? No clue.
DS
You asked the $64,000 question. This is why I posted all the Help
files on the web site.
If you want secure encryption enough you should begin reading them.
They are not very long.
Obviously you have read some of the material.
It is all there. You did not quite read far enough.
From the Theory web page:
"Here are a few practicable solutions to your random number needs.
Get two decks of standard playing cards. Each deck has four suits
from Ace - King and two Jokers. Take two jokers from one deck and
place it in the other deck. With a pen assign one of the four suits
to each Joker. So now you have one deck with 56 cards with four
suits and 14 cards per suit."
Search the Theory web page for this text then read further.
--
From: Anthony Stephen Szopa [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech
Subject: Re: Crypto Export Restrictions
Date: Thu, 02 Nov 2000 10:42:14 -0800
CiPHER wrote:
In article [EMAIL PROTECTED],
Anthony Stephen Szopa [EMAIL PROTECTED] wrote:
Anyone who would make such a claim and not support it is clearly a
nasty person.
*waggles fingers* OoooOOOooo! 'Nasty person'! lol
--
Marcus
---
[ www.cybergoth.cjb.net ] [ alt.gothic.cybergoth ]
Sent via Deja.com http:/
Cryptography-Digest Digest #76
Cryptography-Digest Digest #76, Volume #11Tue, 8 Feb 00 21:13:01 EST
Contents:
Re: Quicken (was Re: Strip Security) (Michael Wojcik)
Re: permission to do crypto research (Jerry Coffin)
Re: permission to do crypto research ("Jeffrey B. Siegal")
A query method for communications ... ("Markku J. Saarelainen")
Re: Compression cannot prevent plaintext recognition (was Re: is signing a
signature with RSA risky?) ("Joseph Ashwood")
Re: permission to do crypto research ("Jeffrey B. Siegal")
Re: Blowfish Question ("Chung W Leong")
Language Challenge 2000 ([EMAIL PROTECTED])
Re: Seeking Information on FRACTAL CRYPTOGRAPHY (Tom St Denis)
Re: Message to SCOTT19U.ZIP_GUY (Tom St Denis)
Re: permission to do crypto research (Bill Unruh)
Re: free C crypto API (Tom St Denis)
Re: DVD crypt Q (Bill Unruh)
From: [EMAIL PROTECTED] (Michael Wojcik)
Subject: Re: Quicken (was Re: Strip Security)
Date: 8 Feb 2000 23:38:10 GMT
Reply-To: [EMAIL PROTECTED]
In article [EMAIL PROTECTED], David Hopwood [EMAIL PROTECTED]
writes:
Michael Wojcik wrote:
[re Quicken servers configured for stupidly small passwords]
There doesn't appear to be any locally stored key, and there's no
evidence during account creation that Quicken is gathering entropy
for a crypto-secure PRNG. Actually, I can't see any way there could
be a hidden key: Quicken can be installed on another computer and
the account access enabled from there with only the four-digit
passphrase. There's no mechanism for transporting a hidden key.
Oh dear. Anyone want to bet that this can be broken just by sniffing
a *single* session and doing an off-line attack? I don't know precisely
what protocol Quicken uses, but if it's just RSA authenticated by the
PIN, it won't be secure against this.
I was thinking of older versions of Quicken, which used direct
dial-up to the server, making sniffing rather less likely. (Anyone
with enough money in their checking account to justify tapping
their phone line and recording their Quicken session probably isn't
using Quicken.)
More recent versions of Quicken do indeed use TCP/IP as their
transport, making sniffing attacks much more likely. It's
possible that Quicken is using SSL, but again I don't see any
evidence of it.
Hopefully, Quicken servers lock account access after a certain (small)
number of access failures, which makes this kind of brute forcing
impractical.
That may not be enough.
No, if the session can be recorded.
I agree completely. Generally speaking, the short passwords required
by some Quicken servers are sooner or later going to be used in an
environment where they're subject to attack. If the session isn't
sniffed, someone else will get hold of the computer and turn on
Winsock tracing or Quicken's own session logging or the like. Access-
failure lockout is only a defense against the most trivial and obvious
brute-forcing.
--
Michael Wojcik [EMAIL PROTECTED]
AAI Development, MERANT (block capitals are a company mandate)
Department of English, Miami University
Pseudoscientific Nonsense Quote o' the Day:
From the scientific standpoint, until these energies are directly
sensed by the evolving perceptions of the individual, via the right
brain, inner-conscious, intuitive faculties, scientists will never
grasp the true workings of the universe's ubiquitous computer system.
-- Noel Huntley
--
From: Jerry Coffin [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,misc.int-property,misc.legal.computi
Subject: Re: permission to do crypto research
Date: Tue, 8 Feb 2000 17:51:25 -0700
In article 87q97u$nlp$[EMAIL PROTECTED], [EMAIL PROTECTED]
says...
[ ... ]
You'll just be able to take the digital output of your
future DVD player, that would normally hook up to your future
digital TV, plug it into your future computer and save the feed.
"future"? Quite a few DVD players have digital outputs right now.
You don't have to wait for a fast digital input on your computer to
use it for pirating either: it'll feed a current digital VCR.
Why muck about with decryption software?
Good question...better than you apparently realized.
Sure: just because it now runs on Windows doesn't mean it wasn't
_intended_, by its creator, for watching DVDs on Linux.
For that matter, why should one particular company be given a monopoly
over players on Windows? I happen to think the XING player is
disgusting...
--
Later,
Jerry.
The universe is a figment of its own imagination.
--
From: "Jeffrey B. Siegal" [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,misc.int-property,misc.legal.computing
Subject: Re: permission to do crypto research
Date:
Cryptography-Digest Digest #76
Cryptography-Digest Digest #76, Volume #9Sat, 13 Feb 99 00:13:03 EST
Contents:
Re: New high-security 56-bit DES: Less-DES ([EMAIL PROTECTED])
Re: RNG Product Feature Poll (R. Knauer)
Re: Transforming RC4 into a one-way hash function (Bauerda)
WW-2 German Enigma Machine For Sale (webb)
Re: New high-security 56-bit DES: Less-DES ("lyal collins")
Re: Transforming RC4 into a one-way hash function ("Peter K. Boucher")
Re: Program Idea (Casey Sybrandy)
Re: SCOTT COMPRESSION ("Eric W Braeden")
Re: RNG Product Feature Poll (Patrick Juola)
Re: hardRandNumbGen (Patrick Juola)
Re: Metaphysics Of Randomness (Patrick Juola)
Re: RNG Product Feature Poll (Patrick Juola)
Re: *** Where Does The Randomness Come From ?!? *** (Patrick Juola)
From: [EMAIL PROTECTED]
Subject: Re: New high-security 56-bit DES: Less-DES
Date: Fri, 12 Feb 1999 23:29:29 GMT
[EMAIL PROTECTED] wrote:
2. To send a message to Alice, Bob forms the first part of his
desired message as a plaintext block of 64 bits:
M1 = 0123...63
I'd suggest the first block should carry 64-M bits of plaintext
(like the others) and M bits of random padding, in order to
resist known plaintext attack. If we can't add random bits, for
fear they will be deemed "key", we could defend against partially
known plaintext by taking the M-bit pad from a hash of the entire
message.
The Less-DES protocol may answer concerns regarding possibly
diverging interpretations of export-free or WA terms -- since there
is no additional key in Less-DES, of any kind, not even ignored, when
security is enhanced from the 56-bit level.
Alas, the way the regulations are implemented in the US, it's the
government's interpretation that carries the day. The rules do not
say that 56-bit or even 40-bit encryption systems are freely
exportable, and neither does the latest statment of intentions to
"relax" export restrictions.
Instead, there's a "one-time review". The various agencies are under
no obligation to permit export based on adhearence to the letter of
the WA or even the agencies' own guidlines. If one wants to argue
that a system falls within legal limits, he'll be making that argument
to government cryptographers.
In 1995, Kent Briggs sought to export of a system using 40-bit
Blowfish. He was told he'd have to cut it to 32 bits. Given the
relative key agility of Blowfish versus ciphers that did receive
fast-track export approval, we can conclude that the reviewers
looked at how long the system would actually take to break, and
not merely at technical conformity to key length limits.
Since that time, export authority for civilian encryption
software has ostensibly moved to the Department of Commerce. In
practice this means that people who know nothing about crypto have
a chance to deny (but not approve) export before the request even
crosses the desk of anyone who knows what he'd doing.
--Bryan
= Posted via Deja News, The Discussion Network
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
--
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: RNG Product Feature Poll
Date: Sat, 13 Feb 1999 00:33:38 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 12 Feb 1999 15:02:45 -0700, "Tony T. Warnock"
[EMAIL PROTECTED] wrote:
The probability of a 1-bit is 1/2. The probability of a 0-bit is 1/2. These are
taken over the entire sequence. The excess of 1-bits over 0-bits in the first N
bits is approximately N/log(N). This means that the frequency is 1/2 + 1/Log(N)
for 1-bits.
I thought the Champernowne number was only defined for an infinite
number of bits.
The absolute excess grows but the relative excess (which is the
probability in the limit) goes to zero.
1) What is meant by "absolute excess"?
2) What is meant by "relative excess"?
3) What does any of this have to do with the infinite Champernowne
number?
Bob Knauer
"The one thing every man fears is the unknown. When presented with this
scenario, individual rights will be willingly relinquished for the guarantee
of their well being granted to them by their world government."
--Henry Kissinger
--
From: [EMAIL PROTECTED] (Bauerda)
Subject: Re: Transforming RC4 into a one-way hash function
Date: 13 Feb 1999 00:35:51 GMT
You want to overcome RC4's weakness that the last few bytes of a long
key have less effect than the first few bytes, right? What do you think
of the following?
1) At the time your hashing software is being developed, generate 1013
"random" bytes, R, and hard-code them into your software.
Why bother with that many? I would say that only 8 to 256 bytes would be more
resonable.
2) At run-time,
a) take the message, M, and make a copy in the reverse-order, call it
rM
b)
