Cryptography-Digest Digest #178, Volume #12 Sat, 8 Jul 00 08:13:00 EDT
Contents:
Re: Missing nuclear secrets found behind Los Alamos copy machine (Michael Kagalenko)
Re: Information-theoretic hash question (was Re: CRC question) ("Scott Fluhrer")
Re: Hash and Entropy (Bryan Olson)
Suggestions for crypto for constrained-memory/CPU computers? ("John Doe")
Re: CRC question (Bryan Olson)
Re: Turning off scripting (SCOTT19U.ZIP_GUY)
Re: A thought on OTPs (Bryan Olson)
Re: A thought on OTPs (Bryan Olson)
Re: A thought on OTPs (Bryan Olson)
Re: CRC question (Benjamin Goldberg)
Another AONT (less expensive, this time) (Benjamin Goldberg)
Re: cray and time needed to attack (Jerry Coffin)
Re: Suggestions for crypto for constrained-memory/CPU computers? (David Blackman)
Re: University Job Bank - Free Job Posting/Search (Ryan Healey)
Re: Compression & Encryption in FISHYLAND (Tim Tyler)
pic alogrithm ????? (dueyftw)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Michael Kagalenko)
Crossposted-To: alt.war.nuclear
Subject: Re: Missing nuclear secrets found behind Los Alamos copy machine
Date: 8 Jul 2000 05:48:12 GMT
Reply-To: [EMAIL PROTECTED]
Gregory Greenman ([EMAIL PROTECTED]) wrote
]> Heck, I have a satellite dish at home that has
]> encryption, after a fashion.
]
]That encryption is not of sufficient strength to protect data as
]sensitive as this. I would posit that any encryption scheme that
]is simple enough that a set-top box can decode it in real time, albeit
]with a known decoding algorithm; is insufficiently secure to stand
]up to a cryto-analytic attack of any great length of time.
That statement is false. A set-top box has enough computing power to
implement an algorithm like Skipjack or Blowfish, which have been
extensively attacked by the best cryptographers.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Information-theoretic hash question (was Re: CRC question)
Date: Fri, 7 Jul 2000 23:09:22 -0700
> What about larger hamming distances than 3?
Simple answer: I have no idea. What don't you work it out (or, at least,
write your own computer program and try it for yourself). You might not get
the answer for all N and all hamming distances, but at least you'll know
more than you do now...
>
> Scott Fluhrer wrote:
> >
> > Benjamin Goldberg <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > Hmm, what if I change it to bitlength(M) strictly-less-than 2**N,
> > > rather than less-than-or-equal ? Or do I have to use 2**(N-1) for
> > > it to work?
> > For hamming distance of 2, yes, that works. An N-bit CRC will always
> > detect a 1 or 2 bit difference for bitlength < 2**N if (and only if)
> > that CRC was based on a primitive polynomial.
> >
> > For hamming distance of up to 3, an N-bit CRC can detect that
> > different for bitlength < 2**(N-1) if that CRC is the (x+1)
> > polynomial multiplied with an N-1 degree primitive polynomial
> > (which is how most standard CRC polynomial are generated).
> >
> > >
> > > Broadening the question, and asking various permutations:
> > > 1) What is the maximum hamming distance that two Y-bit messages can
> > > have, and still have two different X-bit hashes?
> > > 2) What is the minimum hash size needed to detect differences in
> > > Y-bit messages which have a hamming distance Z?
> > > 3) What is the maximum message length for which an X bit hash can
> > > detect differences between messages which have a hamming distance of
> > > Z?
> > I'll let those be exercises for the reader...
> >
> > >
> > > Scott Fluhrer wrote:
> > > >
> > > > Benjamin Goldberg <[EMAIL PROTECTED]> wrote in message
> > > > news:[EMAIL PROTECTED]...
> > > > > Is it possible, for an N-bit CRC, for any n ( 1 <= n <= N )
> > > > > 1-bit changes in a message M ( bitlength(M) <= 2**N ), the
> > > > > output value changes?
> > > > No, unless N = 1
> > > >
> > > > Consider the 2**N messages consisting of 2**N-1 zeros and a one,
> > > > and the 1 message consisting of 2**N zeros. There is a total of
> > > > 2**N+1 messages here, and each pair of messages has either 1 bit
> > > > or 2 bit hamming distance. Since an N-bit CRC has only 2**N
> > > > possible values, there is a collision in here somewhere.
>
>
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Hash and Entropy
Date: Sat, 08 Jul 2000 07:14:05 GMT
Joseph Ashwood wrote:
> I forgot to address something in the secure hash definition that is
> important. Given a number generator of polynomial complexity, it
should be
> (close to) impossible to bias the output either towards or away from a
> subset of the output buckets (a superset of the previous statements).
> Joe
>
"Joseph Ashwood" also wrote:
[...]
> > A hash is a function that takes an input of an arbitrary
> > length, and creates an output of a fixed length.
There's a theoretical problem here. If the hash is fixed
size, than any subset of outputs is in P. There is a model
of a hash function in which output size is a parameter
"intractable" means super-polynomial. There's another model
that says output is fixed size and task is intractable if
the number of operations exceeds some fixed number such as
2^100. Mixing the models is problematic.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "John Doe" <[EMAIL PROTECTED]>
Subject: Suggestions for crypto for constrained-memory/CPU computers?
Date: Sat, 8 Jul 2000 00:44:26 -0700
I'm trying to protect sensitive data stored on a range of
constrained-memory/CPU devices (handhelds, etc.). The data would never
actually be *encrypted* on the device - larger/faster computers would handle
that - the little guy must be able to decrypt reasonably fast though.
I've seen algorithms that do the opposite: fast/easy encryption, intensive
decryption, but what I need is just the opposite. Any pointers and
suggestions would be much appreciated!
Jan
[EMAIL PROTECTED]
-- take out hohoho to email me
______________________________________________________________________
Posted Via Uncensored-News.Com - Still Only $9.95 - http://www.uncensored-news.com
With Servers In California, Texas And Virginia - The Worlds Uncensored News Source
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: CRC question
Date: Sat, 08 Jul 2000 07:30:24 GMT
Benjamin Goldberg wrote:
> Is it possible, for an N-bit CRC, for any n ( 1 <= n <= N ) 1-bit
> changes in a message M ( bitlength(M) <= 2**N ), the output value
> changes?
What does the "for any n ( 1 <= n <= N )" mean? You
don't refer to this n after quantifying it.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Turning off scripting
Date: 8 Jul 2000 07:55:10 GMT
[EMAIL PROTECTED] (Greg Keogh) wrote in
<[EMAIL PROTECTED]>:
>Hi Scott,
>
>It's a real pain in the you-know-what to have to turn off scripting just
>to visit your web site.
>
>Are you sure this is necessary? I'm not aware of any virus risks from
>JavaScript, and I only accept ActiveX controls from signed sources.
>Demanding that visitors turn off scripting and other advanced browser
>features seems to be somewhat dictatorial. I'm not sure what the point
>is. Are you protecting people from your own site, or are you suggesting
>that they keep browser security at the highest safety levels at all
>times, even after they leave your site?
>
>Cheers,
>Greg Keogh mailto:[EMAIL PROTECTED]
>(Melbourne Australia)
>
>
Of course its not necessary. I do it becasue so many sites
require JavaScript to be turned on and it makes me angry that
they really in most cases have no reason to use it. Think of it
as a protest.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS **no JavaScript allowed**
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed ** JavaScript OK**
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction
of the truth."
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: A thought on OTPs
Date: Sat, 08 Jul 2000 07:54:07 GMT
Douglas A. Gwyn wrote:
> "Tony T. Warnock" wrote:
> > A simple version is to note that the characters of the key are
independent
> > and identically uniformly distributed. Thus the probability of
getting a
> > particular cyphertext character is independent of the corresponding
> > plaintext character and of the position in the message. This is
based on
> > the fact that a convolution of a uniform distribution and any other
> > distribution on a circle is the uniform distribution.
>
> Unfortunately, that argument can also be applied to less secure
systems.
But he is close. The fact that each character of plaintext
is independent of the corresponding ciphertext character is
not sufficient to prove security. The fact that the entire
plaintext and ciphertext are independent implies an important
security property, called "perfect secrecy".
(Of course the usual warning about leaking the length of the
plaintext applies.)
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: A thought on OTPs
Date: Sat, 08 Jul 2000 08:07:35 GMT
Simon Johnson wrote:
[...]
> I agree with you, but i, and i'm sure the original poster does, find
it
> hard to put it down in writing how the OTP is secure. Does anyone know
> of a clear cut explanation for me to copy :)
For any text, the conditional probability of that
text being the plaintext given the ciphertext is the
same as the probability of that message being the
plaintext when _not_ given the ciphertext. (Subject
to the usual caveat about the lengths of texts.)
Thus giving away the ciphertext is safe.
That proves one important security property: protection
from the ciphertext exposing the plaintext. Shannon was
careful to call it "perfect secrecy" and not "perfect
security"; there are other attacks an adversary may
launch besides trying to deduce the plaintext.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: A thought on OTPs
Date: Sat, 08 Jul 2000 08:19:10 GMT
Mok-Kong Shen wrote:
> "Douglas A. Gwyn" wrote:
>
> > Mok-Kong Shen wrote:
> > > Also I asked sometime back whether there are good tests for
> > > independence in practice but failed to get a concrete answer.
> >
> > I think you got answers, but just didn't like them.
> > "Independence" of events is a theoretical notion used in models.
> > It is not directly testable, but its consequences are testable
> > with the usual statistical tools of hypothesis testing.
>
> If these 'consequences' that you mean (I am not aware, please name
> these) could not be related mathematically to what I want to test,
> namely independence, then they are of no use to me for my enquiry,
> isn't it?
Nonsense. The answer again: given two black-box sources
we can in many cases reliably refute independence, but
cannot reliably establish independence where it exists.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: CRC question
Date: Sat, 08 Jul 2000 08:43:42 GMT
Bryan Olson wrote:
>
> Benjamin Goldberg wrote:
> > Is it possible, for an N-bit CRC, for any n ( 1 <= n <= N ) 1-bit
> > changes in a message M ( bitlength(M) <= 2**N ), the output value
> > changes?
>
> What does the "for any n ( 1 <= n <= N )" mean? You
> don't refer to this n after quantifying it.
Umm, maybe I should have said it as "for any n 1-bit changes ( 1 <= n <=
N )," instead of the way I did?
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Another AONT (less expensive, this time)
Date: Sat, 08 Jul 2000 08:43:50 GMT
I earlier suggested an AONT that, while good in terms of fulfilling the
properties of what an all-or-nothing-transform needs to do/be, was
computationally expensive { O(N**2) wrt message length }.
I have a new idea, which is much less expensive...
The following is both to transform, and to reverse the transform:
( a, x ) = ( first-20-bytes-of-message, rest-of-message )
b = a XOR SHA1( x )
y = ARC4( b, x )
c = b XOR SHA1( y )
transformed-message = c || y
Perhaps using RC4/ARC4 is an overcompensation for the slowness of the
previous AONT I suggested, you decide :) I will point out, though, that
using a stream cipher simplifies things... only one function is needed
to transform/detransform.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: cray and time needed to attack
Date: Sat, 8 Jul 2000 02:45:45 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> At least the way I do arithmethic, the difference is 1000:1.
Sorry for the typo -- that should (of course) be 100:1.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: David Blackman <[EMAIL PROTECTED]>
Subject: Re: Suggestions for crypto for constrained-memory/CPU computers?
Date: Sat, 08 Jul 2000 20:04:59 +1000
John Doe wrote:
>
> I'm trying to protect sensitive data stored on a range of
> constrained-memory/CPU devices (handhelds, etc.). The data would never
> actually be *encrypted* on the device - larger/faster computers would handle
> that - the little guy must be able to decrypt reasonably fast though.
>
> I've seen algorithms that do the opposite: fast/easy encryption, intensive
> decryption, but what I need is just the opposite. Any pointers and
> suggestions would be much appreciated!
>
> Jan
> [EMAIL PROTECTED]
> -- take out hohoho to email me
The AES finalists look pretty good for this. They can all run in less
than 200 Bytes Ram plus a K or two of ROM. On such small computers they
aren't particularly fast, but a few hundred bytes per second should be
possible. If you have a few KBytes of RAM all of them become much
faster. These algorithms have all been exposed to a lot of scrutiny in
the standards process, and appear to be secure so far.
Serpent is my favourite of the bunch, but Rijndael and Twofish will also
run on extremely small machines (< 64 bytes RAM!). Most of the AES
finalist algorithms are available with free source code and no licence
fees. Certainly Serpent, Rijndael and Twofish are.
http://csrc.nist.gov/encryption/aes/
Alternatively, you could take one of those easy encrypt/ hard decrypt
algorithms you know about, and reverse it. IE, encrypt by using the
"decrypt" algorithm on a fast computer, and decrypt by using the
"encrypt" algorithm on the handheld. I haven't heard of any of these
algorithms. I'm not sure if they would really be secure. But if they
work properly as is, chances are good they would also work in reversed
mode.
------------------------------
From: Ryan Healey <[EMAIL PROTECTED]>
Crossposted-To: sci.chem.analytical,sci.energy,sci.electronics.design
Subject: Re: University Job Bank - Free Job Posting/Search
Date: Sat, 08 Jul 2000 10:53:35 GMT
PLEASE DON'T SPAM US
"UJobBank.com" wrote:
> FYI.
>
> University Job Bank < http://www.UJobBank.com > provides free services
> to all universities/colleges to advertising jobs including faculty,
> staff and postdoctoral positisions, graduate assistantships, and
> internships and other job opportunities.
>
> Students/job seekers can post resume for free at University Resume Bank
> <http://www.UJobBank.com/resume>
>
> Please share the information with your colleagues and students.
>
> Regards,
>
> --
> --------------------------------------------
> Find a job at the University Job Bank
> http://www.UJobBank.com
>
> UJobBank - Jobs for U
> --------------------------------------------
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Compression & Encryption in FISHYLAND
Reply-To: [EMAIL PROTECTED]
Date: Sat, 8 Jul 2000 10:02:29 GMT
Kurt Shoens <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
:>To think that inadequate key management is the *only* case where the
:>ability to rapidly reject bad keys helps does not appear to be correct.
:>
:>Consider the case where the attacker has a known-plaintext attack on the
:>algorithm. Here, sections of the key may be revealed even if the
:>management of the key has otherwise been excellent.
: I'm speaking in the context of current algorithms considered to be
: secure. Such algorithms are expected to be immune to chosen plaintext
: attacks. If having a fixed block of zeros encrypted were useful, a
: chosen plaintext attack could have that information. [...]
: Sure, if you choose an algorithm susceptible to known plaintext
: attacks, then 1-1 compression may help. But why make that choice
: with so many sound alternatives available?
There are practically no algorithms which are known to be secure against
known plaintext attacks. All we can usually say is that we don't
currently know of any such attacks. Since I don't know what attacks my
opponent is aware of, I would avoid providing him with clues such as
known plaintext unnecessarily, wherever possible.
:>If it takes frequency analysis on a significant volume of the message
:>to spot a correct plaintext, then that's obviously going to be slower
:>than (say) the case of looking for a header of all-zeros in the first block.
: I am willing to stipulate that 1-1 compression will require decrypting
: the entire file to check a key in a brute force attack. For example,
: with 16-byte blocks, the work factor for a 1 megabyte file would be
: increased by 2^16. Alternatively, with apparently little or no cost,
: you could choose 256-bit keys rather than 128-bit keys in AES.
: In any event, why worry about it? Brute force attacks on 128-bit keys
: aren't feasible on single blocks anyway.
: To put it more plainly, 1-1 compression makes an already infeasible
: attack slower, so it accomplishes nothing.
Why is brute-force necessarily infeasible? I've previously enumerated all
manner of cases where the keyspace can be reduced through bugs, theft,
torture, carelessness, espionage, and so forth - and having better halting
criteria can help, especially with relatively short messages.
:>"Bad key management" reduces the search space. It doesn't affect whether
:>the search is looking for something it knows how to recognise. You can
:>still have some pretty good encryption with a key-space of only 2^8 keys.
: I can't see how 8-bit keys will be satisfactory, but in any event, who
: cares? We can have symmetric key sizes as large as we need and far
: beyond the reach of brute force attacks.
Because it's quite possible that those keys can be partly bypassed by
cryptanalytic attack, theft, espionage, and so forth.
8-bit keys can be quite satisfactory - *if* both you and the opponent
know you're only ever likely to want to send 256 different messages.
In essence, you can number the messages, and then use a OTP.
Here, the opponent doesn't have a halting criterion he can apply.
: While presenting the advantages of 1-1 compression, you've indicated
: its value in the context of bad choices, such as a presenting an
: attacker with a small search space of keys or choosing a poor encryption
: algorithm. Security is better served by avoiding the poor choices.
Of course - but how are you going to make sure you've done that?
These measures can help defend against the possibility that the office
the messages are sent from is being bugged, or a huge number of other
possible security leaks.
You *don't* give your opponet the keys to the safe just because the safe
is in a locked room, and therefore is already secure.
You keep the keys to yourself, to defend against the possibility that he
tunnels up through the floor.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ The end.
------------------------------
Subject: pic alogrithm ?????
From: dueyftw <[EMAIL PROTECTED]>
Date: Sat, 08 Jul 2000 04:51:06 -0700
I'm going to ask again. Here is an alogrithm that I have come
up with. Is this good, bad or crap?
Dale Morgan picture encryption.
This encryption will have three pictures files for keys. Only
one picture will be known by sender and receiver. The other two
will be inbeded into the program. Picture One will be only know
to the maker of the program. Picture Two will be an control that
will only be know to the control person who distributes the
software. The third Picture will be the user picture that will
be sent or agreed on in some secret fashion.
The first and second key file may be a random generated file.
The third picture file should be a pictures file for ease of
remembering. The whole program and any pictures files that it
uses should never be in a computer when not in use. Otherwise it
would be like leaving ones keys in a door.
The algorithm:
File to be encrypted: F
Encrypted file pulse x number of rounds: F(x)
Picture One: P1
Picture two: P2
Picture Three: P3
Offset: OS
Bits Added for overflow and sign: B( X)
If the first byte of P1 is even then:
F+P1-P2+P3= F(1),B Adding Bytes (not bits)
If the first byte ofP1 is odd:
F-P1+P2-P3=F(1),B
B will be three bits used to remember sign and over flow.
When 24 bits is reach
it will be split into three bytes and used as hash into F(1)
I.E.. For a three rounds example:
F= a or F=65 P1= 124,23,56,224 P2= 67,89,255,90 P3=
100,101,123,54 (The
first four bytes of each file)
65+124-67+100= 222, 001 or F(1)=222 and B(1)= 001 no
overflow and positive
with an offset value of 1(can and should be a higher value) :
OS=1 the next round would be,
222-23+89-101=188, 001 or F(2)=188 and B(2)=001001
third round:
188-56+255-123=9,011 or F(3)=9 and B(3)=001001011
Thanks Duey
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
** 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
******************************
