Cryptography-Digest Digest #253, Volume #11 Sat, 4 Mar 00 18:13:01 EST
Contents:
Re: Largest known prime (Tim Tyler)
Re: NIST, AES at RSA conference (Tim Tyler)
Re: NIST, AES at RSA conference (Tim Tyler)
Re: Cellular automata based public key cryptography (Mok-Kong Shen)
Re: Random bit generators (Tim Tyler)
Re: 'Free' services with tokens/puzzles (Mok-Kong Shen)
Re: Decompiling/Tamper Resistent (Andru Luvisi)
Re: Cellular automata based public key cryptography (Tim Tyler)
Re: Random bit generators (Guy Macon)
Storing phone numbers safely for later comparison - somewhat newbie ("Lance")
Re: 'Free' services with tokens/puzzles ([EMAIL PROTECTED])
Re: Random bit generators ([EMAIL PROTECTED])
Re: Decompiling/Tamper Resistent ([EMAIL PROTECTED])
Re: very tiny algorithm - any better than XOR? (Carl Byington)
Re: VB source code for DES algorthim ("Markus Hahn")
Re: Passwords secure against dictionary attacks? (Dave Howe)
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Largest known prime
Reply-To: [EMAIL PROTECTED]
Date: Sat, 4 Mar 2000 17:05:26 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Mok-Kong Shen wrote:
:> ... I read a claim that such huge primes
:> could be of utility in cryptology.
: That's based on a misunderstanding.
: *Arbitrarily chosen* large primes would be useful
: for schemes such as RSA, but *specially chosen*
: primes are of no particular value.
I believe there are other possible applications:
Primes can be useful in constructing systems with demonstrably large
periods.
A system with observed repetition with a prime langth p has demonstrably
no shorter periods - and combining systems with prime periods gives a
system with a period which is certain to be equal to the product of the
periods of its components.
The "Mersenne Twister" random number generator uses Mersenne primes.
http://www.math.keio.ac.jp/~matumoto/emt.html
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
A company is known by the people it keeps.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Reply-To: [EMAIL PROTECTED]
Date: Sat, 4 Mar 2000 17:13:41 GMT
John Savard <[EMAIL PROTECTED]> wrote:
: Tim Tyler <[EMAIL PROTECTED]> wrote, in part:
:>http://www.crypto.ch/english/company_folder/crypto_com_cryptoie.html
: produced only general comments about the company. [...]
I was foiled by their site's frames ;-(
>From that page, click on "Competence", and then on "Security" on the left.
The URL of the frame in question appears to be:
http://www.crypto.ch/english/company_folder/c_content_html/security_architect.html
...but typing this in directly apparently fails due to a redirection
mechanism.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Slit your wrists; lower your blood pressure.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Reply-To: [EMAIL PROTECTED]
Date: Sat, 4 Mar 2000 17:16:44 GMT
John Savard <[EMAIL PROTECTED]> wrote:
: Tim Tyler <[EMAIL PROTECTED]> wrote, in part:
:>``An important element in the security architecture of Crypto AG is the
:> customer�s independence from the manufacturer�s design. It is based on
:> manipulation-proof security chips and individual ASICs with proprietary
:> mathematical algorithms. Because of this design, the user - and only the
:> user - controls the vital parts of the modern algorithms and
:> consequently gains effective autonomy. This provides the same level of
:> independence as leading industrial nations which use proprietary
:> algorithms geared to their defence or government requirements.''
: Well, allowing the user to alter the algorithm, within limits, is a
: good idea.
It seems closely related to giving the system a larger key.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
What a depressingly stupid machine.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Cellular automata based public key cryptography
Date: Sat, 04 Mar 2000 18:30:59 +0100
Tim Tyler wrote:
>
> I've recently developed an interest in public key cryptography based on
> cellular automata.
A presumably very dumb question: A cellular automaton is a specialized
finite state automaton, isn't it? So wouldn't a (general) finite
state automaton be more versatile and hence have the potential
of being more complex than a cellular automaton?
M. K. Shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random bit generators
Reply-To: [EMAIL PROTECTED]
Date: Sat, 4 Mar 2000 17:29:34 GMT
Guy Macon <[EMAIL PROTECTED]> wrote:
: In article <uipGWubh$GA.265@cpmsnbbsa02>, [EMAIL PROTECTED] (Joseph Ashwood)
:wrote:
:>Take the output of three prngs and use the 3rd one to choose
:>from the other 2.
: I am unsure how this is better than XORing the outputs of all 3 PRNGs.
It /would/ be better /if/ the PRNGs in question were LFSRs. Combining
any number of LFSRs using XOR produces a system with known attacks on it.
The "shrinking generator", OTOH combines the streams using a non-linear
operation, which is likely to improve security.
There's still at least one (relatively feeble?) known attack on the
"shrinking generator", when its components are LFSRs. This is covered
in BS's AC, IIRC.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Meditation is not what you think.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: 'Free' services with tokens/puzzles
Date: Sat, 04 Mar 2000 18:54:39 +0100
[EMAIL PROTECTED] wrote:
>
>
> Simply have your server frequently request some value (e.g. the current value
> of EAX or some other CPU register which in some way might be anticipated by
> your server) that is not likely to be produced unless your client execute
> your module or your client have spent an irrationally large amount of
> resources on analyzing your module.
It seems that the information you want to get could be of different
kinds, namely the module has run a certain number of times in
a fixed time period or the module has continuously run in that
time period and whether a number of copies of the module run
parallelly. Anyway, I am afraid it could be quite difficult to
assure getting 'verifiable' information in any such cases, if one
considers the fact that the system clock can be arbitrarily set.
M. K. Shen
------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Re: Decompiling/Tamper Resistent
Date: 04 Mar 2000 09:35:36 -0800
[EMAIL PROTECTED] writes:
> I am refering to your post and the above poster. It appears that you
> dont have a clue of real crypto systems. Have you heard of FIPS-140
> levels 1-4. Most crypto manufacturers have a
> tamper-resistent/tamper-proof module (for keys and programs). This is
> not to stop customers having access to the source code...customers dont
> go snooping around bits of hardware and disassembling code.. There is
> an easier way of getting the source code.. You just ask...Isnt that
> simple..
Your original post refered to protecting your intellectual property
from "decompiling freaks". Decompiling is a way to get the source
code, hence it sure *seems* like you wanted a way to keep the workings
of your system secret. Are you now claiming that you only want a way
to keep keys secret?
> And I would aprreciate that you dont answer threads about a subject you
> know little about...
It's hard to know anything about you when you keep changing your story.
Andru
--
==========================================================================
| Andru Luvisi | http://libweb.sonoma.edu/ |
| Programmer/Analyst | Library Resources Online |
| Ruben Salazar Library |-----------------------------------------|
| Sonoma State University | http://www.belleprovence.com/ |
| [EMAIL PROTECTED] | Textile imports from Provence, France |
==========================================================================
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Cellular automata based public key cryptography
Reply-To: [EMAIL PROTECTED]
Date: Sat, 4 Mar 2000 18:05:24 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
[PK system using CAs]
: A presumably very dumb question: A cellular automaton is a specialized
: finite state automaton, isn't it? So wouldn't a (general) finite
: state automaton be more versatile and hence have the potential
: of being more complex than a cellular automaton?
Both FSM and cellular automata are capable of simulating Turing universal
systems - anything one can do, so can the other.
On positive feature of CAs is that they make a positive attempt to reflect
the "locality" requirement imposed by physics. Signals take a finite
quantity of time to travel around. To run a synchronous system rapdily,
do want to mimimise the maximum distance between components. In a
physical implementation of a 2D CA, on a 2D piece of silicon, all the
components are the same distance away from one another, and can be updated
synchronously at a high speed.
Anyway, I can simulate any FSM in a CA - and as you note - CAs are
themselves FSMs. The systems don't seem so very different in terms
of the complexity of the things they can represent.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Calm down - it's only ones and zeros.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Random bit generators
Date: 04 Mar 2000 13:34:36 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim Tyler) wrote:
>
>Guy Macon <[EMAIL PROTECTED]> wrote:
>: In article <uipGWubh$GA.265@cpmsnbbsa02>, [EMAIL PROTECTED] (Joseph Ashwood)
>wrote:
>
>:>Take the output of three prngs and use the 3rd one to choose
>:>from the other 2.
>
>: I am unsure how this is better than XORing the outputs of all 3 PRNGs.
>
>It /would/ be better /if/ the PRNGs in question were LFSRs. Combining
>any number of LFSRs using XOR produces a system with known attacks on it.
>
>The "shrinking generator", OTOH combines the streams using a non-linear
>operation, which is likely to improve security.
Ah. Of course. I was assuming that anyone who tried this would use
PRNGs with completely different algorithms. Doing otherwise scares me.
Another interesting question with the "chooser" method (one RNG
choosing from the output of two other RNGs) is whether to get a
bit from both, choose one, then discard the other or whether to
choose a RNG then get the next available bit from the chosen RNG.
------------------------------
From: "Lance" <[EMAIL PROTECTED]>
Subject: Storing phone numbers safely for later comparison - somewhat newbie
Date: Sat, 4 Mar 2000 10:43:57 -0800
This is a somewhat newbie question, but I'm working on a software
application
and want to "do the right thing". Only I'm looking for some
pointers/suggestions.
Specifically, I'm working on an application and for fraud control
reasons I need to maintain a database of abusive social security numbers. I
don't need to search these
in the future (in plaintext anyway) - only know wether to reject a "service"
based on some metrics.
For security/privacy reasons I don't want to store them in plaintext, but it
would seem
that hashing them wouldn't be terribly secure given the rather short amount
of time it
could take to precompute all the combinations of SSNs.
Obviously I could lengthen the cleartext by pre/appending constants, but
that has
it's own caeveats.
What are my other options? Keep in mind that I do need the hashing to be
relatively
quick ( < 0.5 seconds per compare including SQL query time )
I'm sure there are a few solutions that will work, so any help is
appreciated.
TIA,
Lance
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 'Free' services with tokens/puzzles
Date: 4 Mar 2000 18:45:01 GMT
In a previous article, Mok-Kong Shen <[EMAIL PROTECTED]> writes:
>[EMAIL PROTECTED] wrote:
>> Simply have your server frequently request some value (e.g. the current
value
>> of EAX or some other CPU register which in some way might be anticipated
by
>> your server)
---snip---
>I am afraid it could be quite difficult to
>assure getting 'verifiable' information in any such cases, if one
>considers the fact that the system clock can be arbitrarily set.
I does not have to be diffult. It is just a matter of synchronizing threads.
The server should of course ask for the contents of the register at a
specific stage of execution, not at a specific time.
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: Random bit generators
Date: Sat, 04 Mar 2000 12:08:31 -0800
My original formula
C[i] = (R1[i] & R3[i]) || (R2[i] & ~R3[i])
had a typo. What I meant is this:
C[i] = (R1[i] & R3[i]) | (R2[i] & ~R3[i])
I do not think I am XORing anything. I am pseudorandomly selecting bits from one or the
other.
Guy Macon wrote:
> In article <uipGWubh$GA.265@cpmsnbbsa02>, [EMAIL PROTECTED] (Joseph Ashwood)
>wrote:
>
> >Take the output of three prngs and use the 3rd one to choose
> >from the other 2.
>
> ..thus creating a single PRNG that is more complex. Not a bad idea if
> having a more complex PRNG is your goal. I am unsure how this is better
> than XORing the outputs of all 3 PRNGs.
>
> Keep in mind that there may be a corralation between the outputs of your
> initial 3 PNRGs that you don't know about that makes the output a lot less
> random than you think it is.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Decompiling/Tamper Resistent
Date: Sat, 04 Mar 2000 20:33:42 GMT
In article <[EMAIL PROTECTED]>,
Andru Luvisi <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
> > I am refering to your post and the above poster. It appears that
you
> > dont have a clue of real crypto systems. Have you heard of FIPS-140
> > levels 1-4. Most crypto manufacturers have a
> > tamper-resistent/tamper-proof module (for keys and programs). This
is
> > not to stop customers having access to the source code...customers
dont
> > go snooping around bits of hardware and disassembling code.. There
is
> > an easier way of getting the source code.. You just ask...Isnt that
> > simple..
>
> Your original post refered to protecting your intellectual property
> from "decompiling freaks". Decompiling is a way to get the source
> code, hence it sure *seems* like you wanted a way to keep the workings
> of your system secret. Are you now claiming that you only want a way
> to keep keys secret?
No..I have explained that in detail. But I will explain it again for
you. The issue is not keeping the internals of the system secret from
customers or potential customers. Any customer who is serious about our
systems can view the source code and the algorithnms....
What we want to do is keep our stuff out of the hands of copycats...and
I think this is something that is perfectly ligit....As I said
before..no customer is going to go to the length of decompiling
code..they just need to ask for it...and any credible crypto person is
also welcome to review our code...its all open...I hope I made this
clear...
Please visit NCipher....and other hardware crypto vendors...not only do
they keep their keys in tamper resistant boxes...but also their
softwrare...
Samuel Paik in his post got it right....some chip makers offer tamper
resistent EEPROMS and System on a chip precisely for this reason...
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Carl Byington)
Subject: Re: very tiny algorithm - any better than XOR?
Date: 4 Mar 2000 22:05:08 GMT
=====BEGIN PGP SIGNED MESSAGE=====
In article <89qkjq$grc$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>Maybe you could put the crypto algorithm into interpreted space, e.g.
>Skipjack, which needs only about 3 bytes of RAM (plus the data block)
>if you're careful. I don't think you could code it in 50 bytes, but
>there's a sample PIC implementation at
> http://www.brouhaha.com/~eric/crypto/#skipjack
>which you might be able to adapt.
Thanks for the reference.
>>Does the following give better security than a simple additive RNG?
>>[home cooked scheme snipped]
>
>I don't know. That scheme would look better if it had a lot more rounds.
>Why do you use bit rotations instead of a table lookup from the eeprom
>into some type of S box?
Number of rounds was based on the performance target, but that is a much
softer target than the code space requirement. Do you have any
suggestions for a specific number of rounds that would make this
reasonably secure? Bit rotations rather than table lookup from eeprom
since it takes fewer instructions, but I will revisit that issue. We
may have some interface to do that sort of fetch with a small calling
sequence. If that is possible, so we have SBOX[] as a 256 byte array,
what do you suggest for a replacement for my current
v[i] = v[i+1] ^ ((rotate_left(t) + k[r*4+j]) & 0xff);
Something like:
v[i] = v[i+1] ^ SBOX[((rotate_left(t) + k[r*4+j]) & 0xff)];
or:
v[i] = v[i+1] ^ (SBOX[t] + k[r*4+j]) & 0xff;
>Maybe you could use two additive RNG's of differing lengths and
>combine the outputs with the plaintext in some simple nonlinear way to
>get a keystream. That probably wouldn't stand up to serious
>cryptanalysis, but it would be compact and fast, and attackers at
>least would have to think about the problem.
I need to do some more reading on stream ciphers. It seems to me that
we use the key to setup the initial state of the keystream generator.
That generator then produces a bit stream that we xor with the data
to form the cipher text. Of course, we should not use the same key with
multiple texts in this scheme, which is where I get confused. How do
we solve the problem of needing a different key for each message?
In this product, we will have potentially many plaintexts that must be
encrypted with the same key. Some are (small and random) and others are
(large with much redundancy).
- --
PGP key available from the key servers.
Key fingerprint 95 F4 D3 94 66 BA 92 4E 06 1E 95 F8 74 A8 2F A0
=====BEGIN PGP SIGNATURE=====
Version: 4.5
iQCVAgUBOMGId9ZjPoeWO7BhAQGNjgQAuLQ9BtOGEzGWCAjEEC58UDVWOOvc0mS7
u5HoE2apaiuRTH3hoR0hFjGTY1eaeEx3XGkgWULdSrKa3olMj81N7Madm6xT/3wl
l51KO5bDNTfSGt/NtOzRkwSfhHQMtjJY2zq4Cw1tu4m4lxz/E+J0I2BtBrJru24i
dKjsjJfkUdY=
=g7Hx
=====END PGP SIGNATURE=====
------------------------------
From: "Markus Hahn" <[EMAIL PROTECTED]>
Subject: Re: VB source code for DES algorthim
Date: Sat, 4 Mar 2000 23:18:50 +0100
If you don't get a solution in VB you may try to use triple-DES
of CryptPak via the VB interface.
http://home.knuut.de/mchahn/software.html#cryptpak
Markus
<[EMAIL PROTECTED]> schrieb im Newsbeitrag news:89jg6j$qr1$[EMAIL PROTECTED]...
> I'm looking for a VB implementation of DES.
> It's for assignment purposes so speed of operation is not relevant. Also
> my C is very poor hence desire for VB.
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Dave Howe <DHowe@hawkswing>
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: Passwords secure against dictionary attacks?
Date: Sat, 04 Mar 2000 22:37:40 +0000
Reply-To: DHowe@get_email_from_sig
In our last episode (<alt.security.pgp>[Thu, 2 Mar 2000 13:43:08
-0000]), "Joseph Ashwood" <[EMAIL PROTECTED]> said :
>I think your estimate of 16 bits of entropy per word isn't
>quite right. Most Americans have a vocabulary of around 5000
>words, the same applies for many other countries. That means
>that, at best, we can have a reasonable expectation of 8192
>words in their vocabulary, or 13 bits. More likely 4096
>words for 12 bits.
That is of course true - but assumes you have access to the exact
dictionary used by that person (ie, a file containing their
vocabulary). unless you know them VERY well, you are more likely to go
for a common school-style dictionary, with a Personal name and
Placenames list appended - I can imagine this reaching 2^16 entries
without too much trouble.
>Now, of those words we tend to use only a
>few hundred in daily conversation (e.g. obfuscation isn't
>used daily), and therefore it is likely that there will be
>an extreme bias towards those words for only 8 bits of
>entropy per words.
In conversation, yes - but you are more likely to TRY and come up with
something obscure for a passphrase; it's more memorable if nothing
else.
>I guess my point is that you need to identify what your
>adversary is capable of. Will she/he have access to the room
>you type your password in? Will she/he have enough compute
>power to brute force 64 bits of key? Etc.
Not really - if they have any sort of access to the room at all,
particularly to the machine in your absence, you might as well give up
anyhow - a keyboard logger is trivial in software, and not really that
difficult in hardware....
------------------------------
** 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
******************************
