Cryptography-Digest Digest #954, Volume #12 Wed, 18 Oct 00 18:13:01 EDT
Contents:
Re: Storing an Integer on a stream (SCOTT19U.ZIP_GUY)
Re: Huffman stream cipher. (SCOTT19U.ZIP_GUY)
Re: How about the ERIKO-CHAN cipher? (Benjamin Goldberg)
Re: Why trust root CAs ? (Anne & Lynn Wheeler)
Re: x509 (David Wagner)
BIOS password, will it protect PC with PGPDisk against tampering ? (pgp651)
Re: Looking for small implementation of an asymmetric encryption (John Myre)
Re: srp-1.6.0 released (Philip MacKenzie)
Re: ---- As I study Rinjdael... (Cornelius Sybrandy)
Re: Is it trivial for NSA to crack these ciphers? ("Stephen M. Gardner")
Re: Is it trivial for NSA to crack these ciphers? ("Stephen M. Gardner")
Re: Rijndael in Perl (Dido Sevilla)
Re: Is it trivial for NSA to crack these ciphers? ("Stephen M. Gardner")
Re: Is it trivial for NSA to crack these ciphers? ("Stephen M. Gardner")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression
Subject: Re: Storing an Integer on a stream
Date: 18 Oct 2000 20:08:58 GMT
[EMAIL PROTECTED] (Benjamin Goldberg) wrote in
<[EMAIL PROTECTED]>:
>SCOTT19U.ZIP_GUY wrote:
>> >> Take a look if you want an example give me a set of data and I can
>> >> give you the set with the pointer added.
>> >
>> >Ok. Here is my data: I want to encode the pointer 3287 and send it
>> >over a bitstream. What is the string of 0s and 1s that gets sent.
>>
>> Actually the way its encoded is a function of the file. Maybe It
>> would be easier explained if you don't just think of it as added in.
>> But welded in.
>
>Since you refuse to answer my request, I'll make it into a much simpler
>one. Could you give an example [original] file, and an example
>[modified] file?
>
I have anwsered your every request. But I did ask for your to give
an example and you refused. But here is an example like you want
using DSC it is cout an paste the NEWS reader my have screwed it up
so the lines my be twisted. But here it is:
EXAMPLE:
Here is file1.dat in your package note it is
137 charters long
0000 49 20 61 6D 20 74 72 79 69 6E 67 20 74 6F 20 6C *I am trying to l*
0010 65 61 72 6E 20 73 70 61 6E 69 73 68 20 61 6E 64 *earn spanish and*
0020 20 69 74 20 69 73 20 76 65 72 79 20 64 69 66 66 * it is very diff*
0030 69 63 75 6C 74 2E 20 54 68 65 20 6F 6E 6C 79 0D *icult. The only.*
0040 0A 70 68 72 61 73 65 20 49 20 68 61 76 65 20 6C *.phrase I have l*
0050 65 61 72 6D 65 64 20 69 73 3A 20 56 69 76 61 20 *earmed is: Viva *
0060 4D 65 78 69 63 6F 20 43 61 62 72 6F 6E 65 73 21 *Mexico Cabrones!*
0070 20 42 75 74 20 77 68 61 74 20 64 6F 65 73 20 69 * But what does i*
0080 74 20 6D 65 61 6E 3F 0D 0A . . . . . . . *t mean?..*
number of bytes is 137
...
Now lets take same starting file and run BWTQ
In this case the file looks a lot different but know
we have the nasty pointer to combine.
0000 0D 0D 3F 79 21 6F 65 61 2E 3A 49 68 79 74 49 74 *..?y!oea.:IhytIt*
0010 64 64 73 65 6F 74 65 6E 67 6D 73 74 73 74 73 6E *ddseotengmststsn*
0020 20 20 0A 20 20 20 20 76 43 20 65 20 70 65 65 72 * . vC e peer*
0030 68 68 61 69 69 65 6E 20 20 73 76 68 6D 6C 6C 6D *hhaiien svhmllm*
0040 76 6F 6E 4D 69 66 6E 73 77 20 54 70 78 66 64 79 *vonMifnsw Tpxfdy*
0050 20 20 6E 20 20 56 20 20 75 6E 61 20 72 72 61 61 * n V una rraa*
0060 6F 69 61 6F 63 74 64 72 20 73 0A 68 61 61 62 65 *oiaoctdr s.haabe*
0070 74 65 69 65 69 61 69 20 61 69 69 75 6C 20 20 63 *teieiai aiiul c*
0080 42 69 61 20 20 65 6C 72 72 22 00 00 00 . . . *Bia elrr"...*
number of bytes is 141
Next run DSC the "data sensitive combiner" to combine
in a optimal way the pointer to last the result is
below
0000 0D 0D 3F 79 21 6F 65 61 2E 3A 49 68 79 74 49 74 *..?y!oea.:IhytIt*
0010 64 64 73 65 6F 74 65 6E 67 6D 73 74 73 74 73 6E *ddseotengmststsn*
0020 20 20 0A 20 20 20 20 76 43 20 65 20 70 65 65 72 * . vC e peer*
0030 68 68 61 69 69 65 6E 20 20 73 76 68 6D 6C 6C 6D *hhaiien svhmllm*
0040 76 6F 6E 4D 69 66 6E 73 77 20 54 70 78 66 64 79 *vonMifnsw Tpxfdy*
0050 20 20 6E 20 20 56 20 20 75 6E 61 20 72 72 61 61 * n V una rraa*
0060 6F 69 61 6F 63 74 64 72 20 73 0A 68 61 61 62 65 *oiaoctdr s.haabe*
0070 74 65 69 65 69 61 69 20 61 69 69 75 6C 20 20 63 *teieiai aiiul c*
0080 42 69 61 20 20 65 6C 72 45 . . . . . . . *Bia elrE*
number of bytes is 137
In this example the BWT also has the pointer added so
that in this case there is no increase in the original
files data length. The above is just a random test case
Take Care
David A. Scott
The above is a partial example taken from the webpage
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Huffman stream cipher.
Date: 18 Oct 2000 20:27:47 GMT
[EMAIL PROTECTED] (Benjamin Goldberg) wrote in
<[EMAIL PROTECTED]>:
>Because a keyed Huffman coding is a more secure primitive than a
>polyalphabetic substitution, I am proposing an idea to use one as a
>stream cipher. The following is my proposal for generating a psuedo
>random Huffman tree (refered to as a PRHT from now on).
>
>ranmod(x) : a psuedo random number in the range 0..(x-1)
>
>1) Fill a vector with leaf nodes for the values 0..255
>2) Set i=256
>3) j = ranmod(i); k = ranmod(i-1); if(k>=i) ++k;
>4) Join nodes j and k to create a branch.
>4a) Label j 0 and k 1.
>4b) Remove nodes j and k from the vector, and insert the new branch.
> Where the branch is inserted does not matter, provided it is done
> in a consistent way.
>5) if( --i >= 1 ) goto 3;
>
>Assuming ranmod is unbiased, we should have an unbiased selection from
>all of the possible trees. There are, I'm sure, fewer than 256! * 255!
>trees (even taking into account labelings of branches and leaves), but
>how many are there?
>
>The only cryptographic analysis of huffman codes that I know of [MM92]
>depends on the actual statistics of the original plaintext matching that
>of the tree, making it not applicable to this usage.
>
>Since, with some amount of work, part of the tree can be learned if we
>have known plaintext, and can discover where in the ciphertext it's
>corresponding description is, one pass with a PRHT is not sufficiently
>secure. However, breaking up the ciphertext into bytes and enciphering
>using a second PRHT should be sufficiently secure.
>
>Since the 2-PRHT system can still fail through a related plaintext
>attack, and due to the storage requirements for the tree, it would be
>better to use an IV, hash it with the key, use this as the seed of the
>PRBG, and generate a new pair of PRHTs for every message.
>
>For terminating the message, IF the ciphertext does not already end on a
>byte boundary, then the longest symbol in the second PRHT is found, and
>enough bits from it are outputed to fill out a byte.
>
>****
>For those who want me to be less vague, and for me to specify the system
>completely: Assume the IV is 64 bits produced by a TRNG. Assume that
>the key is 128 bits. Assume that the PRNG used is a 120 bit SSLFSR.
>Assume that SHA1 is the hash used to combine IV and key to make the
>SSLFSR seed. Assume that ranmod 32 bits at a time are taken from the
>SSLFSR, and if it's not a good value to get an unbiased result in the
>desired range, it's discarded and a new 32 bit value is taken.
>
>****
>Because of the nature of the system, some messages will expand, and some
>will get smaller. Does anyone want to offer numbers on probabilities
>and amounts of expansion or contraction?
>
>****
>I can't think of any attacks on the key, at all. I can think of a
>chosen plaintext attack on the trees, but this only breaks one message.
>
>Can anyone think of any other (preferably known, not chosen, plaintext)
>attacks on this system?
>
>****
>MM92: "On the Cryptanalysis of Huffman Codes," by Mojdeh Mohtashemi,
>May 1992. http://theory.lcs.mit.edu/~cis/theses/mohtashemi-masters.ps
>
>PS to John A. Malley: Perhaps it was published in June, but page 1 of
>the paper itself says May. Thanks for the link, anyway.
>
Actually a long time ago I proposed very similare stuff
except I prefer to passes in 2 directions through the file
so it more closely approaches an all or nothing type to transform
all it one can use optiomal endings to make bytes endings instead
of what your trying to do. THe code for the above it totally availble
at my site. To do the huffman coding in revese direction of the file
you use the reverse file program that I supply
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: How about the ERIKO-CHAN cipher?
Date: Wed, 18 Oct 2000 21:01:21 GMT
James Felling wrote:
>
> [EMAIL PROTECTED] wrote:
>
> > The ERIKO-CHAN cipher is a private-key cipher.
> >
> > You use the following table to encode a message:
> >
> > 0 1 2 3 4 5
> > -+-----------
> > 0|A B C D E F
> > 1|G H I J K L
> > 2|M N O P Q R
> > 3|S T U V W X
> > 4|Y Z 0 1 2 3
> > 5|4 5 6 7 8 9
> >
> > Then you take your key, a 20-digit (or longer) integer, take its
> > square root, and starting at the decimal point, you take every digit
> > less than 6 until you have as many digits as are in your message.
> > Then you modulo-6-add this to the digits of your message.
> >
> > Could the NSA crack this? Of course, with each message the key must
> > be different.
> >
> > A variation which does not have the "different key each time"
> > weakness is to start your message with a 20-digit number which is to
> > be added to the key before the square root is taken. But I don't
> > have good feelings about it. Unless you send the key *in* code,
> > followed by the message.
You are talking about using an initialization value (IV). The only
problem with this that *I* can see, is that someone might choose the IV
so that IV+key is a perfect square, resulting in an all 0s keystream.
> Yes. I think that they could.
>
> First off the 0-5/0-5 digit split here is our old friend ADFGVX but
> instead of a transposition step there is a stream addition step. The
> major security then lies in your chosen stream. Assuming that the
> method is known, but the key (the 20+digit number) is not there are a
> couple of workable attacks.
> 1) sqrts are not very good random streams. There are often
> correlations in their digits. e or pi or trancendental numbers are
> more likely to have good properties.
The problem with suggesting e or pi, is that both are known values.
> 2) given these correlations and since the digit stream is not
> transposed at all, and therefore is seperable one can make some
> correlative attacks vs. the sqrt stream.
What kind of correlations are there?
> I think it would be challenging to beat, but I also think that there
> would be some quantity of practical attacs vs. it. If you applied
> some form of simple transposition to it at any point post conversion
> this would become stronger. ( such as aligning the output of the
> masked stream in columns beneath the 20 digit number, and using that
> as a transposition key) in that case it becomes ADFGVX masked with a
> Stream.
Although I agree that applying a transposition in addition to the stream
will strengthen it, I don't think that the system ADFGVX uses is
particularly strong. I'm *certain* that it, by itself, it is weak (if
the method is known, and the keylength is known), though having the
stream added may be sufficient to make up for this.
> This will have some benefits. In addition simply for compactness of
> output that the code's output be recombined via the table to the
> numbers and letters.
I've a foolish question: Why wasn't recombination via the table done
with ADFGVX? Making it compact would be just as applicable, I'm sure.
Also, if the method were unknown to the attacker, then leaving it in
*uncompact* form is a partial giveaway wrt the structure of the cipher,
since there being only 6 different symbols in the ciphertext is a bit of
a tipoff to attackers.
--
"Mulder, do you remember when I was missing -- that time that you
*still* insist I was being held aboard a UFO?"
"How could I forget?"
"Well, I'm beginning to wonder if maybe I wouldn't have been
better off staying abo-- I mean, wherever it was that I was
being held." [from an untitled spamfic by [EMAIL PROTECTED]]
------------------------------
Subject: Re: Why trust root CAs ?
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Wed, 18 Oct 2000 21:02:39 GMT
[EMAIL PROTECTED] writes:
> Agreed, but I wasn't proposing that biometric be used except on the
> local device which holds the private key. Ideally this would be a
> tamper proof print recognition smartcard, so people would have the
> convenience of just thumbing their card while it is slotted to
> authorise/authenticate a transaction, but the print recognition data
> would be *not* be held or used anywhere off the card. This way the
> critical authentication info in the wider system is still the key pair
> for which the private key is held on the card, *not* the
> bio-recognition data which is used purely locally to authorise the use
> of the private key.
if we aren't careful ... we'll find ourselves in violent agreement.
--
Anne & Lynn Wheeler | [EMAIL PROTECTED]
http://www.garlic.com/~lynn/
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: x509
Date: 18 Oct 2000 21:13:38 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Bryan Olson wrote:
>[That is, why does the identifier of the signing algorithm
>appear both inside and outside the data under the
>signature?]
>
>I've wondered about that. If anyone knows of some attack
>defeated by identifying the signing algorithm inside the
>signed message, please tell.
>
>For now my theory is that whether the identifier is inside
>or outside the signed data does not matter.
If I understand correctly, you're asking whether there is an attack if
the algorithm-identifier is not mentioned in the signed part? The answer
is Yes, there are attacks.
For instance, MD4 is almost broken. Suppose someone extends Dobbertin's
techniques just a bit, enough to find pre-images for MD4. Now you're
smart: you stopped using MD4 ages ago, and all your signatures take the
form <m, "MD5", Sign(MD5(m))>.
Under the above scenario, there is an attack. Let y = MD5(m). I use
my inversion algorithm to find a preimage m' of y under MD4. Now note
that <m', "MD4", Sign(MD5(m))> is a valid signature on m', which any
receiver will accept. But the original signer never intended for m'
to be signed! Therefore, the message integrity property is violated; QED.
More generally, it is not sufficient that MD5 be collision-free; it is
required that the mapping (h,m) |-> h(m) be collision-free, where the
domain of this mapping is the Cartesian product of the set of recognized
hash functions with the set of possible messages. In other words,
we must also assume that there is no efficient algorithm to find m,m'
such that MD5(m) = SHA(m'), and this property is not guaranteed by the
collision-freeness of MD5 and SHA.
Did I misunderstand your question?
------------------------------
Date: 18 Oct 2000 21:20:48 -0000
From: pgp651 <Use-Author-Address-Header@[127.1]>
Subject: BIOS password, will it protect PC with PGPDisk against tampering ?
=====BEGIN PGP SIGNED MESSAGE=====
When you need to protect PC [ win95/98 is running on it ] against physical
tampering [ to sneak into PC some backdoor software, software key loggers,
replacements of encryption binaries ... ] on PC that has wide & open
physical access to it, what would be the most cost effective solution ?
The people in question are using & are customized with encryption for
e-mail, PGP and with hard disk encryption, PGPdisk.
They have good protection in case of virus infection, the online active
VShield is intercepting all disk activities.
The possible problem of less protected exposure exists when booting process
is transferring access from DOS to WIN operating system. This time all can
be suspended, software added to not encrypted disks [ win95/98 is not
running from encrypted disk ], executables replaced, software installed.
They are very comfortable with PGPDisk encryption and would like to stay
with it when possible.
One of the first option that has been suggested, is BIOS password. It is
very short, about 5 characters long, but it could created about 60 minutes
buffer.
From description how the PC is used, users are estimating that window of
intrusion could be no longer than 60 minutes, except the PC is stolen. In
the event of stolen PC, data is protected by PGPdisk.
The solution they are willing to consider would be in the area of knowing
that tampering occurred instead, when prohibitively expensive, preventing of
tampering with.
Any suggestions would be welcomed.
Thank, pgp651
~~~
This PGP signature only certifies the sender and date of the message.
It implies no approval from the administrators of nym.alias.net.
Date: Wed Oct 18 21:20:41 2000 GMT
From: [EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: 2.6.2
iQEVAwUBOe4ULk5NDhYLYPHNAQHS4wf/UX9w24DKG8AtZZBfgs9trLpZY+YrgeUb
hOJSlhK6jdbxgXnxqu/vRjMi8AsQRuei21uRLRmKj7jwLlIZLlMpNtaCrl6bSKkN
E3aIXTKtye3rc2B4ANMd08iXOEjw145yMMSi76N9gyc0TiVFUvIGti+LZuTQ76Hm
wKTCDuZqaC8luSj/mvB+2QLWBn/ixwEAKMElzUjT1aoMkjWMxcoxuWImAtAbUoJ7
DnWhBKKqGAHpbHdv8W586jz+sMxOWMUJORq4MPpKuWokpIdaKoih9Wfbwuj7pBX9
iFmwHj595dBJTYtltTgny68h+S4Qp5WeeyxJn05GfCpU4X+z3SSEFg==
=0UiU
=====END PGP SIGNATURE=====
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Looking for small implementation of an asymmetric encryption
Date: Wed, 18 Oct 2000 15:20:59 -0600
[EMAIL PROTECTED] wrote:
Ok, I think I see why you are thinking of asymmetric
cryptography. Is your basic situation that you have a
bunch of devices sending data to a central server, and
you don't want anyone snooping on that data? So your
concept is that the devices have a public key, the
server has the corresponding private key, and so only
the server can decrypt what the devices encrypt? Then
the devices don't need to store any long term secrets?
The packet size (49 bits) is simply too small for
encrypting with any known public key algorithm with
any security at all. Either you have to send several
packets for each encrypted set of data, or else you
need to do it some other way. The exact limit depends
on the (presumed) capabilities of your attacker and
how long the data is good for, but I'd think at least
three packets for the lower limit.
The thing about authentication is, could an attacker
benefit somehow by sending fake packets? That is, if
the attacker can find out everything a device knows,
he can act like a device; and the server would have no
way to tell. This may be an unavoidable consequence of
the kind of devices you have. If so, you have to make
sure your system as a whole can deal with spoofing.
Similarly, you mentioned that you don't expect corrupt
data; is it possible for an attacker to corrupt data
on purpose? Is there any advantage (to the attacker)
in doing so?
If your devices cannot keep a long term secret (and I
think this is what you are saying), and you can't require
your user to go around and key them every day, then I
think you are correct that public key techniques are
required. In this case, I see no way of avoiding the
need for messages much larger than 49 bits, even with
the most space-efficient PK around, ECC. As others have
suggested, you can limit the use of PK to an initial key
exchange phase, creating a session key for a symmetric
algorithm.
I don't know of any block encryption algorithms that
handle 49 bit blocks, but it's probably not such a good
idea to do it that way, anyway. You might want to use
something like counter mode, or OFB, or a stream cipher.
In any of these cases you have to deal with synchronization
issues. That is, if a packet is lost or maliciously
deleted or corrupted, can the server figure out how to
decrypt correctly after that?
Take all these suggestions with six or eight grains of
salt; I don't actually know your constraints.
JM
------------------------------
From: Philip MacKenzie <[EMAIL PROTECTED]>
Subject: Re: srp-1.6.0 released
Date: Wed, 18 Oct 2000 17:05:24 -0400
Thomas Wu wrote:
>
> Version 1.6.0 of the SRP distribution has been released. This latest
> release brings the SRP library into full conformance with RFC 2945
> and adds safe parameter checking on the client side, in addition to
> bugfixes and portability enhancements.
>
> Clients using existing versions of the distribution are strongly
> encouraged to upgrade, as these legacy clients allowed potentially
> unsafe parameters to be used in the protocol.
>
Let me rephrase this:
SRP 1.5.2 is ***vulnerable*** to active attacks by
corrupt/spoofing servers!!!! That is, a spoofing server
can obtain enough information to launch an offline-dictionary
attack on a user, without the user even realizing it!
If you do not upgrade, you will be using software that
is potentially **weaker than ssh**, which is a shame since the
whole point of SRP was to alleviate some of the security
issues associated with ssh - in particular, vulnerability
to spoofing server attacks.
This vulnerability is in every implementation of SRP clients
I have seen (except the new SRP 1.6.0, of course).
That means Kermit95, Anzio Telnet, and all the other software
that can be found from the "Links" page on the SRP website, are
vulnerable to this type of attack. If you are using any
of these programs - you should demand a patched version ASAP!
You can find software which shows how to exploit this
vulnerability at:
http://www.bell-labs.com/user/philmac/srp-attack.html
(if this page is not accessible yet, it will be in a few hours)
-Phil
------------------------------
From: Cornelius Sybrandy <[EMAIL PROTECTED]>
Subject: Re: ---- As I study Rinjdael...
Date: Wed, 18 Oct 2000 17:43:15 -0400
> But Rijndael was chosen primarily for its speed, so there is also the
> option of choosing one of the available ciphers from among the other
> finalists, such as Twofish, SERPENT, or, now, MARS as well.
>
Just so I'm not confused, but MARS is now free to use? The last I heard
there were no definates on that subject.
csybrandy
------------------------------
From: "Stephen M. Gardner" <[EMAIL PROTECTED]>
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Wed, 18 Oct 2000 16:42:20 -0500
[EMAIL PROTECTED] wrote:
> If we assume that the NSA is significantly ahead of the private
> sector, the inability to publish is more than offset by the access to
> information noone else has.
Why would we assume that? There is a lot of open crypto research going
on these days. Let's not get caught in the trap of assuming the consequent
here. ;-)
> I suspect that if you told anyone they
> could read every file the NSA has, provided they never discussed them
> later, most people would leap at the chance.
Sure, if you didn't have to suffer the bullshit that comes with it.
Having some "Colonel Flag" SOB sniffing your underwear for 'preversion' is
not a price that most are willing to pay these days. Read your
newspaper--government security jobs are not in vogue. Los Alamos is having
difficulty recruiting especially among asian americans because of the Lee
affair. With the economy the way it is now the government looks like a bad
deal, especially when you consider the consequences of a screwup. These
clowns don't fire you, they throw you in jail and toss away the key. Who
wants to take that chance when a perfectly acceptable alternative is
available in outside of a government prison camp, ah, I mean lab. ;-) Sorry
Uncle Sam but if I want abuse I'll go to a dominatrix, the cost is far
cheaper and the effect is more pleasurable. ;-)
> On the other hand, if they're on par with the open community, the
> inability to publish is offset for many people by the ability to
> accomplish meaningful work without having to deal with publishing! ;)
You still have to document it. It ain't a free ride.
> Saving lives, and the ability to work against the best advesaries the
> rest of the world has to offer are strong motivations.
When? In '42? Surely. In the 50s through the 70s? Yeah maybe. In 2000?
I don't think so. What adversaries? Hello? There is one, I repeat, one
superpower in the world and I don't want to shoot any sunshine up your skirt
but that superpower ain't always the good guy. Slavish belief in the
goodness of one's government (no matter which) is pathetic in this cynical
world where people blow up the wrong factory in Somalia to get back at a
Saudi in Afghanistan and then don't pay reparations anywhere. Again I say:
Hello? Anyone home?
> As to the intrusion into your private life, the private sector is not
> doing much better in that particular case.
This is laughable. Any modern high tech company that routinely subjected
its employees to lie detector tests with probing questions about their sex
lives and use of recreational drugs would have difficulty recruiting the
cleaning staff let alone the smartest engineers and scientists.
> The current trend in many
> companies is mandatory drug testing, immediate dismissile for smoking
> on or off the premisis at some places, etc.
How many companies do you know that drug test engineers and scientists
after the pre-employment phase? I don't know of a single company that
mandates immediate dismissal even for smoking on premises let alone at home.
Most places here in the Dallas area have little outdoor 'cancer wards' with
ashtrays for the severely addicted. Good grief man, what planet do you
live on?
--
Take a walk on the wild side: http://www.metronet.com/~gardner/
There is a road, no simple highway, between the dawn and the
dark of night. And if you go no one may follow. That path is
for your steps alone.
The Grateful Dead ("Ripple")
------------------------------
From: "Stephen M. Gardner" <[EMAIL PROTECTED]>
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Wed, 18 Oct 2000 16:44:13 -0500
CiPHER wrote:
> I don't think it's fair at all to say that one is more open than
> another. Especially in the field of cryptography, let alone any other
> branch of maths (most of which are equally as bad when it comes to
> internal secrecy).
Actually crypto is probably the most open area of research in the
private sector. Security by obscurity is very unfashionable these days.
It is usually seen as giving off the odor of snake oil.
--
Take a walk on the wild side: http://www.metronet.com/~gardner/
There is a road, no simple highway, between the dawn and the
dark of night. And if you go no one may follow. That path is
for your steps alone.
The Grateful Dead ("Ripple")
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.perl.misc
Subject: Re: Rijndael in Perl
Date: Thu, 19 Oct 2000 05:43:49 +0800
Dido Sevilla wrote:
>
> "Tony L. Svanstrom" wrote:
> >
> > Anyone that knows if Rijndael exists in Perl yet and/or if someone's
> > working on it?
> >
>
> Well, I've been working on a Crypt-CBC-compatible module that uses
> Rijndael, but I'm learning how to program Perl modules while I'm at it,
> so progress is somewhat slow. It uses (er...will use) my own Rijndael C
Er...It's done now. I'll get the thing uploaded to PAUSE stat, but in
the meantime, you can download it here:
http://home.pacific.net.ph/~dido/Crypt-Rijndael-0.01.tar.gz
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
From: "Stephen M. Gardner" <[EMAIL PROTECTED]>
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Wed, 18 Oct 2000 17:00:00 -0500
John Savard wrote:
> It certainly can be abused - but codebreaking is one of those fields
> where secrecy is almost always necessary.
That depends on the context. Codebreaking technology in the private
sector is quite open. One need only see what hackers have done to DVD
encryption and the 'encryption' of the Digital Convergence Cuecat.
Granted these are very poor examples but the crytanalysis was carried
out very publically (far too publically for the tastes of the
organizations that got burned by it).
--
Take a walk on the wild side: http://www.metronet.com/~gardner/
There is a road, no simple highway, between the dawn and the
dark of night. And if you go no one may follow. That path is
for your steps alone.
The Grateful Dead ("Ripple")
------------------------------
From: "Stephen M. Gardner" <[EMAIL PROTECTED]>
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Wed, 18 Oct 2000 17:01:47 -0500
"John A. Malley" wrote:
> The original question from Mr. Gardener didn't place
> any qualifiers on that group of scientists other than (1) security
> clearances and (2) no open community peer review/awareness of their
> work.
I don't care what you say about my as long as you spell my name right.
;-)
--
Take a walk on the wild side: http://www.metronet.com/~gardner/
There is a road, no simple highway, between the dawn and the
dark of night. And if you go no one may follow. That path is
for your steps alone.
The Grateful Dead ("Ripple")
------------------------------
** 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
******************************
