Cryptography-Digest Digest #762, Volume #10 Sat, 18 Dec 99 16:13:01 EST
Contents:
Re: NSA competitors (Crypto-Boy)
Re: Analogue encryption (Mr. Eli Y. Kano)
Re: First Bijective Arithmetic Compression (SCOTT19U.ZIP_GUY)
Re: Q: BBS (Mok-Kong Shen)
Re: The 20 years periods did apply to 2 of the 3 patents. Why not for RSA ? (Rich
Wales)
Re: DES as pseudo random number generator (Guy Macon)
Re: Enigma - theoretical question (Jim)
Re: Analogue encryption (Jim)
Re: question (Jim)
MD5SUM for gnupg please anyone?
Re: Keystrokes monitored/encryption useless (Guy Macon)
Re: DES key safety (Jerry Coffin)
Re: Euclid Algorithm (Jerry Coffin)
Re: Attacks on a PKI (Peter Gutmann)
----------------------------------------------------------------------------
From: Crypto-Boy <[EMAIL PROTECTED]>
Subject: Re: NSA competitors
Date: Sat, 18 Dec 1999 16:56:36 GMT
> The Russian one, under the acronym FAPSI, now even has a web site too.
Where is this web site?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mr. Eli Y. Kano)
Subject: Re: Analogue encryption
Date: Sat, 18 Dec 1999 17:10:37 GMT
"Gary" <[EMAIL PROTECTED]> wrote:
>Isn't this insecure as the inverse transform can be found by guessing that
>alot of the voice will have silence?
Lrf.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: First Bijective Arithmetic Compression
Date: Sat, 18 Dec 1999 18:40:00 GMT
In article <83gb7h$95i$[EMAIL PROTECTED]>, "Gary" <[EMAIL PROTECTED]>
wrote:
>Compression and encryption are seperate subjects and mixing the 2 just
>creates a headache when analysing the security of such a scheme.
>For instance I noticed in your original decompression scheme rules were
>introduced to get around illegal decompression.
I am not exactly sure what you mean by "illegal decompression"
since the program does not add information and one can prove that it
does not add information. The problem that you and John Savard can't
seem to comprehend is that though mine for example is standard huffman
compression one most apply some logic at the end of file to get it to match
the fact that real world file are multiplys of 8 bits. You seem to be under
the false illusion that the whole file has to fit some preconcieved notion
and that something has to be added at the end of file to let one know where
the compression has ended. But since mine follows the fact that
Decompess(Compress(X))=X and Compress(Decompress(X))=X
for any X this shows that no information is added to file and that
some sort of optimal file ending treatment was applied. It is only
illegal in your limited view of compression. But if you can find an example
where my compress h2com.exe and decompress h2unc.exe do not
follow the properties mentioned about then I made a mistake.
>Do you randomly introduce anamolies during compression to set off these
>rules when decompressing? If you don't an analyst would home in on the non
>rule breaking decompressions.
What are you babbling about there are no randomly introduced anamolies
quite the opposite this stuff lacks the information that other compression
methods add to a file when compressing.
>Also mixing the 2 affects the efficient implementation and development of a
>good compressor.
>Don't say you can still use another efficient compressor before hand as your
>compressor then just becomes a dubious all or nothing transform.
>
>
>
You have lost me. what dubious all or nothing transform
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: BBS
Date: Sat, 18 Dec 1999 19:43:33 +0100
Terry Ritter wrote:
>
> I give the general requirements for BB&S in Sect. 4.4, the X^2 mod N
> generators:
>
> http://www.io.com/~ritter/ARTS/CRNG2ART.HTM#Sect4.4
>
> Here is the major part:
>
> "N is to be the product of two large distinct primes, P and Q. Both P
> and Q are to be congruent to 3 mod 4, and must also be special (p.
> 378). Prime P is special if P = 2P1 + 1 and P1 = 2P2 + 1 where P1 and
> P2 are odd primes. The paper gives 2879, 1439, 719, 359, 179, and 89
> as examples of special primes (but 179 and 89 appear to not be
> special, while 167, 47 and 23 should be). As yet another condition,
> only one of P1, Q1 may have 2 as a quadratic residue (P1, Q1 are the
> intermediate values computed during the "special" certification). If
> we mark such particular special primes with an asterisk ("*"), we get,
> for example: 23, 47*, 167, 359, 719*, 1439*, 2039, 2879*, 4079*,
> 4127*, etc. Accordingly, N = 719 * 47 fails the additional condition,
> because both special primes are particular. Presumably, these
> detailed conditions guarantee the existence of long cycles, but they
> do not banish short ones. "
>
> I also give a summary of some experimental "BB&S" generators which do
> not behave as we would like to believe all possible BB&S systems must
> behave in Section 7.2.2:
>
> http://www.io.com/~ritter/ARTS/CRNG2ART.HTM#Sect7.2.2
>
> This is not rocket science, folks. Anybody who can program a computer
> can build simple BB&S systems and count their cycles and cycle
> lengths. Obviously, we can do this only for *small* BB&S systems, but
> BB&S is a scalable *mathematical* structure which we can scale to our
> advantage.
>
> The results are indisputable. The only argument which remains is
> whether a *possibility* of weakness (caused by a desire to avoid
> certifying x[0]) is acceptable in any design which we want to see as
> having *proven* security. In my view, such a possibility proves the
> contrary, that such a structure may *not* be secure. And this is the
> sort of thing the major crypto references choose not to discuss.
If I don't err, you confirmed my previous conjecture that it can't
be absolutely guaranteed that for any Blum integer n, however
carefully chosen (excepting through exhaustive tests), there are no
seeds that can lead to very small loops. In fact, it seems to be hard
to find any (at least simple) approach that has the potential to
prove that the congruence x^(2^m) = x mod n has no solution for
small m. (Such unsolvability issues are generally quite hard to deal
with in number theory, as far as I am aware.) You have quite
clearly expressed your opinions on your page. However the common
literatures give one a different impression. In total I personally
consider it unfortunate that a false image of 'non-plus-ultra' in
crypto random number generation has been built up for BBS.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Rich Wales)
Crossposted-To: alt.security.pgp
Subject: Re: The 20 years periods did apply to 2 of the 3 patents. Why not for RSA ?
Date: 18 Dec 1999 10:59:11 -0800
Kent Briggs wrote:
> When the rule changed in 1995, it said that existing patents
> would get protection 17 years after they were granted or 20
> years after they were filed, whichever was longer.
Right. The RSA patent application was filed in 1977, but the patent
wasn't actually issued until 1983. Because of the unusually long
period of time between filing and issuance, the patent kept its original
expiration date (17 years after issuance -- i.e., 20 September 2000).
Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/
See http://www.webcom.com/richw/pgp/ for my PGP key and fingerprint info
*** NOTE: any key generated by me before 1997-09-18 has been REVOKED ***
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: DES as pseudo random number generator
Date: 18 Dec 1999 14:15:02 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Douglas A. Gwyn) wrote:
>
>Markus Eiber wrote:
>> As you know one-time-pad is a cipher with perfect secrecy.
>> How about a one-time-pad using a DES generated pseudo random number
>> sequence?
>
>You contradict yourself.
Like my mum said when I told her that I was
going to grow up and become an Engineer:
"Make up your mind, son. You can be one
or the other, but not both."
------------------------------
From: amadeus @DELETE_THIS.netcomuk.co.uk (Jim)
Subject: Re: Enigma - theoretical question
Date: Sat, 18 Dec 1999 19:21:23 GMT
Reply-To: Jim
On Fri, 17 Dec 1999 15:10:48 GMT, [EMAIL PROTECTED] (Johnny Bravo) wrote:
>On 17 Dec 1999 17:53:22 GMT, [EMAIL PROTECTED] (UBCHI2) wrote:
>
>>If you are going to use the enigma software that you can download off the
>>internet, you should rewire the rotors to a custom pattern. The wiring of the
>>rotors can be an important secret.
>
> Given that and the other conditions he used above, like not putting
>three test letters repeated twice at the start of every message, and
>not putting known plain text at the start of every message, it should
>be pretty secure for short messages.
Or 'section' the message: split it in two, code the second half first
followed by the first bit.
>Much more secure than the actual Enigma as the Germans used it, since they
>broke all the above rules on a regular basis.
Agreed. But the Germans were using it very much more heavily than
we are proposing here.
------------------------------
From: amadeus @DELETE_THIS.netcomuk.co.uk (Jim)
Subject: Re: Analogue encryption
Date: Sat, 18 Dec 1999 19:21:24 GMT
Reply-To: Jim
On Sat, 18 Dec 1999 12:34:52 -0000, "Gary" <[EMAIL PROTECTED]> wrote:
>In old B&W films telephone conversations were scrambled.
>Since digital modems weren't around then what did they do?
>Did they overlay waveforms over the voice?
In some system they did superimpose waveforms at the sending end
and subtract them out at the receiver. I.e. the ciphony system
Turing was working on at the end of the war.
The more usual analogue type is a band-splitter with shuffling
or a splitter with shuffle and time transposition.
Basically the telephone bandwidth (300-3300 Hz approx) can be
split into discrete bands, which can then be put back into the
system in jumbled order, making the speech unintelligible.
A very simple system just inverts the 'phone bandwidth so that
the high frequencies transposed to the low end and the low end to
the high.
>How did they synchronise? Did they have a tracking control on the phone?
Modern systems, such as those used by the Spanish fishermen (analogue
enciphered fishfone!) uses a digital key transmitted within the
telephone bandwidth using frequency-shift (or tone) keying; a new
transposition key is sent with each 'over'.
>If a pseudo one time pad is used to generate a wave form that overlays a
>voice could this ever be as percievably secure as digital encryption?
No. Which is why all serious ciphony systems are digital or at worst
digitally-coded and encrypted vocoders. (And if you've ever used a
secure 'phone incorporating a vocoder, you'll know why I said 'at
worst' !!!)
------------------------------
From: amadeus @DELETE_THIS.netcomuk.co.uk (Jim)
Subject: Re: question
Date: Sat, 18 Dec 1999 19:21:25 GMT
Reply-To: Jim
On Sat, 18 Dec 1999 17:01:50 -0000, "Gary" <[EMAIL PROTECTED]> wrote:
>Chaff and winnowing proposed by Rivest is one example.
>In fact there are also alot of relatively new public key systems that have
>expansion.
By a factor of 2 or 3 ?
------------------------------
From: [EMAIL PROTECTED]()
Subject: MD5SUM for gnupg please anyone?
Date: Sat, 18 Dec 1999 19:24:30 +0000
Hi,
Can anyone please post the MD5SUM for gnupg-1.0.0.tar.gz package.
I downloaded gnupg-1.0.0.tar.gz.asc but can't use it as I
don't have a "trusted" pgp prog. Anyway how do I know that the .asc
file isn't generated with a tampered .tar.gz package? MD5sum of a
"good" package will suffice to check what I have downloaded no?
TIA
gadge
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Keystrokes monitored/encryption useless
Date: 18 Dec 1999 14:25:59 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Liyang
Hu) wrote:
>
>At Thu, 16 Dec 1999 04:56:56 GMT, molypoly <[EMAIL PROTECTED]> said:
>> Take a look at the latest article from Privacytimes.com at
>> http://www.privacytimes.com/dirt_8_17.htm
>> The program is called DIRT and it records all your keystrokes. When
>> you're online, it sends them to the receipient.
>> This means that your keystrokes made while making your encryption
>> keys are now worthless! How would one get around this if this software
>> got into the wrong hands?
>
>I believe a certain program called ScramDisk (for Win9x) gets around this
>little problem by implementing the password entry screen in low-level text
>mode. (the same as when you get the blue screen of death :)
>It may be found at http://www.scramdisk.clara.net/
>
>It's very easy to spot those programs running, as long as you keep an eye
>out for them. <shameless plug>A useful little util, which just happens to
>be called Useful, has a very good process monitor. Anytime I see anything
>running that I dont know the purpose of, I can just kill that process. It
>sees all processes, as opposed to <ctrl+alt+del>, which only shows the
>non-service processes. You can get it at http://www.nerv.cx/hcbd/ </end of
>shameless plug>
I like to run a couple of 30AWG wire wrap wires into the plug on the
back of your PC and connect a Basic Stamp [ http://www.parallaxinc.com/ ]
and have it record keystrokes. It's about the size of a postage stamp,
and there are cool RF transmitter modules available. This allows me to
get the NT Logon password, which no sniffer program can get. For that
matter. there are TX cameras that look through pinholes in your walls
or ceiling. I could make a video of your hands on the keyboard and
of what is displayed on your screen.
If you don't secure your computer physically, I can defeat any security
system you install with little trouble.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: DES key safety
Date: Sat, 18 Dec 1999 13:11:45 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> Jerry Coffin wrote:
> > In article <83der9$g92$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> > > Is DES safe towards the key? I mean if you have the cleartext and
> > > the ciphertext could you derrive the key? Theory and practise is
> > > two different issues, so actually I'm asking two questions.
> > This would be what's called a known-plaintext attack, and no, it's
> > not of much use against DES.
>
> Actually that is not known.
The OP mentions theory vs. practice and really wanting two answers.
In theory, there's a possibility of a known- or chosen- plaintext
attack becoming useful against DES. In practice, there's none
available right now that gives a significant improvement over key
exhaustion.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Euclid Algorithm
Date: Sat, 18 Dec 1999 13:14:07 -0700
In article <RqF64.452$Zi.2883@client>, [EMAIL PROTECTED] says...
[ ... mention of Knuth not discussing modern factoring methods ]
> But on pages 402-3, he mentions Quadratic Sieve, Elliptic Curve Method,
> Number Field Sieve and gives references. I have the (C) 1998 edition which
> has been revised.
Ah, the dangers of making unqualified comments based on an ancient
copy...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Re: Attacks on a PKI
Date: 18 Dec 1999 20:41:24 GMT
Helger Lipmaa <[EMAIL PROTECTED]> writes:
>Secure electronic commerce necessitates wide-scale employment of
>public-key cryptography that, in turn, requires secure and efficient
>methods of certificate management in the \emph{Public-Key
> Infrastructure} (PKI).
You've got this reversed, it's actually:
A PKI requires wide-scale deployment of electronic commerce [0]
That is, without e-commerce as an excuse, PKI vendors will have great
difficulty in selling their wares to users because there's so little
demonstrable need for them. By spreading the misconception that "e-commerce
won't work without a PKI" (so all the PKI-less e-commerce which has been going
on for years, and the squillion dollars of PKI-less e-commerce which analysts
are predicting in the next few years, is all an illusion?), vendors get to sell
their products and services to gullible users.
The real problem with an identity-certificate-based PKI (which is what most
people mean when they say "PKI") is that it's not really useful for much
related to e-commerce because when you're performing a transaction with someone
what you want to know is whether you'll get paid or whether the goods will
ship, and not whether the entity you're dealing with is definitely,
certifiably, digitally-signed-and-authenticated, Joe P.Sixpack the Third. To
use a real-world analogy, when I walk up to the reception desk in a hotel I get
asked for my credit card, not my passport. My identity is irrelevant, all
they're interested in is whether I can pay for my room. A PKI of the type
mentioned above allows you to show your passport, but says nothing about
whether you can pay, or whether you'll receive any goods [1]. This makes this
type of PKI rather inappropriate for e-commerce (consider how many times a year
you use your passport compared to the number of times you use your credit card
or chequebook to get an idea of how useful an identity PKI is in practice).
The real danger of this type of PKI, far more so than any technical attacks, is
that in order to map a PKI-provided name to something you can use, you need to
build a huge parallel infrastructure to do all the things the PKI can't do
(that is, the PKI will tell you "This is X", what you actually want to know is
"Will I get paid by the entity I'm talking to?", and the problem area is
whatever's needed to provide a reply to the question). Even if some sort of
PKI does eventuate, the weak link in the chain will be whatever it is that maps
your PKI-provided digitally signed identity to a payment or goods delivery
capability. You won't need to factor large primes or compromise a CA root
cert, all you need to do is subvert the mechanism which handles the question
"Is the owner of this certificate good for X?".
This is the problem which SPKI tries to solve, it recognises that identity
information is in many cases meaningless (to quote the SPKI docs, "for many
areas of trust management a person's name is irrelevant. A user of a
certificate needs to know whether a given keyholder has been granted some
attribute and that attribute rarely involves a name" ... "The main purpose of
an SPKI certificate is to authorize some action, give permission, grant a
capability, etc"). For more information on SPKI, compare the horrors and
incredible complexity of X.509 certificate chain validation with the elegance
of the SPKI method (there's good introductory coverage at
http://www.clark.net/pub/cme/html/spki-reqts.html). It's kind of unfortunate
that, assuming any kind of PKI ever emerges, it'll be an identity-certificate-
based one - the identity-certificate-PKI side has better marketing resources
than the SPKI guys.
Peter.
[0] Although I wish I could say I'd come up with this :-), it's actually a Carl
Ellison quote.
[1] There have been various attempts to add some sort of usefulness for
handling transactions to this sort of PKI (for example by having extremely
short-lived certs tied to a bank account and issued by the bank which
certify that the account was in good standing the last time they checked,
or something similar), but they're rather hapmered by the fact that the
whole thing really isn't designed for it. I'm not saying they're badly
done, but it's a major task to make a PKI model originally designed for
implementing an electronic telephone directory do anything which is useful
for handling electronic business transactions.
------------------------------
** 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
******************************
