Cryptography-Digest Digest #640, Volume #11 Wed, 26 Apr 00 19:13:01 EDT
Contents:
Re: papers on stream ciphers ("Joseph Ashwood")
Re: Is this a new protocol? ("Adam Durana")
Re: quantum computation FAQ? (Diet NSA)
Re: Can a password be to long? (Guy Macon)
Re: quantum computation FAQ? ("Leo Sgouros")
Career Opportunities @ Cloakware ("Marlies Vincken")
Re: Looking for a *simple* C Twofish source (Frog)
S-Tools4 stego source code [ security evaluation ] - where to get it ? (jungle)
ASCII encrypt and decrypt ("Dan")
Re: DES: Exhaustive Key Search (David Hopwood)
Hurry!!! (Possible Intellectual Property Infringement...) ("C. Prichard")
Re: Requested: update on aes contest (stanislav shalunov)
Re: Requested: update on aes contest (stanislav shalunov)
Re: Can a password be to long? ("Holger Wei�")
Re: base #- digit # ("Holger Wei�")
----------------------------------------------------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: papers on stream ciphers
Date: Wed, 26 Apr 2000 13:12:06 -0700
> First I must agree with Tom in that there is no inherent
weakness to
> XOR.
In spite of the very well known weaknesses?
>
> I believe it has been you (forgive me if I'm wrong), who
has stated that
> the requirements for a cryptographically strong bit stream
and randomness
> are different issues.
Actually my statement has always been that it must not only
be unpredictable to the point that given (-inf, n-1] bits
and [n+1, inf) bits, that the nth bit be impossible to
compute, but also that the bias be as close to zero as
possible (for a large finite stream no symbol should occur
with more than likelihood (+-1) than any other). I have also
always encouraged the use of something besides XOR to make
solving for the stream more difficult.
>
> The requirement for a cryptographically strong key is only
that it be
> unpredictable.
Wrong, it must be not only unpredictable, but unbiased as
well. A highly biased but unpredictable stream can have
consequences as large as having a correlated key
>
> Given this belief, knowing a "clean" stretch of
> key gives no information about the rest of the key.
> (Those stream ciphers that stretch keys, such as
> Lorenz machines, do reveal information as stretches of
> composite key are intercepted).
Actually it gives a significant amount of information about
the rest of the key. You have forgotten that finding a
function that given a clean stretch of key computes the next
bit is not always easier than solving for the original key
given the same stretch of bits.
>
> Of course randomness has the quality of unpredictablility.
> As do other bitstreams, such as those generated by
> transcendental numbers of the form suggested by Pierzyk
et.al.
Now for the real question, how much information on the
trancendental numbers is needed to compute the initial seed
or the next bit or the previous bit? once you have proven a
minimal value you have proven the minimal security
>
> One doesn't care that, perhaps, a truly random bitstream
cannot be
> created. Merely that it pass something that Maurer likes
to call the
> 'next bit test'.
Except that it fails to take into account the ability to
compute prior values in the stream in order to easily
compute the next values.
>
> Ultimately the man-in-the-middle can be resolved only when
a system
> can determine who the sender is and not what they know.
> It is left for those in Authentication and Protocols to
find solutions to
> this problem.
Actually the man-in-the-middle I proposed can be solved
quite easily using strong block encryption, or a stream
cipher that uses something besides XOR.
Joe
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Is this a new protocol?
Date: Wed, 26 Apr 2000 16:52:49 -0400
> > Say you didn't want to store the user passwords in plain text on the
server.
> > You could store hash values of the password. When the client gets the
> > random sequence of bytes, it first hashes the password with the agreed
apon
> > algorithm, then concats that hash value with the random bytes and hashes
it
> > again. Then sends that value to the server. The server would do the
same
> > thing in step 4 except it would concat the random bytes with the hash of
the
> > client's password it has stored.
>
> This modification doesn't help, because the password hash is then
password-
> equivalent. Use something like SRP-3, SNAPI, or B-SPEKE instead.
Actually it does help. Its not supposed to make the system any more secure
though. People tend to use the same password for many different things. So
storing the hash of a user's password would be wiser than just storing it in
plaintext. This way if the server was compromised and someone was able to
read the database with all the usernames and passwords, they wouldn't be
able to get your actual password, and use it to get into other places you
use the same password.
- Adam
------------------------------
Subject: Re: quantum computation FAQ?
From: Diet NSA <[EMAIL PROTECTED]>
Date: Wed, 26 Apr 2000 14:05:33 -0700
In article <lfvN4.9149$[EMAIL PROTECTED]>, "Leo
Sgouros" <[EMAIL PROTECTED]> wrote:
>
>http://arxiv.org/abs/gr-qc/9411073
>
>http://arxiv.org/abs/gr-qc/9411053
>
>
>Nice stuff!!!!
>
>
These articles are not on topic. What is it that you are trying
to say?
>
" V hfdt afogx nfvw ufo axb (o)(o) " - Gtnjv
====================================================
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Can a password be to long?
Date: 26 Apr 2000 17:06:38 EDT
In article <8e7ai0$2rj1$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Holger Wei�)
wrote:
>This is an advise how to remember long passwords given by many of
>the most popular European computer magazines (so this is no longer
>a secret):
>Choose some kind of text you can remember easily, such as a part
>of song lyrics or a quotation of a text. Then take a selection of
>the letters in this text, like every third letter or consonants
>only as your password.
>
>EXAMPLE:
>"The Lord of the Rings", page 456, first sentence:
>"And if we decide to part company, I can set you down outside my
>country at any point you choose."
>
>Every 5. char:
>fcocnnonicrnnce (or something like that; I seem to have forgotten
>how to count)
>provides a 15 char password
>
>Advantage: your password, no matter how long it is, stands any
>dictionary attack
>Disadvantage: a) in this example you have relatively few
>different characters
> b) this method does not provide any numbers or
>special characters and only few capital letters
>
I would modify this advice slightly by suggesting that the phrase *not*
be taken from a book or any other publisher source, but instead composed
by the password creator. Something like:
I went to the lake to see my mother, but it was gone.
Iwttltsmmbiwg
This stops someone who knows your reading habits from guessing
which passage you chose.
------------------------------
From: "Leo Sgouros" <[EMAIL PROTECTED]>
Subject: Re: quantum computation FAQ?
Date: Wed, 26 Apr 2000 21:11:18 GMT
"Diet NSA" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <lfvN4.9149$[EMAIL PROTECTED]>, "Leo
> Sgouros" <[EMAIL PROTECTED]> wrote:
> >
> >http://arxiv.org/abs/gr-qc/9411073
> >
> >http://arxiv.org/abs/gr-qc/9411053
> >
> >
> >Nice stuff!!!!
> >
> >
> These articles are not on topic. What is it that you are trying
> to say?
> >
>
>
> " V hfdt afogx nfvw ufo axb (o)(o) " - Gtnjv
> ----------------------------------------------------
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network
*
> The fastest and easiest way to search and participate in Usenet - Free!
>
>
I was admiring the link someone posted, and alluding to its utility for
various output of which the source is known, absolutely-known,
absolutely-unknown.
Lantings of a runatic.Or something.
Sorry.
<``>
------------------------------
From: "Marlies Vincken" <[EMAIL PROTECTED]>
Subject: Career Opportunities @ Cloakware
Date: Wed, 26 Apr 2000 21:25:56 GMT
Cloakware Corporation
Cloakware is a high-tech start up Ottawa's Silicon Valley North. The
company develops and markets security products and technologies for the fast
growing world of e-Commerce.
Cloakware was founded in December 1997. To date the company has developed
and patented its core Cloakware Technology and a beta version of its first
product, Bond. Bond provides a secure authentication and access control for
a web-centric environment. The first commercial version of Bond will be
available in the second quarter of 2000. Several other applications of the
product and technology are under development.
The company is growing rapidly with unbounded opportunity for career growth.
To continue this growth and take us to the next level, we are looking for
highly motivated and experienced individuals to add to our team. If you
would like your efforts to make a difference, talk to us. Competitive
salaries and benefits are standard along with stock options as an additional
benefit.
For more information on our company and the products we produce, please
visit www.cloakware.com.
WebMaster
Your role as WebMaster will be linked with many of the company's
departments. You will assist our customers with the integration of our
leading edge authentication and access control product into their sites.
You will be involved in the development and implementation of our customer
support infrastructure. Travel to customer sites may be required. You will
create a liaison with the marketing and sales departments to ensure that all
product communication and sales efforts are refined to meet the demands of
the customers. Finally you will be Cloakware's webmaster.
To fulfill the requirement of this position we require the following skills;
? Strong understanding of Web Servers. Particularly MS IIS and Apache on
UNIX.
? Detailed comprehension of UNIX and NT operating systems.
? Detail knowledge of security issues on the Web.
? Knowledge of load sharing, firewalls and routers.
? Good people skills with excellent communication abilities.
If you are interested and have the required skills, please send your resume
to [EMAIL PROTECTED]
Software Designer
In your position as Software Designer, you will be a core member of our Bond
design team. Your responsibilities will include the architecture, design
and implementation of our highly scalable distributed authentication and
access control system for e-commerce.
We require someone with a combination of the following skills:
? B.Sc. Degree (or equivalent) with product development experience.
? 2 to 4 years of Java programming skills.
? A good understanding of Servlet engines.
? Knowledge of http protocol.
? Excellent comprehension of UNIX and NT platforms and their associated Web
Servers.
? Some experience with web languages such as perl, xml, html.
If you are interested and have the required skills, please send your resume
to [EMAIL PROTECTED]
Compiler Designer
In your position as Compiler, you will work closely with our Technology team
of compiler experts and mathematicians to help implement components of
Cloakware's core technology. Our Cloakware technology converts software to
enable it to become tamper-resistant and in a "cloaked" form.
Job experience is a plus, but NOT required.
Required Skills:
? Good knowledge of storage structures such as balanced trees, hash tables,
heaps, dequeues, alternative representations for directed graphs.
? Implementation experience in an object-oriented language (C++, Java,
Eiffel, Modula-3, etc.).
Desirable Areas of Knowledge:
? Program transformations.
? SSA or other modern semantic representations used in optimizing compilers;
data flow and control flow representations.
? Compiler optimizing transforms.
? Numerical analysis as applied to computer arithmetic.
? Standard floating point representations and arithmetic (IEEE 754).
? Computational complexity theory (NP-hard problems, the complexity
hierarchy).
? Analysis of algorithms (finding expression e such that an algorithm is
O(e), and the like).
? Graph theory as applied to compilation.
? Elementary lattice theory as applicable to compilation, optimization, and
algorithmic inference of program properties.
? Discrete mathematics.
? Abstract algebra (groups, rings, and fields).
? Linear algebra.
If you are interested in this position and have the required skills and some
of the areas of knowledge, please send your resume [EMAIL PROTECTED]
Cloakware Application Engineer
In your position as Application Engineer, you will be a key member of our
Cloakware Technology team. You will work with sales and the core
development teams to design and apply our revolutionary, patent-pending
tamper-proof software technology to customer applications. Our leading edge
technology enables exciting new architectures and security solutions, and
unparalleled growth opportunities.
We require someone with the following skills:
? B.Sc. degree in Computer Science, Math or Software Engineering.
? 2 Years of Java programming experience.
? Good understanding of security protocols, cryptography and related
technologies.
? Good people, problem solving and communication skills.
? Ability to work in a team and under pressure.
If you are interested in this position and have the required skills, please
send your resume to [EMAIL PROTECTED]
------------------------------
From: Frog <[EMAIL PROTECTED]>
Date: 26 Apr 2000 21:46:22 -0000
Subject: Re: Looking for a *simple* C Twofish source
Despite all the talk about Twofish being "simple", anyone who has looked
at the code can see that it is anything but.
I suggest that you get someone to take a Twofish source and run it through
a C pre-processor to get the #defines out. Use one of the less optimized
options so that the code comes out more simple. Then pass it through
a C formatter ("beautifier") to get the result to look halfway readable.
They could turn most typedefs into #defines beforehand so that those
would go away too.
I'm not sure you'll get any that don't use pointers; those are a pretty
common technique in C.
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk,comp.security.pgp.discuss
Subject: S-Tools4 stego source code [ security evaluation ] - where to get it ?
Date: Wed, 26 Apr 2000 17:50:41 -0400
I would like to see the S-Tools4 stego source code [ security evaluation ]
any help in providing it would be appreciated ...
you can get it from
from ftp://idea.sec.dsi.unimi.it/pub/security/crypt/code/
s-tools4.zip
------------------------------
From: "Dan" <[EMAIL PROTECTED]>
Subject: ASCII encrypt and decrypt
Date: Wed, 26 Apr 2000 22:36:56 GMT
Anyone know how to use VB to write a code convert MS word to ASCII?
Example .... like
HAL if you encrypt by +1 using ASCII; it will become IBM.
Thank.
------------------------------
Date: Wed, 26 Apr 2000 23:37:31 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: DES: Exhaustive Key Search
=====BEGIN PGP SIGNED MESSAGE=====
eniGmah wrote:
>
> Question for the experts:
>
> Given a known 64 bit clear test and the corresponding high order 32
> bits of ciphertext where the low order 32 bits have been stripped off,
> what is the likelyhood of determining the 56 bit DES key via exhaustive
> key search or similar methods?
> a) What is the theoretical min/ max # of different 56 bit keys can
> produce the identical 32 high order bits of output for a given fixed
> input?
On average 2^24 keys will match [*]; over all possible plaintexts and
half-ciphertexts, the number of matches should approximately follow
a Poisson distribution with lambda = 2^24. This is because each key
has a 1 in 2^32 probability of giving the correct half-ciphertext,
and the trials for each key can be treated as being independent.
[*] Technically, the number of expected matches is 1 + (2^56 - 1)/2^32,
if one key is known to match a priori.
> b) Since there are 2^64 possible permutations of a 64 bit value,
> and only 2^56 different ciphertext values for a given input block
> enciphered under all possible 2^56 bit keys, does that imply that
> for a given input - only 1/128th of the 64 bit permutation space will
> be mapped out?
1/256th.
> Is it then possible that in scenario (a), that some of the 2^32 possible
> permutations (low order 32 bits) of potential output (concatenated with
> the known high order 32 bits of output for the given 64 bit input do
> not live in the DES key space, thereby reducing the amount of potential
> keys yielding the identical high order 32 bit ciphertext?
There are 2^32 possibilities for the low half of the ciphertext, and
2^56 keys, so with high probability we would expect all or almost all of
the possibilities to occur. That's beside the point, though; you only need
to consider the probability that each key will result in a match for
the part of the ciphertext that is known.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOQdvlTkCAxeYt5gVAQEenwf+I7iSEyp2xOOtnigWSz7SU0KwEPneAl1W
bdGQABaMovuxIWAOVyA0E9NuXqTvlCyFAzRLp/3xTIwqWQhqtgqlwC5F75hSEZIf
aPYmOoz0QUcL3oeHC2ZXfyJoqZFQ3GHm4WpgTYGfTZalX850pK2Zes+v/fr+2kL+
LdBfCSvwlmdtoTGCLnaSVhxGixUTRh0wdDx49TIJUo7YGnRnANLPj1xwZfmFrqNo
mxgnRhfUolVCvH3rSzctzLomP7n7vlq7EhFwgBUd8/46BzXNb2rr/A3L8u1D9/m6
wSgHZoJKGEPx8RzMQ9m0BRGvj5imQMWH6nsEXvTZYrKN1OM+lCjF5w==
=wBOW
=====END PGP SIGNATURE=====
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: Hurry!!! (Possible Intellectual Property Infringement...)
Date: Wed, 26 Apr 2000 22:39:11 GMT
Since this post is soon removed for its content anyway...
Why not just put another good trade secret and innovation in the clear?
New innovation uses CipherText to encrypt page tags in PERL wrapped site =
:
Demontrating CipherText as the security provider in a method that uses =
page tag encryption may be the niche application I have been looking =
for...
This is new information about a security method that I have developed =
using CipherText. It does not require cookies!!! In a noframes setting =
user impersonation can be limited to a single occurence for any given =
user. Policy would dictate the consequences of getting caught. (Its =
possible to track keys from frames as well, refreshing the keys each =
time a frame gets new content.)
The simple Perl wrapped demonstration at:
UNIX demonstration:
http://www.greentv.com/cgi-bin/cgiwrap/greentv/CRI/_nttc.cgi?page=3Dopene=
r&user_id=3D&env=3Dx
NT demonstration:
http://cri-bsu.org/chuck/cgi-bin/CRI/_nttc.pl?page=3Dopener&user_id=3D&en=
v=3Dx
Now uses CipherText II to encrypt the tag keys with DIFFERENT keys for =
each user session. This means that all users have different encrypted =
links as part of their persistent data for the application. Try it and =
you will see that the tags are encrypted differently each time you =
refresh the above link to a frameset.
This eliminates the possibility that encrypted links can be exchanged =
via email to unlock protected pages and it prevents users from reusing =
the encrypted keys in successive sessions.
When using framesets it is only possible to refresh links when the =
entire frameset is refreshed. However, IF THERE ARE NO FRAMES, the =
encryption key can be changed with EACH user response.
Using CipherText II there are no problems encrypting page tags and =
transmitting them in the default internet protocol.
With a simple password to protect a page, there is virtually no way to =
navigate to the protected page by entering the encrypted link for a =
given session.
This another example of encryption in the default HTTP protocol where =
CipherText is doing something that other algorithms cannot.
-Charles Prichard
------------------------------
Subject: Re: Requested: update on aes contest
From: stanislav shalunov <[EMAIL PROTECTED]>
Date: Wed, 26 Apr 2000 22:55:31 GMT
Jerry Coffin <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] says...
>> Whereas if you have several ciphers, the probability of one of them
>> being broken at one point increases.
> If you want to claim this, you need to support it. Right now, it's
> simply another piece of gas-doused cloth covering your straw man.
I don't see what we can discuss further in this thread if you don't
agree with the statement "It's more probable that Twofish or RC6 or
Serpent will be broken at some point than that Serpent will be broken
at some point." (Choice of ciphers in this example is arbitrary.)
The only situation where this wouldn't be true is when we have
absolutely no doubts that neither of them can possibly be ever broken.
--
stanislav shalunov | Speaking only for myself.
------------------------------
Subject: Re: Requested: update on aes contest
From: stanislav shalunov <[EMAIL PROTECTED]>
Date: Wed, 26 Apr 2000 23:07:32 GMT
[EMAIL PROTECTED] (wtshaw) writes:
> [...] Of course, if you push your position, like MS, asserting that you
> decide for all others, you deserve wrath against you for your
> wrongdoing.
>
> People who cry, "Stop the world, no more changes," are the ones who
> should leave. [...]
Um, right. Microsoft and I are supporting a freeze of standards.
Never noticed Microsoft doing that (would be very nice if they did).
Never advocated freezing standards myself.
I'm flattered by the comparison of your humble servant with a powerful
corporation, thank you. Too bad I don't even have a Microsoft OS
anywhere at work or at home.
--
stanislav shalunov | Speaking only for myself.
------------------------------
From: "Holger Wei�" <[EMAIL PROTECTED]>
Subject: Re: Can a password be to long?
Date: Thu, 27 Apr 2000 00:52:12 +0200
Guy Macon wrote in <8e7lou$[EMAIL PROTECTED]>...
]
]I would modify this advice slightly by suggesting that the phrase
*not*
]be taken from a book or any other publisher source, but instead
composed
]by the password creator. Something like:
]
]I went to the lake to see my mother, but it was gone.
]
]Iwttltsmmbiwg
Of course it was *not* my intention to say that quoting a book,
song, movie or whatever is *save*. I just did not want to post
something *I* would propably use as a password.
However, I'm quite sure that many people have difficulties of
thinking off a sentence that provides a *really* secure password.
Your sentence for example has a relatively simple structure and
therefore the initial letters are easy to guess. So, though my
example provided a rather poor password, your password is not that
much better.
By the way: trying *all* combinations of *all* sentences in *all*
bokks I've ever read is more work than an brute force attack.
"I may never prove what I know to be true" (Dream Theater, The
Spirit carries on), but I'm rather sure.
Holger
------------------------------
From: "Holger Wei�" <[EMAIL PROTECTED]>
Subject: Re: base #- digit #
Date: Thu, 27 Apr 2000 01:03:57 +0200
[EMAIL PROTECTED] wrote in <8e7eo7$mjo$[EMAIL PROTECTED]>...
|
|What is the relation between digit # & # of bases ?
|
I'm not sure if I understood your question, but I think wha you
want to know is:
N2 = ln (B1) / ln (B2) * N1
where
B1, B2 : bases of N1, N2
B1^N1 = B2^N2
This means:
A (binary) key of 2048 bits is equivalent to a decimal key with
ln (2) / ln (10) * 2048
digits.
Holger
------------------------------
** 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
******************************
