Cryptography-Digest Digest #454, Volume #11 Fri, 31 Mar 00 06:13:01 EST
Contents:
Chronometric Cryptography ("Dan Coyle")
Re: Does the NSA have ALL Possible PGP keys? (Don Bruder)
md5 spoofing (Jeff Sutch)
Re: http://www.cryptomat.com ("Borys Pawliw Newsgroups")
Re: Does anybody know of a secure FTP server? (Paul Rubin)
Re: Q: Entropy (Pascal JUNOD)
Re: Q: Entropy (Mok-Kong Shen)
Re: new Echelon article (Arturo)
Re: Chronometric Cryptography (Mok-Kong Shen)
Re: md5 spoofing (Casper H.S. Dik - Network Security Engineer)
Re: Coderpunks Query on Teledyne Crypto ([EMAIL PROTECTED])
Re: Coderpunks Query on Teledyne Crypto ([EMAIL PROTECTED])
Re: Key exchange using Secret Key Encryption ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: "Dan Coyle" <[EMAIL PROTECTED]>
Subject: Chronometric Cryptography
Date: Thu, 30 Mar 2000 22:49:54 -0600
Dan Coyle ( [EMAIL PROTECTED] )
I have been working on a project for a while now, and was wondering if
anyone here might have some feedback, Good Idea/Bad Idea/???.
In most cases, that I've seen, key size seems to be the determining factor
in judging the effective security provided by any given cipher. That is, a
cipher with a 128-bit key is usually judged to be better than a cipher with
a 56-bit key. This isn't always the case, I know, but where a stronger
cipher is needed, a person usually increases the bit size of the key. Each
time this is done the application/object that needs to use the cipher, needs
to be updated, and a new version of the product released. Key size is also,
usually, the key factor in determining if the application/object can be
exported to other countries.
A simple solution to this problem would be to create a cipher that uses
processing time as a primary determinate for it's measure of security. That
is, create a cipher that took just as long to encrypt any given plaintext
into ciphertext, as it does to convert that ciphertext back into plaintext.
Therefore allowing the application/object to determine the measure of
security at run-time instead of design-time. In addition, when technology
changes, and more powerful machines are made that can resolve ciphertext
back into plaintext using brute force methods, the hardware which executes
the cipher is the only component that what would need upgrading because the
cipher would still take the same amount of time to execute, it just gets
more cycles to do it's job. I call this type of cipher, a Chronometric
cipher meaning a cipher whose security is measured by time.
Example :
User A encrypts a message in 1995 using a 56-bit key Chronometric cipher
on a 100MHz Pentium Machine for 1 second. In 2000, User A uses the same
application with the same 56-bit Chronometric cipher on a Pentium III 700MHz
machine for a second. Because the user is on a faster machine when he
encrypts the second message, it does more work while encrypting the message,
making it more secure, even though it's the same program, and underlying
algorithm.
Another advantage that a Chronometric cipher would bring, is that a
malicious user, attempting a brute force attack, to decrypt the message,
would have to decrypt the message with, at least, the same amount of
processing effort. Even more, as long as the malicious user is not aware
how much processing effort was put into encrypting the message, he/she would
have to hazard a guess, to how much processing effort to use while
attempting to brute force the decryption.
There are, however, some drawbacks to such an algorithm.
1. The Recipient, of the ciphertext, has no idea how much processing effort
it will take to decrypt an encrypted message.
2. Faster machines would either speed up the process, or make it more
secure, but not both.
3. If an incorrect key is used, it would result in, what would appear to be,
an infinite loop.
After some time, and effort, I put together a prototype, and it seems to
work pretty well. I've spent most of my time doing Cryptanalysis, and I
think I've tied down most of the weak spots.
The basic algorithm I used was as follows
User A enters a message M, a key K, and a time period P
KS <- Hash(K)
Ki <- KS
TargetTime <- CurrentTime + P
While (CurrentTime < TargetTime) do
Begin
M <- EncryptMessage(M,Ki)
Ki <- GenerateNextKey(M,Ki)
End
KF <- KS Xor Ki
M <- Concat(M,KF)
KS - StartKey
Ki - Iteration Key
KF - FinalKey, stored within the final message.
Hash - A Hashing Function
EncryptMessage - Any Symmetric Key Cipher function
GenerateNextKey - A function that Generates the next Iteration Key, based on
the old Iteration Key and the Current Message
To decrypt the message I use the following algorithm
User A enters a message M, with Final Key KF Concatenated to it, and Key K
KS <- KF Xor Hash(K)
Ki <- KS
While (KS <> K) do
Begin
Ki <- GeneratePrevKey(M,Ki)
M <- DecryptMessage(M,Ki)
End
Thank you for your time.
DC
------------------------------
From: Don Bruder <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Thu, 30 Mar 2000 21:40:40 -0800
In article <[EMAIL PROTECTED]>, "Douglas J. Renze"
<[EMAIL PROTECTED]> wrote:
: Probably the fastest way would be to put a gun to your
: son/daughter/wife's head and say, "Give me the key or I'll pull the
: trigger."
:
: Any one of those would be effective. I know the last of the 3 would
: definitely work for me.
Ahhh... hostages to fortune. You poor man, you.
--
--
Don Bruder - [EMAIL PROTECTED]
Horseman by day, 'net-freak by night. What a contrast, eh?
Make 50 cents (or more...) per hour when surfing by signing up
here: www.alladvantage.com/join.asp?refid=KJW570
------------------------------
From: Jeff Sutch <[EMAIL PROTECTED]>
Subject: md5 spoofing
Date: Thu, 30 Mar 2000 21:01:26 -0800
I heard an account of spoofed md5sums from system binaries today, that
I can't seem to verify anywhere. Does anyone know of a validated process
to modify a binary so that it can't be md5summed?
------------------------------
From: "Borys Pawliw Newsgroups" <[EMAIL PROTECTED]>
Subject: Re: http://www.cryptomat.com
Date: Fri, 31 Mar 2000 15:58:45 +1000
Geez, I feel like such a schmuck!
Still, the info below is not of any real help to them: if they even break a
normal PGP message in a few weeks, that is something that is worthy of a
Nobel prize...
Borys.
Tim Tyler <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Borys Pawliw Newsgroups <[EMAIL PROTECTED]> wrote:
>
> : I sent them a PGP 6.5.3 encrypted ciphertext message, with a few tricks
to
> : it...:
>
> : 1) The beginning and end of the plaintext I used was a series of numbers
and
> : characters such as #$^%, just to make a known/attempted plaintext attack
a
> : little harder...
>
> : 2) The ciphertext was modified a bit, so that the first character in
each
> : l64 charctare line of ciphertext, if it was upper case, was changed to
> : lowercase and vice-versa...
>
> ...but now you've published some "clues" in a public place - on a thread
> with their URL in it no less! ;-)
> --
> __________
> |im |yler The Mandala Centre http://mandala.co.uk/ [EMAIL PROTECTED]
>
> 2002 - the next year of the palindrome.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Does anybody know of a secure FTP server?
Date: 31 Mar 2000 07:13:29 GMT
In article <[EMAIL PROTECTED]>,
Jaime Cardoso <[EMAIL PROTECTED]> wrote:
>For the hardware, be aware, SSL uses a lot of calculations so, Intel
>should be the last resource HW platform for you. If you are going
>with an SSL server, you can increse your performance xfold (10X to
>20X or more) if you use a CPU that is good with math (UltraSparc,
>Alpha or SGI).
The Intel PII/III and AMD K6 and K7 are quite fast for SSL with good
software. On a 500 mhz PIII you should be able to do >100 secret key
operations per second. This is faster than a low end ($5000) NCipher
accelerator (I'm not familiar with Rainbow).
I don't think accelerators are cost effective any more. Because the
market for them is limited, they're always behind the hardware technology
curve. What some of them are good for is secure key management, and
I sometimes use them for that.
Btw, the Sparc v8/v9 has very slow integer multiplication and the
widespread implementations that I know of are much slower than the
corresponding x86 implementations. You can do somewhat better by using
the floating point processor, but Intel processors are still a lot faster.
I am saying this after having benchmarked all four processors I've
mentioned. From fastest to slowest: K7, PII/III, K6, Sparc.
I haven't done any timings on SGI or Alpha but I don't see how they
can approach the X86's in cost effectiveness if you're just doing SSL.
------------------------------
Date: Fri, 31 Mar 2000 07:49:08 +0000
From: Pascal JUNOD <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Q: Entropy
> Well, there's the definition:
>
> entropy of x, in bits = - log_base_2(probability(x))
This definition is false ! The exact one is
X ... discrete random variable
entropy H(X) = - sum p_i * log_2 (p_i)
where the sum is taken over all the elements with a probability > 0.
A+
Pascal
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Pascal Junod, [EMAIL PROTECTED] *
* Route d'Yverdon 25, CH-1028 Préverenges, Switzerland *
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Entropy
Date: Fri, 31 Mar 2000 10:07:33 +0200
Tim Tyler wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> : Given an arbitrary (finite) bit sequence, how does one actually
> : go about in practice to determine the entropy it contains?
>
> Pick a language and then employ "search techniques" to find the shortest
> possible description of your bit sequence in that language.
>
> : Are there concrete and dependable (accurate, exact) algorithms?
>
> No. There are various algorithms that *purport* to measure the entropy
> of a stream or file - e.g. "ENT": http://www.fourmilab.ch/random/
>
> However these generally produce crude estimates, with little logical
> connection to the actual entropy of the sequence w.r.t. any sensible
> language.
>
> Calculating entropy generally runs into the Halting problem.
>
> Except for trivially short or simple sequences, there will be shorter
> programs than your current best candidate that do not halt.
>
> *Proving* that these programs don't halt and output your target
> sequence can be "a little bit tricky". See the work of G J Chaitin
> (http://www.cs.auckland.ac.nz/CDMTCS/chaitin/) for more about this.
>
> General entropy resource: "Entropy on the World Wide Web":
> http://www.math.washington.edu/~hillman/entropy.html
Thank you. My point is that people have been apparently using
in cryptology a measure that is not reasonably computable in
except by doing some guess work. A consequent (provocative) question
is then how much real meaning one can attach to argumentations in
which this measure plays a role in practical applications.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]=NOSPAM (Arturo)
Subject: Re: new Echelon article
Date: Fri, 31 Mar 2000 07:07:53 GMT
On Thu, 30 Mar 2000 17:36:56 GMT, [EMAIL PROTECTED] (JimD)
wrote:
>On Thu, 30 Mar 2000 13:34:48 GMT, [EMAIL PROTECTED] (Lincoln Yeoh)
>wrote:
>
>I don't understand it either. It isn't at all easy to intercept a
>mobile 'phone off the air. It's encrypted and it moves around.
For what I heard, itīs not so difficult to scan mobile phones inside
one "cell" (I donīt know the exact procedure, but it seems like it can be
done with a laptop computer). As for the encryption, it is computationally
equivalent to 40 bits (or less), well within reach of anybody with a
medium-size computer. You save the transmission and then decrypt it
on-line, or you can even decrypt in real time if you have enough computing
power.
>Here in democratic bloody Britain, where they tap 'phone lines at
>will without judicial authority, it would be very much easier for
>them to order a tap the landline side.
Yes. But that needs a court order. Eavesdropping means nobody
cares about asking for permission.
>This may (probably) cause
>them a problem with mobile-mobile. There may also be problems with
>calls _to_ a mobile 'phone.
Not really. They need merely install tapping ports at the receiving
cells, or somewhere else in the system. After all, mobile phone messages
donīt go right from a phone to another, they must be directed.
>Let's hope their problems increase many-fold!
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Chronometric Cryptography
Date: Fri, 31 Mar 2000 10:30:16 +0200
Dan Coyle wrote:
>
> A simple solution to this problem would be to create a cipher that uses
> processing time as a primary determinate for it's measure of security. That
> is, create a cipher that took just as long to encrypt any given plaintext
> into ciphertext, as it does to convert that ciphertext back into plaintext.
> Therefore allowing the application/object to determine the measure of
> security at run-time instead of design-time. In addition, when technology
> changes, and more powerful machines are made that can resolve ciphertext
> back into plaintext using brute force methods, the hardware which executes
> the cipher is the only component that what would need upgrading because the
> cipher would still take the same amount of time to execute, it just gets
> more cycles to do it's job. I call this type of cipher, a Chronometric
> cipher meaning a cipher whose security is measured by time.
One problem you should note is that you generally don't exactly
know the resources of the opponent. He may have 100, 1000 or 10000
processors. So the moderate factor of increase in MHZ of chips
with time is not that determining, I suppose.
If you have (or believe to have) an idea of how long the (proper,
i.e. knowing the key) decryption time should be in order to render
the brute force time of the opponent imfeasible, then the best way
I believe is to use a cipher that is parametrized in diverse
aspects, in particular in the number of rounds. Through tuning
the parameters you could arbitrarily increase the processing time
to that you want. See my humble WEAK3-EX available on my web page.
M. K. Shen
==============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED] (Casper H.S. Dik - Network Security Engineer)
Subject: Re: md5 spoofing
Date: 31 Mar 2000 09:41:42 GMT
[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]
Jeff Sutch <[EMAIL PROTECTED]> writes:
> I heard an account of spoofed md5sums from system binaries today, that
>I can't seem to verify anywhere. Does anyone know of a validated process
>to modify a binary so that it can't be md5summed?
That would have been headline news; some weaknesses are suspected, but
no way to generate a modified binary with the same md5 or even any file with
the same md5 has yet been found.
CRC checksums are easily and routinely faked by hackers.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Coderpunks Query on Teledyne Crypto
Date: Fri, 31 Mar 2000 09:52:26 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> John Savard wrote:
> > As to what an orthomorphic permutation is, I did not see a clear
> > explanation of that in the patent.
>
> Just from analyzing the word, perhaps it means a transformation
> of a set to an orthogonal (anticorrelated) set. Maybe this
> refers to the one-bit-changes-everything aspect.
>
I also think so, orthomorphic might be used as a term somewhat opposed
to isomorphic. But in defining it, you have to talk about this property
respective to some relation between two (or more sets).
An isomorphy between two sets N and M regarding to some relation R can be
defined the following (didn't look it up though, sorry if it isn't 100%
correct):
(1) There is a bijective function f: N --> M such that each element of N
is mapped to an element of M, and the inverse of f maps each element of M
to the respective element of N, i.e. each element of N is associated with
an element of M and vice versa, and no two different elements of N are
associated with the same element in M and vice versa
(2) If for two elements <a,b> of N relation R holds R(a,b), then relation
R also holds for the respective elements in M, i.e. R(f(a), f(b))
(3) If (1) and (2) are fullfilled the two sets are isomorphic regarding
to relation R
For example, if N={1,2,3} and M = {2,4,6} and relation R is > "greater
than", N and M are isomorphic because f(n) = 2n is a bijective relation
over N and M, and if e.g. 2>1 (in N), also 4>2 holds, etc.
Now, orthomorphic perhaps is about some similar property, except that N
and M are guaranteed *not* to fullfill (2). For example, if you take R to
be an ordering relation (like e.g. > also is), function f would
guarantee that for each pair <a,b> in N, if R(a,b) then NOT(R(f(a),
f(b))) holds. In this example, f would ensure that the ordering of M (as
defined by R) is always different than the ordering of N.
As an example,for N = {1,2,3} regarding to relation > "greater than",
f(n) = n*-1 would ensure that N and M are orthomorphic regarding greater
than, because if e.g. 2>1 the respective relation in M (2*-1) > (1*-1) is
wrong, and so for each other argument of f as well.
Just an assumption, maybe they mean something completely different by
"orthomorphic". And sorry if my definitions weren't correct...
Greetings,
Erich Steinmann
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Coderpunks Query on Teledyne Crypto
Date: Fri, 31 Mar 2000 10:15:17 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> John Savard wrote:
> > As to what an orthomorphic permutation is, I did not see a clear
> > explanation of that in the patent.
>
> Just from analyzing the word, perhaps it means a transformation
> of a set to an orthogonal (anticorrelated) set. Maybe this
> refers to the one-bit-changes-everything aspect.
>
I also think so, orthomorphic might be used as a term somewhat opposed
to isomorphic. But in defining it, you have to talk about this property
respective to some relation between two (or more sets).
An isomorphy between two sets N and M regarding to some relation R can be
defined the following (didn't look it up though, sorry if it isn't 100%
correct):
(1) There is a bijective function f: N --> M such that each element of N
is mapped to an element of M, and the inverse of f maps each element of M
to the respective element of N, i.e. each element of N is associated with
an element of M and vice versa, and no two different elements of N are
associated with the same element in M and vice versa
(2) If for two elements <a,b> of N relation R holds R(a,b), then relation
R also holds for the respective elements in M, i.e. R(f(a), f(b))
(3) If (1) and (2) are fullfilled the two sets are isomorphic regarding
to relation R
For example, if N={1,2,3} and M = {2,4,6} and relation R is > "greater
than", N and M are isomorphic because f(n) = 2n is a bijective relation
over N and M, and if e.g. 2>1 (in N), also 4>2 holds, etc.
Now, orthomorphic perhaps is about some similar property, except that N
and M are guaranteed *not* to fullfill (2). For example, if you take R to
be an ordering relation (like e.g. > also is), function f would
guarantee that for each pair <a,b> in N, if R(a,b) then NOT(R(f(a),
f(b))) holds. In this example, f would ensure that the ordering of M (as
defined by R) is always different than the ordering of N.
As an example,for N = {1,2,3} regarding to relation > "greater than",
f(n) = n*-1 would ensure that N and M are orthomorphic regarding greater
than, because if e.g. 2>1 the respective relation in M (2*-1) > (1*-1) is
wrong, and so for each other argument of f as well.
Just an assumption, maybe they mean something completely different by
"orthomorphic". And sorry if my definitions weren't correct...
Greetings,
Erich Steinmann
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Key exchange using Secret Key Encryption
Date: Fri, 31 Mar 2000 10:37:44 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (wtshaw) wrote:
> In article <8bvdfk$ghs$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> > Strangely enough, many "secure" connections, such as those used in
> > browsers, completely ignore the man-in-the-middle problem.
> >
> The excuse given is that things happen so fast that it would be
difficult
> to set up a man-in-the-middle. But, with active secret spies in a
machine,
> the situation can be setup quickly, as those wanting to intercept your
> communications can make it automatic.
I agree. One must realize that a man-in-the-middle attack can be setup
in many different ways and at many different places. Trojans can be
installed on the client, server or a router or firewall etc. Making the
process automatic is simple, you only need to find out the protocol
used.
-Erik Runeson
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
