Cryptography-Digest Digest #103, Volume #9 Thu, 18 Feb 99 16:13:03 EST
Contents:
Re: Decoding messages from ETI. (fungus)
Re: 640-bit Modulus Factored. ([EMAIL PROTECTED])
Re: encryption debate (Andrew Haley)
Re: New high-security 56-bit DES: Less-DES ([EMAIL PROTECTED])
Re: Telephone Encryption (Paul Rubin)
Re: Export Laws (Michael Kjorling)
Re: random number generator??? (R. Knauer)
Re: Double-DES, DESX, and instinct (Uri Blumenthal)
Re: Telephone Encryption (Paul Rubin)
MS Certificate Server - Adding Extensions?? ("David Garske - API")
Re: Telephone Encryption ("Trevor Jackson, III")
----------------------------------------------------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Decoding messages from ETI.
Date: Fri, 19 Feb 1999 06:00:11 +0100
WhiteHat wrote:
>
> Greetings,
>
> I am searching for various methods of decoding/understanding a message
> received from an extra terrestrial intelligence (if/when we receive
> such a message). It is presumed that the ETI wants us to read the
> message. Thus, the task of understanding the message is the task of
> learning the "language" used to compose it (i.e. break the code of the
> language).
>
This is a bit impossible to answer, like asking what alien food would
taste like.
> I am looking for ways of "decoding" such a message. Any suggestions
> and/or links would be greatly appreciated.
>
The movie "Contact" had a well done example of this sort of thing...
A few years back, NASA sent a message for extraterrestrials to decipher.
IIRC, the message was a sequence of pulses. If you arranged the pulses
into a grid, you got a two colour image. The width and height of the
image were prime numbers so, based on the total number of pulses, there
was only one way to create the grid. I can't remember what the image
was but it was pretty simple, just enough to let them know we were
intelligent.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 640-bit Modulus Factored.
Date: Wed, 17 Feb 1999 15:28:26 GMT
In article <[EMAIL PROTECTED]>,
Ted Kaliszewski <[EMAIL PROTECTED]> wrote:
> Thank you for your comments. The modulus in question, besides being a pseudo-
> prime, is also a product of two primes that are simply relates as follows:
> p = 2*q -1, according to the proposition made by G. Jaeschke ( Math.Comp.
> 61(1993), pp.915-926. Thus, it can also be factored by solving the corres-
> ponding quadratic equation. However, I stick to my ufm routine since it is
> effective for a more general case of pseudoprime moduli,
Anytime p | q -1 or p | q + 1 (or vice-versa) and N = pq, one can easily
factor N via the p-1 or p+1 algorithm.
It is easy to construct large composites which are of special form that are
easily factored. The trick is to find methods which will factor large,
RANDOMLY chosen integers.
May I suggest you answer the following question:
Let N be a reasonably large (256+ bits) composite. What is the
probability that N can be factored with your method?
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Andrew Haley)
Subject: Re: encryption debate
Date: 18 Feb 1999 17:34:59 GMT
R. Knauer ([EMAIL PROTECTED]) wrote:
: On 18 Feb 1999 15:45:37 GMT, [EMAIL PROTECTED] (Andrew Haley)
: wrote:
: >1. This is off topic in sci.crypt.
: Not really. Govt infringement of personal privacy is every bit part of
: crytpo. DUH!
For crying out loud, read the FAQ:
2.2. Do political discussions belong in sci.crypt?
No. In fact some newsgroups (notably misc.legal.computing) were
created exactly so that political questions like ``Should RSA be
patented?'' don't get in the way of technical discussions. Many
sci.crypt readers also read misc.legal.computing, comp.org.eff.talk,
comp.patents, sci.math, comp.compression, talk.politics.crypto,
et al.; for the benefit of people who don't care about those other
topics, try to put your postings in the right group.
Andrew.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: New high-security 56-bit DES: Less-DES
Date: Thu, 18 Feb 1999 18:44:29 GMT
In article <[EMAIL PROTECTED]>,
Bryan Olson <[EMAIL PROTECTED]> wrote:
>
>
> [EMAIL PROTECTED] wrote:
> > [EMAIL PROTECTED] wrote:
> [...]
> > > 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.
> >
> > Yes, this is a good point. That is why I wrote, in the posting:
> >
> > | The recently discussed methods of
> > | "plaintext hardening" (see Tony Bartoletti's postings) can be used
> > | to advantage[...]
> > The plaintext-hardening techniques discussed in mcg-talk [see archives at
> > http://www.mcg.org.br/emails.htmn] include compression, bit-rotation and XOR
> > with a random 64-bit block (with one random block for the whole msg). Thus,
> > the "hardened" message is not only near to 7 bit/byte in entropy as one
> > varies the tentative key (the maximum limit needed in DES, since it is only
a
> > 56-bit random cipher) but also non-deterministic.
> >
> > So, we are in violent agreement there!
>
> More or less. Compression doesn't help against known plaintext
Yes, and it does not help even against ciphertext-only attack -- see
http://www.mcg.org.br/unicity.htm, with a Huffman coding example.
HOWEVER, please read my full paragraph above and the mcg-talk archives as
provided. Indeed, any method in isolation is weak -- e.g., can you use only
S-boxes in block-ciphers? But note that the designation "plaintext hardening"
denoted NOT a single technique but the joint use of independent, reversible
and key-less transformations such as (compression + bit-rotation +
bit-shifting (diffusion) + random-block XOR with transmitted random-block).
Thus, compression DOES help against known-plaintext attack **IF** you make
the ciphertext on any bit for N 8-byte blocks randomly depend on any
plaintext bit in N blocks -- in the sense that you MUST encrypt N blocks per
trial key, which increases the workload in proportion to the number N of
blocks.
So, in *combination* with the other techniques given above in my reply,
compression DOES improve resilience against a known-plaintext attack.
>and
> a 64-bit XOR block makes the receiver's job harder. A random pad
> in the first block provides uniformity with the other blocks.
This is a common misconception, in two counts:
1. A random pad has 8 bits/byte of entropy and sticks out like a sore
random-thumb among a necessarily lower-entropy message -- since **any**
plaintext encoding must be reversible and known to the attacker.
2. A random pad in the first block will NOT affect the other blocks since DES
works **per block**.
>
> > > > 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.
> >
> > Also in agreement. However, the Less-DES and M-DES methods hopefully serve
to
> > show that you cannot control what you do not have. The enhanced security in
> > Less-DES/M-DES is derived NOT from any amount of shared secret-bits but from
> > *open ignorance* -- which cannot be limitited. It is simply what I don't
tell
> > anyone, not even my friend Alice.
> >
> > Thus, there is NO hope to control security-strength!
>
> I don't see how that follows. If you can't export a system with Less-DES
> any more than you can export 448-bit Blowfish, what's the difference?
The difference is that M-DES (and, its Less-DES variant) is allowed by the
agreed upon written rules of the Wassenaar Arrangement, even when the *users*
decide to use M-DES with an effective 76-bit security to an attacker -- since
they only need 56-bits of shared-secret.
Thus, *any* WA state may affirm that M-DES is export-free while at the same
time that state fully complies with the WA's terms. And, no other WA state
may complain.
Of course, states are free to even ban encryption altogether (as France did,
until recently) but that is not very effective in today's competitive world,
it seems. So, the Less/M-DES alternative is a clean and direct way to allow
strong security even if *all* existing WA rules are followed.
Which is of course not possible for any encryption technique that relies on
more than 56 bits of shared-secret -- like 448-bit Blowfish. But, 56-bit
Blowfish may be used -- as Less/M-Blowfish....within WA terms ... and may
then provide 448-bit of effective key-length if the *users* so choose.
One final comment may help: who makes Less-M/DES stronger than 56-bits? The
user, not the software producer -- which only allows 56-bits of shared-secret.
WA or other export rules can only restrict the capability of the tools that
the users may legally buy. No rule can control what the users may decide NOT
to do (as in Less-DES) with the tool they are allowed have.
Cheers,
Ed Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Telephone Encryption
Date: Thu, 18 Feb 1999 19:33:46 GMT
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>>The chips are now called "Fortezza". They no longer have the
>>"Law Enforcement Access Field" that was so controversial.
>
>Are there any commercial telephones being made with that technology?
Fortezza is actually a pcmcia card. It's mostly been used in the
Defense Messaging System for SBU (sensitive but unclassified)
traffic, from what I understand. I thought it used the Capstone chip
which is a successor to Clipper. I didn't realize it had no LEAF.
Last year the Skipjack and KEA algorithms used in Capstone were
declassified so it became ok to implement them in software or smart
cards. This was apparently because the Fortezza cards were so
expensive, they couldn't buy enough of them for the DMS.
The whole point of Clipper for civilian use was the LEAF. So
there's no particular reason to use it without the LEAF.
If you're looking to buy high quality secure phones I probably can put
you in touch with a guy who has been making some very nice ones at
about $1000 each. Email me if you want this.
If you're looking for something cheap for occasional use, try one
of the software programs.
------------------------------
From: [EMAIL PROTECTED] (Michael Kjorling)
Subject: Re: Export Laws
Date: Thu, 18 Feb 1999 20:00:38 GMT
Reply-To: [EMAIL PROTECTED]
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
The point is that cryptographic programs are not allowed to be exported in
ELECTRONIC form. Suppose I want to export a simple program, of a few thousand
bytes. I could then convert it into ASCII, print it to paper, get it outside
the USA and then scan and reconvert it into computer-executable binaries.
Voila...
If I get caught by the police, I can say as one of my friends said to me once:
"You can always claim that you are a dyslectic, and that you have invented
your own language by compining different elements from finnish, french and
chinese, but you only use it when you're writing"...
//Michael
On Sun, 14 Feb 1999 12:13:27 -0500, "jmp" <[EMAIL PROTECTED]> wrote:
> Question: why not lump all your [cryptographic] source code
>togather into one big file in the Adobe Acrobat format,
>and export that? There would then be NO difference at all except for the
>media. (No difference in layout)
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: PGP 6.0.2i executables: coming soon to a server near you
iQA/AwUBNsreiyqje/2KcOM+EQKm2gCgiu1vSyQC4AFzgQ+qBdTJHnEwu5AAoK0L
uDWdRW4++Z+qVMd0ixMOlPLz
=iJ5O
=====END PGP SIGNATURE=====
_________________________________________
Mann mu� nicht Gro� sein, um Gro� zu sein
=========================================
Remove the x's and replace .ru with .se
in e-mail address to reply
=========================================
PGP Key ID : 0x8A70E33E
Fingerprint: 95F1 074D 336D F8F0 F297
6A5B 2AA3 7BFD 8A70 E33E
http://certserver.pgp.com:11371/pks/lookup?op=get&search=0x8A70E33E
The above mail should not be
considered mine if the PGP signature
cannot be verified with the above key
(which information is included in
each and every of my Usenet posts.)
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: random number generator???
Date: Thu, 18 Feb 1999 19:34:01 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 18 Feb 1999 17:24:46 -0000, "Sam Simpson"
<[EMAIL PROTECTED]> wrote:
>>True random numbers defy any kind of algorithmic characterization,
>>including pseudo-random statistical tests.
>Indeed.
I should have emphasized *finite* random numbers in the statement
above.
>I strongly disagree that just munging text is as good as both text input
>and mouse wiggles (but I can't prove it <g>).
The claim is not that it is as "good", but that it is easier. Because
text has low entropy density it will presumably require more effort to
distill any randomness it has.
But I wonder if keystreams are known to be constructed from hashed
text streams, and the hash is also known, then are the resulting
ciphers really secure. The entropy argument would seem to indicate
that they are in a practical sense if the hashing procedure is done
properly in the sense of distilling the randomness to 100% entropy
density.
Still, since the whole scheme is algorithmic, it leaves me with the
nagging doubt that it is not satisfying the requirements for a
proveably secure keystream - in the sense that it is not satisfying
the specification for a TRNG, namely that it is capable of generating
all possible finite sequences equiprobably.
>>It would seem that it would take more hashing if you left in all the
>>bits. Patrick Juola (IIRC) commented on this the other day, so if he
>>is tuned into this thread, perhaps he (or anyone else) could comment
>>on that.
>I'd rather be conservative (with respect of "entropy bits") rather than
>chuck them away needlessly.
The thing that concerns me is that inclusion of them may restrict the
output of the hash generator in terms of its capability to generate
all possible finite sequences equiprobably.
>Besides, for the intended platform, CPU cycles are cheap.
Agreed.
>I couldn't possible comment.
I admit it was a loaded question. :-)
>People far more adequately equipped have
>looked at SHA-1 and found no weaknesses.
<idle speculation> On the other hand, the hidden regularities in SHA-1
could be so subtle that only the math geniuses at NSA know about them.
What if, for example, that the algorithm reduces to something simple?
IOW, the creators took some simple calculation and made it look very
complex, fooling everyone into thinking it is secure. I realize that a
hash has to be virtually collision free as well as pass pseudo-random
tests, but that could possibly be incorporated into the design without
anyone spotting it. </idle speculation>
When you have the security (and prosperity) of the free-world as your
prime directive, you will do anything and everything to gain the upper
hand - and the NSA is no exception to that rule. I would not want it
any other way myself.
>At creation time, application developers specify the "Events per hash" &
>"Bytes required".
I meant in practical terms you will have to know the entropy of your
input (mouse wiggles, etc.) to know how much to hash it to get 100%
entropy density.
>>>Drop in to c.s.p.d and view his jihad of the month :-)
>>No thanks. There are enough lunatics on sci.crypt for one lifetime.
>:-)
Speaking of the devil - he just surfaced a few moments ago on c.s.p.d
playing the role of the proverbial Net Nanny. It seems like old times
now. <sigh>
Just as the Idiot in Marat/Sade said that you can't have a revolution
without General Copulation, it seems that you can't have a crypto
forum without Ol' Sternlight. :-)
Bob Knauer
"The first principle of a civilized state is that power is
legitimate only when it is under contract."
--Walter Lippmann
------------------------------
From: Uri Blumenthal <[EMAIL PROTECTED]>
Subject: Re: Double-DES, DESX, and instinct
Date: Thu, 18 Feb 1999 15:04:06 -0500
Reply-To: [EMAIL PROTECTED]
John Savard wrote:
> In a thread I started about an attempt to find a cipher which would
> both qualify as a "mode" of single-DES and yet provide improved
> security, unlike the modes described at the time of the DES standard,
> I wound up concluding that I could make a flawed idea work if I made
> use of the basic idea of DESX as well.
>
> Someone noted something I hadn't realized: that while DESX has
> improved security against a brute-force attack, its vulnerability to
> differential cryptanalysis is not appreciably reduced over that of
> plain DES.
If one makes two observations about DES:
- its key schedule is independent of the actual
encryption engine;
- it does not have to stop at 16th round.
then the concept of pseudo-independent subkeys becomes attractive.
See Pragocrypt'96 - "A Better Key Schedule for DES-like ciphers"
by yours truly and Steve Bellovin.
In short, you can have 2^60 differential attack resistance for the
cost of 16-round DES, and be completely invulnerable to diff. and
linear attacks for the cost of 32 rounds. Essentially it will
provide 3DES strength for 2DES computational cost.
One drawback: key setup is slow. On the other hand, we viewed it
as a feature.
--
Regards,
Uri
-=-=-==-=-=-
<Disclaimer>
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Telephone Encryption
Date: Thu, 18 Feb 1999 20:49:45 GMT
In article <7ahrql$tpk$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Paul Rubin) wrote:
>
>> Software (programs that use PC's with audio hardware to encrypt speech):
>> Nautilus, http://www.lila.com/nautilus.html
Nautilus url is actualy http://www.lila.com/nautilus/index.html
(my mistake earlier).
>> I'm most familiar with Nautilus (I worked on it). It comes with
>> source code and has speech coders down to 2400 bps (good for cellular
>> phones). Also, it can work either with modems or over IP. I think
>> the other two are IP-only and don't ship source.
>
>PGPfone is modem-to-modem (over a regular analog line) *and* IP to IP.
>
>PGPfone will work Mac-PGPfone to Windows-PGPfone. Nautilus is PC only.
Nautilus is not PC only. I've used it on Sparcstations. It works
under DOS, Windows, Linux, and Solaris. Porting to other Unixes
shouldn't be hard. There was a guy interested in doing a Mac
port a while back but I don't think anything came of it.
If you want to port it, the source is right there ;-).
------------------------------
From: "David Garske - API" <[EMAIL PROTECTED]>
Subject: MS Certificate Server - Adding Extensions??
Date: Thu, 18 Feb 1999 11:48:07 -0800
I am trying to add Certificate Extensions to my certificates and am having
no luck. Has anyone had any experience doing this?
The server I am placing this one uses very tight security. So far I have
modified the policy module so that request are suspended until approved by
an Admin person at which time they can come back and install their client
certificate. I have all the enrollment form completed with the fields, and
now I can't figure out why this data is not writing. It compiles fine and
the information in the DN goes through OK.
This is some of my sample code I am using:
<%
''Process a Certificate Request
On Error Resume Next
Dim Certificate, DispositionCode, LastStatus,ConfigString, PKCS10
Dim SubmitFlag, GetCertFlag, Attributes, ControlType
Set ICertRequest = Server.CreateObject("CertificateAuthority.Request")
Set ICertConfig = Server.CreateObject("CertificateAuthority.Config")
Set ICertServerPolicy =
Server.CreateObject("CertificateAuthority.ServerPolicy")
ConfigString = ICertConfig.GetConfig(0)
PKCS10 = Request.Form("CertRequest")
SubmitFlag = Request.Form("SubmitFlag")
GetCertFlag = Request.Form("GetCertFlag")
Attributes = Request.Form("CertAttrib")
ControlType = Request.Form("ControlType")
if PKCS10 <> "" then
DispositionCode = ICertRequest.Submit(SubmitFlag, PKCS10, Attributes,
ConfigString)
LastStatus = 0
LastStatus = ICertRequest.GetLastStatus()
Session("CertStore") = Certificate
end if
%>
<%
''Set Certificate Extension
RequestID = ICertRequest.GetRequestId()
FirstName = Request.Form("FirstName")
ICertServerPolicy.SetCertificateExtension ConfigString, RequestID,
FirstName, PROPTYPE_STRING, 0, FirstName
LastName = Request.Form("LastName")
ICertServerPolicy.SetCertificateExtension ConfigString, RequestID,
LastName, PROPTYPE_STRING, 0, LastName
%>
Any input would be grateful. I am at the end of this project and am running
out of time. Thanks in advance!
------------------------------
Date: Thu, 18 Feb 1999 16:09:01 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Telephone Encryption
Paul Rubin wrote:
> In article <7ahrql$tpk$[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]> wrote:
> >In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (Paul Rubin) wrote:
> >
> >> Software (programs that use PC's with audio hardware to encrypt speech):
> >> Nautilus, http://www.lila.com/nautilus.html
>
> Nautilus url is actualy http://www.lila.com/nautilus/index.html
> (my mistake earlier).
Not Found at 1999-Feb-18 16:08...
------------------------------
** 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
******************************
