Cryptography-Digest Digest #211, Volume #11 Mon, 28 Feb 00 00:13:01 EST
Contents:
Re: NSA SPIES ON THE POPE, MOTHER THERESA AND DIANA! ("Joseph Ashwood")
Re: - US "allows" encryption program online (Isaac)
Re: How to Annoy the NSA ("Donald S. Crankshaw")
Re: Does the NSA have ALL Possible PGP keys? ("Dead Kennedy")
Re: Passwords secure against dictionary attacks? (Alan J Rosenthal)
Re: How do I get the key from the passphrase in DES? (JPeschel)
Re: CRC-16 Reverse Algorithm ? (Terry Ritter)
Re: CRC-16 Reverse Algorithm ? (Terry Ritter)
Re: CRC-16 Reverse Algorithm ? (Terry Ritter)
Re: NSA SPIES ON THE POPE, MOTHER THERESA AND DIANA! (Dave Hazelwood)
Re: EOF in cipher??? ("David Thompson")
----------------------------------------------------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: NSA SPIES ON THE POPE, MOTHER THERESA AND DIANA!
Date: Sun, 27 Feb 2000 16:08:01 -0000
I'm not sure I agree with you. I was for the fight against
turning the US (where I live) communist not because I wanted
to follow the rich, but because communism as it has been
practiced is a losing proposition. True communism, I would
have been for, but it doesn't work, as soon as 2 people say
"I want to be in charge" true communism breaks down.
Communism as practiced in the world today bears little
semblance to this, the average person is little more than a
pebble on the driveway for those of import. Just examine
what we have learned of what went on in the Soviet Union,
there are a vast number of parellels to the state of France
around the time of the famous (mangled) quote "Let them eat
cake" a time many of us know more about.
Of course this entire post is off-topic. However, it is
worth noting that the Soviet Union had some of the greatest
advances in security in the world, simply by giving the
promise of making them something more than a pebble. Here in
the US we can't have those advances anymore, the middle
class is too strong.
If we're going to continue this line of thought, we should
at least take it to a talk. newsgroup if not off NG
entirely.
Joe
"Mary - Jayne" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Sun, 27 Feb 2000 06:02:24 GMT,
[EMAIL PROTECTED] (Dave
> Hazelwood) wrote:
>
> >
> >All in the name of democracy and human rights? Isn't this
what we
> >fought Communism for 50 years to avoid ?
>
> No. We fought communism because the rich and powerful did
not want to share
> their wealth and power with the rest of us. It has
nothing to do with
> freedom, human rights, or even democracy. Just doing what
the rich want us
> to do, as always. So which country is a democracy then -
none that I know
> of.
>
> Regards,
>
> MJ
>
> http://www.xarabungha.btinternet.co.uk/
>
> http://website.lineone.net/~c.j.stevens/
------------------------------
From: [EMAIL PROTECTED] (Isaac)
Crossposted-To: alt.sources.crypto,talk.politics.crypto,us.legal
Subject: Re: - US "allows" encryption program online
Date: 28 Feb 2000 02:43:34 GMT
On Sat, 26 Feb 2000 01:39:08 GMT, John Galt <[EMAIL PROTECTED]> wrote:
>"Professor allowed to post encryption program online"
>
>I have been watching the responses to this post. It is incredibly sad that
>so many people consider themselves as "subjects" instead of "citizens", in
>that they do not appear to be the least bit angry that any government would
I think this is a little silly. Your arguing because noone reacted to the
wording picked by whoever wrote the newspaper article. Yes they were poorly
chosen, but so what?
Bernstein's right to post the program has been discussed endlessly.
Forgive us for not rehashing the old discussions for your benefit. I think
the news presented in the original post was worth posting and discussion.
Isaac
------------------------------
Date: Sun, 27 Feb 2000 22:17:54 -0500
From: "Donald S. Crankshaw" <[EMAIL PROTECTED]>
Subject: Re: How to Annoy the NSA
"Trevor Jackson, III" wrote:
>
> Thank you for the insights. Are you able to comment on the slope of the
> quantum operation time? If we need to project the performance of QC into
> the future we need an estimate of the rate of change in the fundamental
> operating frequency in order to stay safely on the upper side of the
> feasibility boundary.
>
> The the slope is not apparent, perhaps you could explain the basis for the
> 10 ns per operation? I.e., what is taking that time? If, for example, it
> is all speed-of-light delays than scaling the device down would affect the
> operating frequency. But if there is some intrinsic "settling/sensing" time
> per operation then scaling the device down could actually be counter
> productive. What's going on during an "operation"?
The operation time that I'm using is based on the Rabi oscillation
time. This is the time it takes to rotate a qubit between the states
of |0> and |1> and back again. The term rotate is used since the
qubit may be in superpositions of the |0> and |1> states, so it
doesn't just become |0>, then |1>, and then back again. It goes
through a continuous change of where it's a|0> + b|1>, where a^2 + b^2
= 1.
The rotation is performed by applying some perturbation to the qubit.
In our case, the perturbation is an oscillating magnetic field. We
can speed up the qubit rotation simply by increasing the field
oscillation magnitude. What's the limit? Well, if we increase the
magnitude too much, we disturb the bias point that makes the qubit
operate in the way we want it to. We probably couldn't increase speed
by more than 5 times this way. We could change the bias point to
something which could allow faster oscillation, but there are all
sorts of other considerations that would come into play then.
Alternatively, we can adjust the design of the qubit. The operation
time is also affected by the physical parameters of the quantum
system. For a simple physical system (say an atom with two energy
states), you're stuck with whatever Hamiltonian nature gives you. For
a solid state system, one which you design, the parameters you choose
determine what the quantum system looks like, and you can in principle
adjust these so that it can perform its operations more quickly.
However, this is not as easy as it sounds. The parameters are chosen
not just to speed up the quantum operation, but also to increase the
decoherence time (the time the system remains quantum), to make the
system easy to measure, to make it less vulnerable to certain types of
noise, etc.
In short, it's a hard question to answer for just my own system: it
doesn't simply scale. I can't even hazard a guess at what parameters
you have to modify for other systems. Thus, I really can't tell you
how quickly quantum computers will increase in speed. To be honest,
it's not really a hot topic in the QC community. You just need a high
enough Q, that's (decoherence time)/(operation time), that you can do
error correction. After that, the real challenge is to increase the
number of qubits you can put in a quantum register. Of course, that's
only important once you've demonstrated a qubit and a quantum gate,
which most of the current proposals have yet to do.
Sincerely,
Donald S. Crankshaw
http://www.mit.edu/~dscrank
------------------------------
From: "Dead Kennedy" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Mon, 28 Feb 2000 03:31:05 GMT
If nothing else, PGP encryption ain't making things any easier for the
spooks at the
nsa. that's a good thing...
--
".In our obsession with antagonisms of the moment, we often forget
how much unites all the members of humanity. Perhaps we need
some outside, universal threat to make us recognize this common
bond. I occasionally think how quickly our differences worldwide
would vanish if we were facing an alien threat from outside this
world. And yet I ask you, is not an alien threat already among us?"
-Ronald Reagan
Beretta <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Sun, 13 Feb 2000 13:21:56 -0800, "tiwolf" <[EMAIL PROTECTED]> wrote:
>
> >Does anyone here really think that any cryto program self made or
commercial
> >is not broken already or can't be broken given a little effort by the NSA
> >geeks. I know that someone might use some type of cryto that might give
them
> >trouble for a while, but if they really want to I think that the NSA
geeks
> >can break it.
> >
> >
> <snip>
>
> You seem to assume the NSA is all powerful, has an infinite budget,
infinite room for
> computers, and somehow is the only agency that is not bound by the laws of
mathematics...
>
> And while I'll admit that the NSA certainly does have a huge budget, that
budget is not
> infinite.. And while they certainly have talented cryptanalysts on staff,
those
> cryptanalysts are not infinite in number, nor infinite in talent. In fact,
there is no
> reason that the cryptanalysts on the NSA payroll are necessarily "the
best".
>
>
------------------------------
Crossposted-To: comp.security.misc
From: [EMAIL PROTECTED] (Alan J Rosenthal)
Subject: Re: Passwords secure against dictionary attacks?
Date: 28 Feb 2000 02:24:36 GMT
[EMAIL PROTECTED] (Guy Macon) writes:
>Two characters can have 65,536 possible values (much less if
>you only use what's available on your keyboard).
This is way overestimated (e.g. you can't use the 0 byte), but anyway...
>There are many more english words than that.
Most of them are highly improbable. You don't have to put *all* the English
words in a list to make for a real good dictionary attack.
Incidentally, in my experience about a quarter of the passwords which are
supposed to be good security because they have all sorts of characters in them
end with an exclamation point. Well, over a tenth, anyway.
For an adequate password, either really overshoot the assumed threat
(e.g. a long passphrase), or generate it with a random number generator
(high quality may or may not be necessary depending on other details; I've
heard of two distinct cases where people figured out pseudo-randomly-generated
passwords based on knowledge of the PRNG and other users' passwords in the
generated series).
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: How do I get the key from the passphrase in DES?
Date: 28 Feb 2000 03:44:57 GMT
"Amit IG" [EMAIL PROTECTED] writes:
>I want to know the technique used for deriving the 64-bit key from an
>arbitrary length passphrase. The key is then used in DES.
DES uses a 56-bit key.
How an arbitrary passphrase generates a key depends on the
specific implementation.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: CRC-16 Reverse Algorithm ?
Date: Mon, 28 Feb 2000 04:33:22 GMT
On 27 Feb 2000 15:25:11 -0800, in
<89cbon$v9s$[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (David A. Wagner) wrote:
>In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] (David A. Wagner) wrote:
>> >Yes, 111..11 -> 111..10 (if the incoming data bit is zero;
>> >assuming Fibonacci configuration, not Galois). Right?
>>
>> Right.
>>
>> >Right. Now, if 111..11 -> 111..10 under input bit zero, then
>> >111..11 -> 111..10 xor 1 = 111..11 under input bit one. No?
>>
>> No.
>>
>> In a shift-left CRC, 0's always shift in, and this is independent of
>> the data value. the only way the rightmost bit gets set to a 1 is
>> from the poly add.
>
>Ok. That looks like the source of the confusion, then. Thanks.
>
>See my earlier quoted comments -- I was assuming we were talking
>about a Fibonacci configuration (what CRC folks seem to call "forward"
>CRC), rather than a Galois configuration (what CRC folks seem to be
>calling a "reverse" CRC, if I understand correctly). This seems to
>be where we diverged.
Yeah. We "diverged" when some of us were talking about CRC, and
others of us were not.
>As far as I can see, it remains true that the all-ones state is bad
>for Fibonacci ("forward"?) if you xor the incoming data bit along with
>the feedback taps to get your new state-bit.
Obviously, that is not CRC.
>But the poster was
>apparently talking about Galois / "reverse" configuration.
I know quite a few different various configurations for CRC. But the
CRC result is unambiguous.
CRC does use LFSR operations. But not all forms of LFSR are CRC. I
don't know whether we can do a CRC in the other LFSR form. Maybe we
can, but we had better get the same result from it. Which means that
it had better detect both leading 1's and 0's.
>I think.
>
>Right?
No.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: CRC-16 Reverse Algorithm ?
Date: Mon, 28 Feb 2000 04:33:42 GMT
On 27 Feb 2000 15:08:08 -0800, in
<89caoo$v8j$[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (David A. Wagner) wrote:
>In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
>> Missing and extra 0's are also detected.
>
>How can this be? Take a vanilla CRC initialized to the all-zeros state.
>Clock in a single zero bit. The result will still be the all-zeros
>state. Clock in as many zero bits as you like, the state won't change.
If the CRC register is initialized with zeros, it cannot detect
leading zeros in the data. That problem was detected early in CRC
use, and from that time it became common to init the CRC register as
ones. When this is done, CRC can detect both leading zeros and
leading ones.
Here is what you said, which defines the current issue:
>David A. Wagner <[EMAIL PROTECTED]> wrote in message
>news:89a959$to6$[EMAIL PROTECTED]...
>> In article <#txNt0Ng$GA.262@cpmsnbbsa03>, Marty <[EMAIL PROTECTED]> wrote:
>> > Inserted and/or deleted ones at the start of a ones initialized CRC are
>> > indeed detected.
>>
>> Did you mean "not detected"? I thought Doug Stell got it right.
And here is the statement which you thought was right:
On Fri, 25 Feb 2000 23:34:15 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt [EMAIL PROTECTED]
(Doug Stell) wrote:
>[...]
>CRCs that are initialized to all zeros (CRC-16 is one of these) can
>not detect the addition or deletion of leading zeros. Likewise, CRCs
>that are initialized to all ones can not not detect the addition or
>deletion of leading ones.
The last statement was false.
>Consequently, the CRC can't tell the difference between the message
>0^j || M (i.e., j zeros followed by M) and the message 0^k || M.
>
>Sure, in a real implementation you should add extra precautions to eliminate
>this property. For instance, simply avoid starting in the all-zeros state.
>Or start in the all-zeros state but always prepend a one-bit to the message
>(a roughly equivalent countermeasure). But if you do nothing, it seems you
>get into trouble. And I'm talking about the vanilla "do-nothing" case.
The CRC register has to be initialized to *some* known value. The
vanilla case is to initialize the CRC to all-1's.
>Consider the pseudocode you suggested:
> if (msb(crc) = databit)
> crc = crc << 1;
> else
> crc = (crc << 1) ^ poly;
>If you run this code fragment with crc=0 and databit=0, you will execute the
>statement `crc = crc << 1;', and since 0 << 1 = 0, we will still have crc=0
>after the code fragment. This supports what I said above.
>
>There, I tried it. Now, where did I go wrong?
By not actually trying some working CRC code after thinking about it.
>Ignore the all-ones stuff for the moment;
>Are you *sure* I'm wrong about this all-zeros property?
What you said originally was wrong. I'm not sure what you have
changed to now.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: CRC-16 Reverse Algorithm ?
Date: Mon, 28 Feb 2000 04:34:00 GMT
On 27 Feb 2000 15:20:51 -0800, in
<89cbgj$v98$[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (David A. Wagner) wrote:
>In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
>> if (msb(crc) = databit)
>> crc = crc << 1;
>> else
>> crc = (crc << 1) ^ poly;
>
>Ok, let's try this.
>I will show a initial state which allows you to prepend as many
>one bits as you like without changing the final CRC hash.
But that is not the issue.
You have agreed with the statement that CRC could not detect faults in
*leading* 1's.
Here is the original statement:
On Fri, 25 Feb 2000 23:34:15 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt [EMAIL PROTECTED]
(Doug Stell) wrote:
>[...]
>CRCs that are initialized to all zeros (CRC-16 is one of these) can
>not detect the addition or deletion of leading zeros. Likewise, CRCs
>that are initialized to all ones can not not detect the addition or
>deletion of leading ones.
The last statement is false. And since modern CRC's do set the CRC
register to 1's they do indeed detect both leading 0's and 1's. End
of story.
Are you now saying that if, mid operations, the CRC register has some
particular state, it will not detect extra 1's? While that may be an
interesting idea, it is a completely different issue.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Dave Hazelwood)
Subject: Re: NSA SPIES ON THE POPE, MOTHER THERESA AND DIANA!
Date: Mon, 28 Feb 2000 04:42:13 GMT
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
>I'm not sure I agree with you. I was for the fight against
>turning the US (where I live) communist not because I wanted
>to follow the rich, but because communism as it has been
>practiced is a losing proposition. True communism, I would
>have been for, but it doesn't work, as soon as 2 people say
>"I want to be in charge" true communism breaks down.
>Communism as practiced in the world today bears little
>semblance to this, the average person is little more than a
>pebble on the driveway for those of import. Just examine
>what we have learned of what went on in the Soviet Union,
>there are a vast number of parellels to the state of France
>around the time of the famous (mangled) quote "Let them eat
>cake" a time many of us know more about.
>
>Of course this entire post is off-topic. However, it is
>worth noting that the Soviet Union had some of the greatest
>advances in security in the world, simply by giving the
>promise of making them something more than a pebble. Here in
>the US we can't have those advances anymore, the middle
>class is too strong.
>
>If we're going to continue this line of thought, we should
>at least take it to a talk. newsgroup if not off NG
>entirely.
> Joe
>
Maybe to talk.politics.crypto ?
>"Mary - Jayne" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> On Sun, 27 Feb 2000 06:02:24 GMT,
>[EMAIL PROTECTED] (Dave
>> Hazelwood) wrote:
>>
>> >
>> >All in the name of democracy and human rights? Isn't this
>what we
>> >fought Communism for 50 years to avoid ?
>>
>> No. We fought communism because the rich and powerful did
>not want to share
>> their wealth and power with the rest of us. It has
>nothing to do with
>> freedom, human rights, or even democracy. Just doing what
>the rich want us
>> to do, as always. So which country is a democracy then -
>none that I know
>> of.
>>
>> Regards,
>>
>> MJ
>>
>> http://www.xarabungha.btinternet.co.uk/
>>
>> http://website.lineone.net/~c.j.stevens/
>
------------------------------
From: "David Thompson" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Mon, 28 Feb 2000 05:06:36 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote :
> Mok-Kong Shen wrote:
> > I am ignorant of what the C standard specifies. Question: Does
> > 'binary' require the file to be multiple of words or just any
> > multiple of bytes will do?
>
> The latter.
>
I think you're mistaken. C90 7.9.2, unchanged in C99 7.19.2p3,
allows the implementation to pad stored binary streams
(normally disk files) with null characters = zero-value bytes;
AFAIK this is to allow file granularity > 1 byte. As examples,
I believe RT-11 rounded to 512-byte blocks, and I'm pretty sure
CP/M rounded to 128-byte sectors, though I don't recall any
(pre-ANSI?!) C implementation for CP/M.
On the other hand, Un*x/POSIX and MSDOS/Win do provide
any-number-of-octets-exactly (the former for text mode also).
This is arguably most systems of interest. IMO,YMMV,FCOL.
> For a binary stream, also, the file position indicator (used
> with fseek and ftell) measures position in bytes, unlike the
> case for text streams in some implementations (where about
> the only thing you can do with the f.p.i. is use it to get
> back to the previously recorded position).
True. Although a really lame implementation could decide
that fseek() always, or sometimes, fails due to "error".
And a system with >2GB files that wants to keep 'long'
32-bits has to use f{get,set}pos instead of fseek,ftell.
--
- David.Thompson 1 now at worldnet.att.net
------------------------------
** 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
******************************
