Cryptography-Digest Digest #563, Volume #10 Sat, 13 Nov 99 13:13:03 EST
Contents:
Re: smartcard idea? ("ME")
Re: What's gpg? <PHILOSOPHY 101> ("Mark Keiper")
Specific use of a hash function ? (thomas)
Re: Enigma Machine: fair market value
Re: Cryptography for Dummies (Paul Crowley)
Re: Need technique for about 24 bytes (Paul Crowley)
about the win rng using the timer (Tom St Denis)
Re: Specific use of a hash function ? (Tom St Denis)
Re: ENCRYPTOR 4.0 by Comotex USA Inc. CRACKED !! (fungus)
Re: smartcard idea? (John Bailey)
Re: Ultimate Crypto Protection? (fungus)
Re: Can the SETI@home client be protected? (fungus)
intelligent brute force? (Keith A Monahan)
scott16u contest (SCOTT19U.ZIP_GUY)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Coen Visser)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Coen Visser)
Re: Enigma Machine: fair market value (David Hamer)
Re: Need technique for about 24 bytes ("Gary")
----------------------------------------------------------------------------
From: "ME" <[EMAIL PROTECTED]>
Subject: Re: smartcard idea?
Date: Sat, 13 Nov 1999 19:54:59 +1100
non-PKI authentication?
Go to an ATM, and withdraw funds (ideally, yours - it saves later hassles)
and you have just used non-PKI electronic authentication.
It's used about 16 billion times a year in the USA alone.
Lyal
Mok-Kong Shen wrote in message <[EMAIL PROTECTED]>...
>Craig Inglis schrieb:
>>
>> I wonder what it would cost to design a credit card sized smartcard
>> with a numeric keypad, a little LCD display, and a processor
>> powerful enough to a 2048bit modular exponentiation?
>>
>> Then, a user could use this (or any other card) to authenticate
>> interactive transactions utilising a small shared secret, without
>> any need for a PKI.
>>
>> The user would tap in a few details on the card...
>>
>> Account: 12345678
>> Amount: 123.45
>> PIN: *******
>>
>> Then place the card in a suitable docking receptacle connected
>> to the phone network (or internet, or WAP, or whatever) which
>> allows the card to communicate with a remote authentication
>> server.
>>
>> It then authenticates using a mechanism like SPEKE, SRP,
>> SNAKE, or whatever, and on success provides some form
>> of transaction identifier... which could be verified by the
>> docking station, and 'claimed' by its owner.
>>
>> The card to come with a large random number set at the
>> factory which it could use to generate different pseudo
>> random numbers for each authentication.
>>
>> Does anyone have any links to non-PKI based identification
>> schemes??
>>
>> ta
>>
>> Craig.
------------------------------
From: "Mark Keiper" <[EMAIL PROTECTED]>
Subject: Re: What's gpg? <PHILOSOPHY 101>
Date: Sat, 13 Nov 1999 05:33:56 -0500
Dennis Ritchie... Inventor of C?
*wonders if he is walking among giants*
mk
Dennis Ritchie <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> John Savard wrote (first quoting):
> > > .... As the class came to an end, the student woke up and copied the
> > >problems from the board, thinking they were his weekend homework
assignment.
> > >He labored away and when he returned to class the beginning of the next
> > >week, he had the solution to one of them. 1 out of 3 ain't bad. If you
> > >believe it's impossible to accomplish something- guess what- you're
right.
> >
> > Yes, this really happened; it's not an urban legend. That was Paul
> > Cohen, and his proof that the negation of the Axiom of Choice was
> > compatible with set theory, wasn't it?
>
> Well, the independence of AC and GCH, and the forcing method,
> are Cohen's most memorable contributions that I know of, but
> he neglected to mention the waking-up business in his 1966 monograph
> and in the 1965 course at Harvard in which he discussed
> the then-new (1963) result. I'd want to see some direct testimony
> before believing this particular story.
>
> Dennis
------------------------------
From: thomas <[EMAIL PROTECTED]>
Subject: Specific use of a hash function ?
Date: Sat, 13 Nov 1999 11:34:09 +0100
Hello,
I have a file of employees with their name, surname, date of birth and
another data.
I want to attribute an ID number to each employee.
Can I use a hash function ?
For some reasons, the personal data of my employees must not be found
with the knowledge of the ID. This is the reason why I think about a
hash function.
MD5, SHA-1, RipeMD160, what is the best ?
And what about if I only take 8 or 10 bits in the hash for the ID ? I
suppose the efficiency of the hash would not be as stronger as if I take
the whole hash but what this will affect ? privacy only or collisions
too ?
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Enigma Machine: fair market value
Date: 13 Nov 99 11:19:58 GMT
zenlight ([EMAIL PROTECTED]) wrote:
: Does anyone know what the fair market value of
: an enigma machine is?
I've been told they go for $10,000 and up at auction.
John Savard
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Cryptography for Dummies
Date: 13 Nov 1999 10:45:32 -0000
"Joseph Ashwood" <[EMAIL PROTECTED]> writes:
> If your $saltedpass is not as long as your hash functions input then it
> would certainly be advantageous to find another hash function, because no
> matter what you do it can be found.
If the hash function is strong, then finding a preimage will be
infeasably difficult even where an existing preimage is shorter than
the output of the hash function. So I don't think you need worry
about this. Especially since it might be read as persuading people to
go for hash functions with shorter outputs, which would be a mistake.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Need technique for about 24 bytes
Date: 13 Nov 1999 11:25:06 -0000
Caesar Valenti <[EMAIL PROTECTED]> writes:
> I am in need of finding source code that will encode (and decode, of
> course) a string of about 24 characters. Out of necessity, the string
> will only consist of the 36 alpha numeric characters (case insensitive)
> The encrypted string is also limited to the same 36 characters. The
> encrypted string should be about the same size as the original.
>
> The code should relatively short and easy to implement.
Then you're out of luck, because I think all the solutions are at
least somewhat tricky. Sorry!
If you allow the ciphertext to be a little bigger than the plaintext,
it's pretty easy: with a little cunning, you can use a stream cipher
like RC4. You have to prepend the ciphertext with some "spice", such
that the same (key,spice) pair is never used twice. If all the
encryption with a particular key is done from a single host, that can
maintain a counter for the spice, and that doesn't encrypt very often,
you might only need two or three letters of spice. If on the other
hand hundreds of uncoordinated hosts are encryptingwith the same
secret key, and you can't even issue each host a serial number, the
spice needs to be rather bigger; worst case is around 26 letters.
Note that the RC4 CPRNG produces outputs in the range 0-255. Just
discard successive outputs until you get one in the range 0-35, then
add the output to the next charater in your stream; if you prefer to
go faster, discard outputs outside the range 0-251, then divide each
output by 7 before using it. Because of some nasty properties with
RC4, it's usually a good idea to discard the first 256 characters of
output before you start.
If the ciphertext must be *exactly* the same size as the plaintext,
you have a bigger problem. If you need it to be fast too, you have a
really big problem, so I'll assume you don't. Unfortunately, it means
building a new cryptosystem, so any solution I propose could have big
security holes I don't know about, but it's a fun problem, so I'll
give it a stab anyway, with a Feistel cipher.
This system is based on the way of using RC4 I described in the
paragraph above; it uses a key K to encrypt a stream of alphanumerics
P into another stream of the same length C, so C = E(K, P).
Decryption P = D(K, C) is the same, but using subtraction instead of
addition. One more bit of notation: "." is string concatenation.
I'll assume your input is exactly 24 characters. Divide it into two
halves, L_0 and R_0. Your secret key is K. Now we build a simple
four-stage Feistel cipher.
L_1, R_1 = R_0, E(K . "1" . R_0, L_0)
L_2, R_2 = R_1, D(K . "2" . R_1, L_1)
L_3, R_3 = R_2, E(K . "3" . R_2, L_2)
L_4, R_4 = D(K . "4" . R_3, L_3), R_3
Note that there's no swap in the last step, and E and D alternate.
This is so decryption has the same structure:
L_1, R_1 = R_0, E(K . "4" . R_0, L_0)
L_2, R_2 = R_1, D(K . "3" . R_1, L_1)
L_3, R_3 = R_2, E(K . "2" . R_2, L_2)
L_4, R_4 = D(K . "1" . R_3, L_3), R_3
The "1", "2" and so on are there to prevent slide attacks, by making
sure that each step is distinct. The value of the string doesn't
really matter here: you could use "one", "two" and the security would
be the same. This is maybe a day's work or less for an experienced
Perl programmer and cryptographer.
In theory this should provide you with all the security you can get
under the circumstances. In practice... any of the friendly
neighbourhood sci.crypt cryptanalysts care to take a look? David Wagner?
Sorry it's so much more difficult than you'd hoped.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: about the win rng using the timer
Date: Sat, 13 Nov 1999 12:17:01 GMT
I ran my version of his rng for 2^20 bits and got some results...
Order-16 analysis, lo=?[can't remember sorry], hi=34, me=16,ame=~6500
lo = lowest count
hi = highest count
me = median
ame = # of counts at median
I am doing a bigger test now. Generally though i think it will do
well. The order-0 stats are good.
I will do a 32x65536 test today [under 'load' conditions of
icq+winamp+email] and copy the results. I will also check out # that
are close to median [+/- 4 which is 12.5% error].
I think under 'load' conditions which is pretty much all the time, this
rng works well.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Specific use of a hash function ?
Date: Sat, 13 Nov 1999 12:41:08 GMT
In article <[EMAIL PROTECTED]>,
thomas <[EMAIL PROTECTED]> wrote:
> Hello,
> I have a file of employees with their name, surname, date of birth and
> another data.
> I want to attribute an ID number to each employee.
> Can I use a hash function ?
> For some reasons, the personal data of my employees must not be found
> with the knowledge of the ID. This is the reason why I think about a
> hash function.
> MD5, SHA-1, RipeMD160, what is the best ?
> And what about if I only take 8 or 10 bits in the hash for the ID ? I
> suppose the efficiency of the hash would not be as stronger as if I
take
> the whole hash but what this will affect ? privacy only or collisions
> too ?
You can discard bits of your hash all you want, but if these ID's must
be kept secret [ as part of a login perhaps ] I would at least keep
them >40 bits. Numerically this is about 12 digits. This is not
because truncating the hash is insecure [although can lead to faster
colisions] it's because I could simply guess a number <1024 to get a ID
num.
You could always just assign them ID # linearly as they register.
There would be no collisions then and it's perfectly secure for your
needs. Of course you can then simply call people #5 and skip the title
thingy.... :)
tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: ENCRYPTOR 4.0 by Comotex USA Inc. CRACKED !!
Date: Sat, 13 Nov 1999 12:02:27 +0100
JPeschel wrote:
>
> fungus [EMAIL PROTECTED] writes:
> >Read the subject line "Encryptor 4.0 by Comotex.. .... cracked",
> >not "Algorithm XXX cracked"
>
> You read it. This guy hasn't cracked anything.
>
Your reasoning is....?
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED] (John Bailey)
Subject: Re: smartcard idea?
Date: Sat, 13 Nov 1999 12:50:13 GMT
On Fri, 12 Nov 1999 13:41:13 -0000, "Craig Inglis"
<[EMAIL PROTECTED]> wrote:
>I wonder what it would cost to design a credit card sized smartcard
>with a numeric keypad, a little LCD display, and a processor
>powerful enough to a 2048bit modular exponentiation?
You could rephrase the question, given the ubiquitiousness of cellular
phones.
wonder how much memory and program space would be required to add a
process to a cell phone process so that it could provide user
initiatied 2048bit modular exponentionation. Have the cell phone
manufacturers already provided enough space? If not, what would it
cost to add the space and software. Is it or some reasonable close
equivalent already provided, in the existing security suites of the
cell phone?
Excellent concept--let's do it!
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Ultimate Crypto Protection?
Date: Sat, 13 Nov 1999 12:00:13 +0100
Gary wrote:
>
> Tim Wood wrote in message <80gqkr$2g4$[EMAIL PROTECTED]>...
> >
> >Gary wrote in message <80fhd0$sve$[EMAIL PROTECTED]>...
>
> >A PRNG is not a OTP and never will be due to the P ;-)
>
> Sorry you're right, that should be a true random source.
> Still in the old days OTP was a page from a book and not a
> truly random source.
No, that would be a "book cipher".
In the old days, OTPs were often made by rolling dice.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Can the SETI@home client be protected?
Date: Sat, 13 Nov 1999 12:13:05 +0100
David A Molnar wrote:
>
> *How* do you convince people that the client is optimal and
> doesn't need improving?
>
You can't.
> Plus it still wouldn't address the more paranoid scenarios where
> people are intentionally trying to misreport data...
>
Authentication of packets can certainly be done using cryptographic
techniques. As soon as you start to worry about security,
authentication is probably a good idea.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: intelligent brute force?
Date: 13 Nov 1999 13:41:41 GMT
Brute forcing takes a long time. Even brute forcing with reduced character
sets takes a long time.
Has anyone written a paper or a chapter in a book describing methods of
brute forcing intelligently, before resorting to a full-scale search?
For instance,
1. First perform a dictionary attack
2. Use digram/trigrams in various combinations
3. try pre and postfixing numbers
4. etc etc
I know this is going to depend on the language used, but if you have some
knowledge of the passphrase involved, it could find it years and years
before a full-search.
And what knowledge of a passphrase would considerably help the intelligent
search? Passphrase length and characters involved come to mind, but what
else? Knowing that the passphrase is based on English words with
misspellings?
Keith
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: scott16u contest
Date: Sat, 13 Nov 1999 15:30:09 GMT
Well it has been over a year. Even though many think my code is snake oil
I did run a contest for a large ( for my income level) prise to see if any one
could see weaknesses in my program. Know one was able to sovle it.
Has any one of you out there in hachers ville make any progress at all.
It was virtually impossible to get the exact same solution that I got but
there were many thousands of solutions possible. But the solution denisty
was such you would have better luck guess an AES key to some encrypted
text with a known plaintext. This is not your usuallt weak short keyed crypto
that the phony crypto gods and there NSA friends want you to use.
MORE LATER
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
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
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: Coen Visser <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Sat, 13 Nov 1999 15:38:37 +0000
[EMAIL PROTECTED] wrote:
> Coen Visser <[EMAIL PROTECTED]> wrote:
> [...]
> > Keep in mind that compression is defined + O(1).
> Aye, there's the rub. The + O(1) means that we
> cannot meaningfully talk about whether an
> individual string is compressible in the
> Kolmogorov complexity sense (except with respect
> to a given representation language). The length
No, I don't believe that is the case. You can compress
any single string (or at most a finite number) as small
as you want, as you are saying below. However, if you
find a repeating pattern in a certain string that you can use
to compress it that string *will* be compressible in
the K-complexity sense irrespectible of the representation
language. You use the constant factor to abstract from
the specific representation language.
> For _any_ string, there is some language in which
> the string has a representation that is one
> character long. Tell me the string and I'll
> construct such a language.
I agree with you.
> The most basic cool theorem from Kolmogorov
> complexity states:
>
> For any two reasonably powerful languages L
> and L', there is some constant C, such that
> for all strings x, the shortest representation
> of x in L and the shortest representation of x
> in L' differ in length by at most C.
Yes, that is where to O(1) comes from. Fix a
Universal Turing Machine of size O(1) and it does
not matter which effective language you use.
> The order of quantification is critical. It's
> easy to mess it up and think the theorem
> contradicts the claim that for any string there's
> a language in which the string has complexity 1.
That is why I mentioned the additional constant
factor (O(1)). Though maybe my examples/explanations
were not thorough enough.
> The theorem tells us that if we ignore additive
> constants, we can talk about the compressibility
> of strings without concern for the representation
> language. But ignoring constants only makes
> sense when talking about infinite sets of strings.
You mean the infinite set of infinite strings? I only know of
Kolmogorov complexity in the context of infinite sets of
strings.
> For an individual string, what the theorem implies
> is completely vacuous: two constants differ by at
> most a constant.
Not exactly. You describe two different things in this
sentence:
1) compressibility of a single specific string and
2) the apparent comparison (two constants) of the shortest
length of two specific strings.
I agree that it is difficult (although not completely
meaningless) to talk about 2. But one could argue that
a specific string "0101010..." is compressible + O(1)
independently of the representation language.
> > So I allow for
> > some overhead of a Turing Machine definition. Now I can compress all
> > finite length strings of form "0101010101010101..." by preceding
> [...]
>
> Yes. There are infinitely many strings of this
> form, so it's meaningful to say their complexity
> is the log base 2 of their length plus or minus a
> constant. Saying the same of some particular
> string is nonsense: the length of the shortest
> representation of "01010101" is three plus or
> minus some constant.
That is completely true. The length of the sortest
representation of a strings can not be computed.
But you are taking my example out of its context.
I gave a counter-example on a claim that you can not
compress any string out of the pool of all finite-length
strings. I did not aim for shortest compression.
> In conclusion, there is no meaning in talking
> about whether a given string by itself is random,
Agreed that is non-computable.
> in either the sense of Shannon's entropy or
> Kolmogorov complexity. The entropy is defined
> only when given the probability distribution, and
I am a bit rusty on the subject but there is a
"universal distribution" which dominates any
probability distribution. Of course, to leave some
challenge for us humans, this "universal
distribution" is non-computable.
> the complexity of a given string is meaningful
> only when given the representation language. For
> infinite sets of string, Kolmogorov complexity
> can provide a notion of their compressibility
> independent of the representation language.
I agree completely here.
Regards,
Coen Visser
------------------------------
From: Coen Visser <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Sat, 13 Nov 1999 15:53:36 +0000
"Trevor Jackson, III" wrote:
> Coen Visser wrote:
> > Keep in mind that compression is defined + O(1)
> > [...]
> > I have just compressed infinitely many strings of a special form
> > "010101..." and left all other strings untouched (+O(1)).
> Hardly. You have added a prefix bit to every string. So you did touch "all other
>strings". Their
> representations are now larger, and the sum of their increase will outweigh the
>decrease in the
> strings you compressed.
I thought that the arbitrary large but constant factor O(1)
was understood. Furthermore I gave an example of just one type
of string containing a certain pattern. I hope you didn't expect me
to do this for all strings that contain compressible patterns. That
would bring the balance more in your direction. Especially when
using optimal compression (which is just a theoretical concept).
> > So, you're use statistical tests. It happened to be proved that a string
> > that passes all [*] statistical tests within the required confidence
> > level
> > is incompressible (and random because it passed the tests). So our
> > definitions
> > start to look dangerously equivalent.
>
> Not at all. You are assuming that a string that passes statistical tests is random.
> I am assuming
> that a string that fails statistical tests is non-random. We are worlds apart.
I disagree. We are just talking from other sides
of an otherwise fair coin. Passing or failing *all* statistical
tests is just a matter of how you define the tests.
Regards,
Coen Visser
------------------------------
Date: Sat, 13 Nov 1999 10:55:22 -0500
From: David Hamer <[EMAIL PROTECTED]>
Subject: Re: Enigma Machine: fair market value
On my web site - the page:
<http://www.eclipse.net/~dhamer/enigma_p.htm>
...carries a [circa] ten-year history of auction and private sale prices
for both Enigma and NEMA.
DHH
zenlight wrote:
> Does anyone know what the fair market value of
> an enigma machine is?
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
David Hamer The Crypto Simulations Group
[EMAIL PROTECTED] or [EMAIL PROTECTED]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: Need technique for about 24 bytes
Date: Sat, 13 Nov 1999 15:54:11 -0000
What is the destination platform?
IE What are the memory, bandwidth, error rate, and cpu (8,16,32 bit?)
limitations?
Is the string made up of completely random characters or does it have
redundancy which could squeeze the string into 15 8 bit bytes (each
character averaging 5 bits)?
These parameters effect what type of compression and cipher algorithms
should be used.
------------------------------
** 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
******************************
