Cryptography-Digest Digest #934, Volume #12 Mon, 16 Oct 00 01:13:01 EDT
Contents:
Re: Rijndael implementations (Tim Tyler)
Re: Rijndael implementations (Tim Tyler)
Patching policy of Stas Busygin's RHPS (Stas Busygin)
Re: pseudo random test (=?ISO-8859-1?Q?Jacques_Th=E9riault?=)
Re: pseudo random test (=?ISO-8859-1?Q?Jacques_Th=E9riault?=)
Re: Rijndael implementations (Tim Tyler)
Re: naval code books were "weighted" (Steve Roberts)
Re: SHA-256 implementation in pure C (free) ("bubba")
Re: pseudo random test (Frank M. Siegert)
Re: Securely hashed passwords ("David Thompson")
Re: Why trust root CAs ? ("David Thompson")
Re: Rijndael implementations (Benjamin Goldberg)
fiat-shamir style schemes? (David A Molnar)
Re: Is it trivial for NSA to crack these ciphers? ("John A. Malley")
Re: naval code books were "weighted" (John Savard)
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Rijndael implementations
Reply-To: [EMAIL PROTECTED]
Date: Sun, 15 Oct 2000 23:56:45 GMT
Richard Heathfield <[EMAIL PROTECTED]> wrote:
: My current client is writing code which must work on machines with 8
: bits per byte, sizeof(long)=4. A fairly typical system, you might think.
: But the same code must also work on machines with 32 bits per byte:
: sizeof(long) = sizeof(int) = sizeof(short) = sizeof(char) = 1.
: Pretending that a byte has 8 bits won't help us. We have to confront the
: reality of 32-bit bytes, and ignorance doesn't count as a defence in the
: real world.
I believe the original issue about the byte was a terminological one - a
question of which term should refer to what.
No volume of terminology or naming of names will help with porting C
programs (complete with C's incompletely-specified fundamental type sizes)
between different architectures.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Organic: Church music.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Rijndael implementations
Reply-To: [EMAIL PROTECTED]
Date: Sun, 15 Oct 2000 23:47:54 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: I think the word "byte" itself arose from making a long I
: instead of short I in "bit", maybe also punning about a
: chomp ("bite") taken out of a machine word.
According to the "New Hackers Dictionary", it is a variant on "bite" -
whose spelling was modified to reduce the accidental resembalance to the
word "bit".
The term "nybble" appears to be clear evidence that bite-sized chunks are
indeed implicated.
The term was coined by Werner Buchholz in 1956. The move to 8 bits
happened later that year (all according to the dictionary).
: In fact I've seen a lot of confusion among newcomers over the
: use of the term "byte" in the C standard to designate the
: implementation's choice for the smallest unit used to compose
: data objects. [...]
C is trying to accomodate hardware variations too much. Programming
environments should specify the size of data types to aid portability.
This is a problem with the programming language - rather than anything
much to do with terminology, IMO.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Free gift.
------------------------------
From: Stas Busygin <[EMAIL PROTECTED]>
Crossposted-To: comp.theory,sci.math,sci.op-research
Subject: Patching policy of Stas Busygin's RHPS
Date: Mon, 16 Oct 2000 03:25:48 +0300
To avoid possible misunderstandings through circulation of the old
and patched stuff simultaneously, the history of the changes (along
with the dates) will be maintained from now and henceforth at pages
contained the stuff. According to this, the CFP (
http://www.geocities.com/st_busygin/call.html ) is supplemented now
with the following paragraph:
> 6. As authors have the right to patch or renew their stuff at any time, the history
>of the changes will be made available to provide users an opportunity to observe
>evolution of proposals. It is understood that anyone downloading the proposed stuff
>considers it to be authors' gift to the community and regards the authors' right to
>share their insights in embryonic form. The evolution of the stuff from that state to
>its perfection is a vital concern of the repository project.
All newly patched texts will contain the date corresponding to the
last patch. I'd like to thank Vladimir Z. Nuri, the moderator of
theory-edge list, whose suggestions help me to make this
improvement of my project.
Best regards,
Stas Busygin
email: [EMAIL PROTECTED]
WWW: http://www.busygin.dp.ua
------------------------------
Subject: Re: pseudo random test
From: [EMAIL PROTECTED] (=?ISO-8859-1?Q?Jacques_Th=E9riault?=)
Date: Mon, 16 Oct 2000 00:43:51 GMT
Jacques Th�riault <[EMAIL PROTECTED]> wrote:
> I would like to test a RNG that I made.
>
> Is there somewhere on the web that offer such services for free?
>
> And/Or Could you recoment which tests should a RNG pass to be acceptable
> to a cryptographically point of vue.
>
> Thanks
> Jacques
more specifically I'm looking to test this sequqnce
kAbbCwt3hPR-F4GH5ge7YGzhd4AeAc2gzqSsETN3YIQd3Sbx6heAgIY.2nJhGp4y
VSWWgoJJ2QrD6sBwXhOWkKY6P0Q4XUpr69r-HRUPjFlFMszfWpi8GpGCDEmgpsGW
W77BUC6eiGcm1uOX86Zb4lGMnTaCdLHJFt2C3AZK0v1v4e5oS.vodzbzRr56Zftt
6xLgn6NgSp6lw2qzlNcOshFB5qia6k-Ty5wvpNCikB40YNzG2a7QpjRR1.w-hQYg
EI8cGtR6emZhkO.7b6rNdANUAt2MhHbreE4J9d8AgVE4ZbVQ5UZt5QqJlYHLOMaZ
6LzEIBHjR7CKQkBYiimovWMkSN3aZVJDqyxT2GCHOPkx0srkAotj1V-6dW-hhWI9
MSpJz8.C-L9gyY10QlN0djK.gO8h-fMwNNEKHupRQTk-loWvDwbXzNFnRNy0GNQt
MRna.e-6SlFUR.VQFd6Kw26-4ZFdRtCtcwAXMZ6CQAgWLd5XuhMLukBLBykRCBDF
ugGuuWmvXI7eOvwiRq.1Wf6psOEpT9GwA6u9CG7.FxiSYZoUDO5Pq2bx8mMGI.GS
OsHJF3gu4bLDdS2dAEDvMNzMtA.ZJaKwVN6FBp2SaWgf3I6A2BqgAb.2T-SkZ97q
D-k3g7uxw0a6mnzmcVvihq-FD.-nA-CaWRMt6AKl0aaybH1EHF3wqnvJoE.vMUh2
YwPJ8iPGmKNjVifpLZ86cC9aczR5VGBuV681qBSGm83mdAD5B.bjVpEqZ92OVBjk
SY6PZtOWmzREOSWCS7Eq4eS3eOm2yzI0GeSzZLoayCW1HZ14w2Yklcn97SaekIt1
3o9e8pU0-CDoMhhkewtUmEix1tmT-EiVde1CFichoScX4ShEzOcdhjKUmJqTwDiF
ST92EcPJIwCV.BAFnktyBsnKDW5pNib6GU78KFelecVbDGPrEf3s3GkiQp5daO25
mDVg1eTdE.xkQ8Y7jX-xUVktIN-l92fQCZdwadIeU0BsXf6FemAN2bTQFt65AVQ9
Thanks
------------------------------
Subject: Re: pseudo random test
From: [EMAIL PROTECTED] (=?ISO-8859-1?Q?Jacques_Th=E9riault?=)
Date: Mon, 16 Oct 2000 00:43:53 GMT
Jacques Th�riault <[EMAIL PROTECTED]> wrote:
> I would like to test a RNG that I made.
>
> Is there somewhere on the web that offer such services for free?
>
> And/Or Could you recoment which tests should a RNG pass to be acceptable
> to a cryptographically point of vue.
>
> Thanks
> Jacques
more specifically I'm looking to have this sequence analysed
kAbbCwt3hPR-F4GH5ge7YGzhd4AeAc2gzqSsETN3YIQd3Sbx6heAgIY.2nJhGp4y
VSWWgoJJ2QrD6sBwXhOWkKY6P0Q4XUpr69r-HRUPjFlFMszfWpi8GpGCDEmgpsGW
W77BUC6eiGcm1uOX86Zb4lGMnTaCdLHJFt2C3AZK0v1v4e5oS.vodzbzRr56Zftt
6xLgn6NgSp6lw2qzlNcOshFB5qia6k-Ty5wvpNCikB40YNzG2a7QpjRR1.w-hQYg
EI8cGtR6emZhkO.7b6rNdANUAt2MhHbreE4J9d8AgVE4ZbVQ5UZt5QqJlYHLOMaZ
6LzEIBHjR7CKQkBYiimovWMkSN3aZVJDqyxT2GCHOPkx0srkAotj1V-6dW-hhWI9
MSpJz8.C-L9gyY10QlN0djK.gO8h-fMwNNEKHupRQTk-loWvDwbXzNFnRNy0GNQt
MRna.e-6SlFUR.VQFd6Kw26-4ZFdRtCtcwAXMZ6CQAgWLd5XuhMLukBLBykRCBDF
ugGuuWmvXI7eOvwiRq.1Wf6psOEpT9GwA6u9CG7.FxiSYZoUDO5Pq2bx8mMGI.GS
OsHJF3gu4bLDdS2dAEDvMNzMtA.ZJaKwVN6FBp2SaWgf3I6A2BqgAb.2T-SkZ97q
D-k3g7uxw0a6mnzmcVvihq-FD.-nA-CaWRMt6AKl0aaybH1EHF3wqnvJoE.vMUh2
YwPJ8iPGmKNjVifpLZ86cC9aczR5VGBuV681qBSGm83mdAD5B.bjVpEqZ92OVBjk
SY6PZtOWmzREOSWCS7Eq4eS3eOm2yzI0GeSzZLoayCW1HZ14w2Yklcn97SaekIt1
3o9e8pU0-CDoMhhkewtUmEix1tmT-EiVde1CFichoScX4ShEzOcdhjKUmJqTwDiF
ST92EcPJIwCV.BAFnktyBsnKDW5pNib6GU78KFelecVbDGPrEf3s3GkiQp5daO25
mDVg1eTdE.xkQ8Y7jX-xUVktIN-l92fQCZdwadIeU0BsXf6FemAN2bTQFt65AVQ9
Thanks
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Rijndael implementations
Reply-To: [EMAIL PROTECTED]
Date: Mon, 16 Oct 2000 00:09:33 GMT
John Savard <[EMAIL PROTECTED]> wrote:
: Using the term byte to mean "eight bits" in no way implies that all
: machines have a character cell that is one byte in size. That many
: computers have a six bit character, or that Java uses a sixteen bit
: character, is well known. A character cell may vary in size from one
: architecture to another, while a byte is now a unit of information.
"byte" is a term that I think *should* be a unit of information - in much
the same way as "bit".
However - according to many sources - it's a unit which doesn't have a
clearly-specified size. This is about the most fundamental property you
can have in something used for measuring information.
If we had a ruler that measured completely different distances in
different places, we would throw it away - and get a proper ruler
that worked.
This is what I think should happen to definitions of bytes - ones that
vary in size depending on location should be discarded as being of low
utility when attempting to communicate with others.
If you want a term that denotes "small chunk of information, of
architecture dependent size", then you're welcome to it - but I don't see
that the need for such a term justifies polluting a common information
storage metric with architecture-dependent considerations.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Free gift.
------------------------------
From: [EMAIL PROTECTED] (Steve Roberts)
Subject: Re: naval code books were "weighted"
Date: Mon, 16 Oct 2000 02:18:34 GMT
[EMAIL PROTECTED] (Jim) wrote:
>On Thu, 12 Oct 2000 19:22:51 GMT, James Muir <[EMAIL PROTECTED]> wrote:
>
>>I'm reading a paper in which the author explains that some cipher
>>systems used in WWII employed countermeasures to protect against the
>>seizure of key material. The author states for example that naval code
>>books were "weighted".
>>
>
>Yes. They were weighted to sink. They could be thrown overboard
>if the warship was cancelled, and in deep water recovery would be
>extremely unlikely. Certainly the Royal Navy did this. Probably
>still does!
The German Naval code book of 1916 was bound with lead in the binding.
The Russians recovered the body of a German sailor who had jumped
overboard from a sinking ship, clutching the code book. Unfortunately
he drowned, still clutching it. I've seen a photo of the recovered
book.
The (Tsarist) Russians had no idea what to do with the code book, so
the Tsar gave it to the British, knowing that the Poms liked to
collect this sort of thing. This is how the British were able to
decipher the Zimmerman Telegram of 1917.
Steve Roberts
------------------------------
From: "bubba" <[EMAIL PROTECTED]>
Subject: Re: SHA-256 implementation in pure C (free)
Date: Mon, 16 Oct 2000 02:17:43 GMT
Yes, the conversion is easy:
http://sduplichan.home.att.net/SHA/sha512.c
This source code is portable for Microsoft Windows.
UINT64 is defined in basetsd.h to be __int64. 32-bit
Windows compilers support __int64 by generating the
proper code. For example, add/adc is generated for
adding a 64-bit int in two 32-bit chunks. When building
for Win64, native 64-bit integers are used.
A more efficient x86 might be to use the MMX registers.
They can do 64-bit shift and add, but unfortunately no
64-bit add yet (Pentium 4 SIMD2 supports a 64-bit adds
in the MMX registers).
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:8sc779$aog$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>,
> lcs Mixmaster Remailer <[EMAIL PROTECTED]> wrote:
> > > At http://www.geocities.com/tomstdenis/files/sha256.c you can find a
> > > free copy of the SHA-256 hash function in C. It's rather easy to
> drop
> > > in and use. I hope SHA-256 is in fact secure though... heheheh
> >
> > Okay, hotshot, now let's see you do SHA-512. No fair peeking at
> > http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=681517214.
>
> Well first off, I would change "unsigned long" to "unsigned long long"
> then I would change the constants and some other trivial stuff.
>
> Personally I think both algorithms are stupid but SHA-256 has more use
> then SHA-512. Like who would put 2^256 effort to forge a msg anyways?
>
> Tom
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Frank M. Siegert)
Subject: Re: pseudo random test
Date: Mon, 16 Oct 2000 03:54:13 GMT
On Sun, 15 Oct 2000 23:40:00 GMT, [EMAIL PROTECTED]
(=?ISO-8859-1?Q?Jacques_Th=E9riault?=) wrote:
>I would like to test a RNG that I made.
>
>Is there somewhere on the web that offer such services for free?
>
>And/Or Could you recoment which tests should a RNG pass to be acceptable
>to a cryptographically point of vue.
Cryptographically secureness is *hard* to proof, statistical behaviour
is somewhat easier, e.g. search for the DIEHARD tests. For some easy
randomness tests you can also look here at my code
http://www.this.net/~frank/stepfive3.c
look in the main program, there are tests for mean, monte carlo pi and
distribution mainly for the purpose of Q&D testing the stepfive random
generator. I suggest you also use a larger set of psuedo random
values, your posted data set is much too small for any deeper
analysis.
------------------------------
From: "David Thompson" <[EMAIL PROTECTED]>
Subject: Re: Securely hashed passwords
Date: Mon, 16 Oct 2000 04:08:58 GMT
<[EMAIL PROTECTED]> wrote :
> Can someone show me an easy way to generate securely hashed passwords?
> I need to import them as flat files into LDAP, and I expect them to
> look like this: {SHA}NWdeaPS1r3uZXZIFrQ/EOELxZFA=
>
> I tried using SHA.pm, but I'm having trouble getting it into a 32 bit
> string.
>
I'm not sure why you want a "32 bit string", but SHA-1 output
(or SHA, if you really are using the defective version) is 160 bits
or 20 "bytes" (octets) and your example sure looks like
20 octets base-64 encoded (producing 28 text characters).
Just hashing a password and storing (or transmitting) the result
probably exposes you to an offline dictionary attack and maybe
an active forgery attack depending on how your system is used.
At a minimum, you probably want to salt the hash, and you may
want to do something more involved, depending on your use.
--
- David.Thompson 1 now at worldnet.att.net
------------------------------
From: "David Thompson" <[EMAIL PROTECTED]>
Subject: Re: Why trust root CAs ?
Date: Mon, 16 Oct 2000 04:09:56 GMT
Lyalc <[EMAIL PROTECTED]> wrote :
> Why does every sniffer and every server along the line need to see your name
> and address that is embodied in the certificate?
>
> Only you and the delivery agent need that information, yet certificates give
> it all away, every time the certificate is used. No ifs, no buts,
> privacy=zero.
>
Not necessarily. SET solves this -- for the cardholder --
by using as the cardholder identifier a keyed hash (HMAC)
of the account number by a secret opaquely agreed
between the cardholder (system) and the cardholder CA,
which is in effect the Issuing bank. And assuming
SHA-1 is noninvertible, unrecoverable by anyone else.
In effect the cardholder cert guarantees that the signing key
is for _some_ valid account at the specified Issuer.
(Or was; SET doesn't revoke cardholder, or merchant, certs,
using instead existing blocks on underlying accounts.
SET doesn't use enveloping keys for cardholder,
so the issue of authenticating them doesn't arise.)
For merchant and acquirer-gateway certs it does
use real identity, and for merchant address(es).
Acquirer certs don't have address details, apparently
because they are mostly huge banks -- does it
really matter "where" Citibank or Chase or BoA is?
You're not going to physically go there, if you need
to contact them you'll use toll-free phone or the net.
(And as a cardholder you won't contact them anyway,
you'll go through your Issuer.)
The weak point here is probably local storage of the secret,
and other information including signing private key, on a PC,
but that's true for most other personal crypto as well.
And known techniques for trying to deal with it.
--
- David.Thompson 1 now at worldnet.att.net
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Rijndael implementations
Date: Mon, 16 Oct 2000 04:23:48 GMT
Tim Tyler wrote:
>
> Paul Schlyter <[EMAIL PROTECTED]> wrote:
[snip]
> :Java is also designed to to execute on only one single architecture,
> :the Java virtual machine, while C was designed to execute on many
> :different architectures.
>
> There's no difference between C and Java in this respect. Java was
> designed (from the first white paper) to be compiled to whatever
> processing hardware is available. The difference from C in this
> respect is that C is often shipped in compiled form, while Java is
> almost always compiled on the target machine at some stage before
> being executed.
Untrue, UNLESS you are considering just-in-time compiling to be
compiling. If I write a Java applet, I compile it from source to
bytecode on whatever machine I'm on. That bytecode will (ok, should)
run on any implementation of the JVM. It should run on Win*, on *nix,
on Mac. However, I don't compile my applet on Win, *nix, Mac... only on
my Win95. Also, with some restrictions, it should run on a
[non-virtual] java machine.
> Any idea that Java was designed solely to be interpreted in a virtual
> machine is not historically correct.
That at least, is true. Java bytecodes run [directly] on javacards,
which are definitely not virtual machines. Also, java source code
doesn't *have* to be compiled into bytecode, it can be compiled into
architechture dependent object code, or even interpreted directly. (Not
that I know of any java source interpreters... but there *are*
java->object code compilers).
And lastly, java bytecode is often just-in-time compiled into object
code of the machine the JVM is running on. This is probably what is
meant by "Java is almost always compiled on the target machine at some
stage before being executed." However, it is ALWAYS possible to hav jit
turned off, and have the JVM run purely in interpretational mode, with
no compiling of any kind occuring.
--
"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]]
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: fiat-shamir style schemes?
Date: 16 Oct 2000 04:18:06 GMT
does anyone have a list of modern or "best of breed" fiat-shamir style
schemes?
I am aware of the Fiat-Shamir original scheme, the first
Guillou-Quisquater scheme, a scheme due to Shamir and Micali,
a newer Guillou-Quisquater scheme, and vaguely aware of some
schemes for proving knowledge of 2^t roots which were the basis
for some forward-secure signature schemes, as well as the
fact that T. Okamoto has an ID scheme which could be converted
to a signature scheme.
What else is there? what do people use for fiat-shamir style schemes
in e.g. smartcards? if you were doing a performance comparison, what
would you pick as the contestants?
thanks,
-david
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Sun, 15 Oct 2000 21:38:53 -0700
Paul Pires wrote:
[snip]
>
> All of these examples are short, intense efforts. Every one you
> mentioned was compromised at a later date. None of them
> are analogous to the NSA sustaining a level of secrecy for so long
> where those knowledgeable cannot even predict their capabilities
> over the long haul.
I provided three examples of secret research with no peer review, no
publications and security clearances resulting in incredible
accomplishments. 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.
As this discussion/thread progressed it's apparent some of us placed
quite a few assumed constraints on that group of scientists (a.k.a. the
NSA):
1. It's assumed the NSA suffers internal inbreeding of thought, its
researchers are extremely insular.
2. It's assumed the NSA operates in a different intelligence situation
than that of the WWII/Bletchley Park period.
3. It's assumed the NSA is stultified by huge self-perpetuating
bureaucracies.
4. It's assumed the NSA never addressed world-menacing evils that
required relatively short term and exciting responses.
5. It's assumed the NSA's knowledge has never been compromised.
6. It's assumed the NSA's capabilities cannot be predicted.
In my response to Mr. Gardener (see other thread branch) I argued that
item 1 is possibly true, item 2 is not true, item 3 is partially true
(not stultification but there is a bureaucracy), item 4 is not true. My
reasoning is primarily based on Davis Kahn's book "The Code Breakers"
and his description of the NSA in Chapter 19.
You've suggest items 5 and 6 with your post.
Item 5 is not strictly true. The open cryptological community *does*
know some of what the NSA knew in the past - differential cryptanalysis
of DES-like ciphers, public key cryptography, most of the pre-WWII
cryptanalysis and cryptography. Open cryptology did not need an Otto
Fuchs to leak the secrets. The open cryptological community is currently
(probably) rediscovering cryptanalytic and cryptographic truths NSA
researchers uncovered some 20 years ago. For example, years after
secret research devised protections against differential cryptanalysis,
cryptological researches in the open figured out how to do it.
Mathematics is mathematics. Just like fission and fusion weapons - years
after those secret projects, ordinary physics majors independently
figured out how to design those weapons, starting from the same initial
conditions of knowledge as in 1940. Physics is physics.
Item 6 is trickier to assess. The NSA and the open community get equal
access to published engineering, physics, information theory, complexity
theory, language and mathematics research. The NSA advantage is the
internal corpus of research and finding built up over the past 40 years
on top of what was known by the end of WWII. That framework gives a
different cohesiveness to new findings in the open. The scope and extent
of the framework is not openly known. But the public knowledge is
available to everyone - and worst case/most probable threat models
(based on assumptions about what technical advances the NSA made since
the 40s) are possible. The intelligence agencies of every
nation/group/power *should* be doing this very task. It's like the CIA's
mission - build up socio-economic models/assessments of other
nations/groups/powers. Comparative risk assessments.
>
> I think the problem in understanding their capabilities stems
> much more from a different activity rather than an absurdly
> capable secrecy effort. They are working on different
> approaches designed to meet different objectives. What
> we are doing is not real relevant to them and vice versa
Kahn claims COMSEC in the NSA looks over every cryptosystem proposed to
the agency by amateurs (pg. 710 of his book.)
But with respect to civilian traffic - our own encrypted messages - I'd
agree that the vast majority of private communications is but "small
potatoes" to the eyes and ears of the NSA. Our discourse *is* the noise.
>
> The one area of cross over would be cryptanalysis. They
> would have a need to know the content of encrypted
> messages in general. Sooner or later, the effort/reward
> equation is going to make cracking pointless and other
> methods to obtain the meaning are going to be needed.
>
> Look how they isolate themselves from any form of
> information radiation and figure how they got there.
> can they see a snapshot of your computers state at
> any time? Can they tap the information entry and
> display directly with ease? The operational complexity
> and interconnectivity of electronic devices is a
> target rich environment. Yes, if the effort to break
> a cipher becomes moot, they will move on to other
> promising weaknesses. If this point has already be
> reached, how will you know? Why would they tell
> you?
We aren't that valuable in the scheme of world politics. Our thoughts,
our positions, our cares and woes, our files, our documents are not
matters of national security. Unless we figure highly in some
organization, movement, political or economic structure of some
nation-state, city or region that matters to US interests, we give no
reason for the NSA to care about our traffic. People should realize that
in general, no one thinks about them more than they think about
themselves.
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: naval code books were "weighted"
Date: Mon, 16 Oct 2000 04:06:25 GMT
On Mon, 16 Oct 2000 02:18:34 GMT, [EMAIL PROTECTED] (Steve
Roberts) wrote, in part:
>The German Naval code book of 1916 was bound with lead in the binding.
>The Russians recovered the body of a German sailor who had jumped
>overboard from a sinking ship, clutching the code book. Unfortunately
>he drowned, still clutching it. I've seen a photo of the recovered
>book.
According to a recent book, however, the colorful story about the
Magdeburg code book is wrong, because the book wasn't water damaged.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
** 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
******************************
