Cryptography-Digest Digest #699, Volume #13 Fri, 16 Feb 01 20:13:01 EST
Contents:
DES-Question... ("Carsten Alexander")
Re: Reverse encoding question (Michael J. Fromberger)
srp-1.7.2 released (Thomas Wu)
Re: Steak Stream Cipher (Thomas Wu)
Re: /dev/random under Linux (Janusz A. Urbanowicz)
Re: Hardware RNG - Where can I order one? (Janusz A. Urbanowicz)
Re: National Security Nightmare? (Darren New)
Re: Steak Stream Cipher ("Henrick Hellstr�m")
Re: Hardware RNG - Where can I order one? (Paul Rubin)
Re: Super strong crypto (wtshaw)
Re: Steak Stream Cipher (those who know me have no need of my name)
Re: Big Numbers in C/C++ ("Dann Corbit")
Re: Steak Stream Cipher (Thomas Wu)
Re: Big Numbers in C/C++ ("Douglas A. Gwyn")
Re: File encryption with Rijndael ("Marcin Kurzawa")
Re: Super strong crypto (Steve Portly)
Re: National Security Nightmare? ("Douglas A. Gwyn")
Re: Super strong crypto ("Douglas A. Gwyn")
Re: Super strong crypto ("Douglas A. Gwyn")
Re: Hardware RNG - Where can I order one? ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: "Carsten Alexander" <[EMAIL PROTECTED]>
Subject: DES-Question...
Date: Fri, 16 Feb 2001 20:19:25 +0100
Hi there,
i'm quite new in cryptography, but i think i got the "big picture" of DES.
My problem: i have almost no idea of the scientific and numeric-theoretical
background, 'cause it's a hard one. But i'm working on this ;-)
My question:
First: assume we'd know the plaintext, didn't know the encryption key used,
and only 16 bits of the ciphertext. When we'd do a brute force attack we'd
get 2**(56-8) = 2**48 matching keys. Am i right so fare?
Second: assume we'd know a second, completely different plaintext , still
didn't know the identical encryption key used, and 16 bits of the different
ciphertext. When we'd do a brute force, we'd get an another subset of 2**48
matching keys. Let's take a look on the two subsets. Which amount of keys
would be the same? Every second key, or every eights one (because, we know
eight bits of both ciphertextes)
Thanks for your attention,
Carsten Alexander
------------------------------
From: Michael J. Fromberger <[EMAIL PROTECTED]>
Subject: Re: Reverse encoding question
Date: 16 Feb 2001 19:23:01 GMT
In <[EMAIL PROTECTED]> Paul Starzetz <[EMAIL PROTECTED]> writes:
>given a cipher C and encrypted text X, what plaintext shall I use to
>obtain X, _if_ the encryption key of the cipher C is known? I have
>to solve this problem for either blowfish or 3des. I don't ask for
>how to break des, notice that ;-)
>
>Small example:
>
>I have to produce 3des-cbc encrypted data having full controll over
>the used encryption key, but after encryption the output has to be
>e.g.:
>
>0xabdc0001 whatever .....
>DATA[0-3] DATA[4...]
>and I'm looking for the plaintext which would produce that. I only
>need the first 4 bytes to match.
>thx, hope somebody knows a solution for this.
Hello there,
In general, if E is a symmetric cipher with decryption rule D, if you
have C = Ek(X), and you know C and k, you can easily compute:
Y = Dk(X)
Encrypting Y with key k will result in X, i.e., Ek(Y) = X. This
should work for any symmetric cipher. Are you sure this is the
question you are looking for the answer to?
-M
--
Michael J. Fromberger Software Engineer, Thayer School of Engineering
sting <at> linguist.dartmouth.edu http://www.dartmouth.edu/~sting/
Nihil curo de ista tua stulta superstitione.
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Crossposted-To: comp.security.unix,comp.os.linux.security
Subject: srp-1.7.2 released
Date: 16 Feb 2001 11:50:46 -0800
Version 1.7.2 of the SRP distribution has been released. This is mostly
a bugfix release, with the following changes:
- Added 3DES Encryption support in Telnet (RFC2947/RFC2948)
- Portability fixes (especially for FreeBSD and SCO)
- Improvements to Telnet X11 connection forwarding and Kerberos support.
SRP Telnet is an Open Source implementation of the SRP authentication
standard in Telnet (RFC2944) along with a variety of other Telnet
features, such as TLS session security and X11 session forwarding.
SRP Telnet is a secure alternative to existing login protocols that
offers strong password security without additional user inconvenience.
SRP is a strong password-based authentication and key exchange protocol
that resists active and passive network attacks, including dictionary
attacks and MITM attacks, without depending on previously-exchanged
host keys. SRP is freely available worldwide and does not depend on
any encumbered technologies. The SRP name is also not trademarked
anywhere.
http://srp.stanford.edu/
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: Steak Stream Cipher
Date: 16 Feb 2001 11:54:49 -0800
"Henrick Hellstr�m" <[EMAIL PROTECTED]> writes:
> That's at least three or four questions in one. The Secure Remote Password
> protocol itself seems to be a nice solution that gives you a session key
> exchange and identity verification. Perhaps there are other protocols with
> the same or higher security level (but better performance), but I don't
> pretend that I myself have invented anything such.
For the same security level as SRP, I don't think there's anything
faster out there right now. Maybe in the future, but not at the moment.
> I presume that you by "SRP FTP" refer to some kind of C/C++ code library. To
> the best of my knowledge, there is no such library available in
> Delphi/Object Pascal code. I'd be delighted if you proved me wrong.
The SRP distribution is a full reference implementation of SRP password-
based authentication and key exchange in FTP. It's written in C and
highly portable to many Unices as well as Windows. Version 1.7.2 was
just released.
http://srp.stanford.edu/
Tom
> The 3DES/CAST/Blowfish algorithms are different block ciphers. Since I
> haven't finished documenting Steak and published all results, I am only
> justified to claim that Steak is another cipher, different from those three
> in several respects: Firstly, it is a stream cipher with a 8-bit block size
> (no padding to fill up end blocks is necessary). Secondly, the purpose of
> the design of Steak is that it will neither be necessary to wrap it in a
> mode of operation (PCFB-8/n mode is already part of the algorithm), nor to
> apply a MAC on top of it. Using Steak, you obtain a message authentication
> code simply by padding the plain text with a string of your choice and
> encrypting it as usual. Insofar Steak will not be proved to be substantially
> weaker in any way than any of the cipher/MAC combinations you suggested, I
> think that it is interesting simply because of it's different design.
>
> It is debatable whether or not such justification is sufficient or not.
> Let's just that I recognize my responsibility as the designer of Steak to
> document it properly and as far as possible prove that it has whatever level
> of security it has.
>
> --
> Henrick Hellstr�m
> StreamSec HB
>
> "Thomas Wu" <[EMAIL PROTECTED]> skrev i meddelandet
> news:[EMAIL PROTECTED]...
> > Don't want certificates? SRP FTP does strong password authentication
> > without certificates. It encrypts and integrity-protects session data
> > (both control and data channels) with your choice of 3DES/CAST/Blowfish
> > and MACs with your choice of MD5/SHA-1 using the exchanged SRP session
> > key. It resists active and passive network attacks, including brute-force
> > password attacks. Does your product solve something that isn't already
> > solved for free?
>
>
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: [EMAIL PROTECTED] (Janusz A. Urbanowicz)
Subject: Re: /dev/random under Linux
Date: 16 Feb 2001 20:11:27 +0100
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] (Matthew Kwan) writes:
> Any motherboard running the Intel 810 chipset and beyond has hardware
> random number generation (using thermal noise). You might want to
> rewrite the /dev/random kernel code to take advantage of this feature.
> Or hassle the current author to write it for you.
It is already supported in 2.2.18 and 2.4.0 Linux kernels.
Alex
--
======= Janusz A. Urbanowicz, Thawte WOT Notary, ALEX3=RIPE =========
There were cowboys ever since there were computers. They built the first
computers to crack German ice, right? Codebreakers. So there was ice before
computers, you wanna look it that way. -- William Gibson, 'Count Zero'.
------------------------------
From: [EMAIL PROTECTED] (Janusz A. Urbanowicz)
Subject: Re: Hardware RNG - Where can I order one?
Date: 16 Feb 2001 20:14:06 +0100
Reply-To: [EMAIL PROTECTED]
"The Death" <[EMAIL PROTECTED]> writes:
> Where can i buy a good hardware RNG that i can connect to my PC and use to
> generate secure random bits?
Get a motherboard that is Intel 810 or 815 based. It has one.
Alex
--
======= Janusz A. Urbanowicz, Thawte WOT Notary, ALEX3=RIPE =========
There were cowboys ever since there were computers. They built the first
computers to crack German ice, right? Codebreakers. So there was ice before
computers, you wanna look it that way. -- William Gibson, 'Count Zero'.
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: National Security Nightmare?
Date: Fri, 16 Feb 2001 20:38:05 GMT
Flame away! ;-)
http://www.washingtonpost.com/wp-dyn/articles/A36464-2001Feb7.html
Cancer-Risk Study Clears Cell Phones.
Mok-Kong Shen wrote:
> I am afraid that others would flame us for drifting far
> away from crypto.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
Ignorance can be cured. Naivety cures itself.
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Steak Stream Cipher
Date: Fri, 16 Feb 2001 22:21:32 +0100
Hm. It seems to me as if the srp distribution only includes a client.
What about server side srp? Do you have a secure ftp server as well, or is
the ftp server supposed to be placed behind a server side layer application
of some kind?
--
Henrick Hellstr�m
StreamSec HB
"Thomas Wu" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> The SRP distribution is a full reference implementation of SRP password-
> based authentication and key exchange in FTP. It's written in C and
> highly portable to many Unices as well as Windows. Version 1.7.2 was
> just released.
>
> http://srp.stanford.edu/
>
> Tom
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Hardware RNG - Where can I order one?
Date: 16 Feb 2001 13:30:04 -0800
[EMAIL PROTECTED] (Janusz A. Urbanowicz) writes:
> "The Death" <[EMAIL PROTECTED]> writes:
>
> > Where can i buy a good hardware RNG that i can connect to my PC and use to
> > generate secure random bits?
>
> Get a motherboard that is Intel 810 or 815 based. It has one.
Is there a simple way to tell if my mb supports this? It's a Thinkpad
a20p laptop, PIII processor. Thanks.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Super strong crypto
Date: Fri, 16 Feb 2001 16:13:00 -0600
In article <[EMAIL PROTECTED]>, Steve Portly
<[EMAIL PROTECTED]> wrote:
>
> Your system can only be as strong as the first key you use. An attacker
> with an infinite amount of time could try all combinations of starting
> keys until a coherent message appears.
The chaining based clearly on previous messages might be easier to attack
than if the key generation procedure is obscure.
> If your starting key is made up of
> more elements than the sum of characters in the entire message then you
> have a secure system since all possible messages might appear. Such a
> large key size would be unwieldy and would require padding each message to
> the agreed upon key size.
Keys could change based on sheer throughput, even within a message if a
threshold is reached.
--
Better to pardon hundreds of guilty people than execute one
that is innocent.
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: Steak Stream Cipher
Date: Fri, 16 Feb 2001 22:57:07 -0000
<94tc15$usg$[EMAIL PROTECTED]> divulged:
>In article <94t6g3$qai$[EMAIL PROTECTED]>,
> Bryan Olson <[EMAIL PROTECTED]> wrote:
>> For secure FTP, why would you not use TLS (updated SSL)?
>
>I think there is demand for secure server solutions for non-commersial
>use without the requirement of expensive ceritificates. But maybe you
>know something about the full potential of TLS that I don't?
mitm problems aside, generating a certificate does not require the use of a
commercial service.
--
okay, have a sig then
------------------------------
From: "Dann Corbit" <[EMAIL PROTECTED]>
Subject: Re: Big Numbers in C/C++
Date: Fri, 16 Feb 2001 15:07:23 -0800
"JCA" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Paul Schlyter wrote:
>
> > In article <[EMAIL PROTECTED]>,
> > David Sowinski <[EMAIL PROTECTED]> wrote:
> >
> > > I prefer GMP and believe that it is faster than MIRACL.
> >
> > Did you use just the C low-level routines in MIRACL when evaulating
> > the speed? MIRACL also has assembly language replacements for these
> > for the most popular processors,
>
> So does GMP.
MIRACL is a lot easier to use. The speed might be a push, but you also have a
ton of algorithms already implemented. Besides which, C++ classes are so much
easier to understand. MIRACL is a lot better (for me -- YMMV).
How does GMP compare to Freelip? Has anyone actually done benchmarks?
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
"The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. FAQ: ftp://cap.connx.com/pub/Chess%20Analysis%20Project%20FAQ.htm
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: Steak Stream Cipher
Date: 16 Feb 2001 15:28:36 -0800
"Henrick Hellstr�m" <[EMAIL PROTECTED]> writes:
> Hm. It seems to me as if the srp distribution only includes a client.
>
> What about server side srp? Do you have a secure ftp server as well, or is
> the ftp server supposed to be placed behind a server side layer application
> of some kind?
The SRP distribution contains both ftp (client) and ftpd (server).
Tom
> --
> Henrick Hellstr�m
> StreamSec HB
>
> "Thomas Wu" <[EMAIL PROTECTED]> skrev i meddelandet
> news:[EMAIL PROTECTED]...
> > The SRP distribution is a full reference implementation of SRP password-
> > based authentication and key exchange in FTP. It's written in C and
> > highly portable to many Unices as well as Windows. Version 1.7.2 was
> > just released.
> >
> > http://srp.stanford.edu/
> >
> > Tom
>
>
>
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Big Numbers in C/C++
Date: Fri, 16 Feb 2001 23:05:31 GMT
Paul Schlyter wrote:
> I also believe MIRACL is somewhat more accurate - why? Because it
> implements reals not as the usual floating-point numbers but as
> rational numbers: A/B where A and B both are integers. ...
> MIRACL includes a full set of transcendental functions
> (logs/trigs/etc) for MIRACL hi-precision real numbers.
Pray tell, how does MIRACL represent sin(1/2), log(5), etc.?
Those are not rational numbers.
------------------------------
From: "Marcin Kurzawa" <[EMAIL PROTECTED]>
Subject: Re: File encryption with Rijndael
Date: Fri, 16 Feb 2001 23:51:16 GMT
"Marcin" <[EMAIL PROTECTED]> wrote in message
news:2j5g6.72833$[EMAIL PROTECTED]...
> I have made available my tiny command line file encryption program based
on
> Rijndael with 256 bit keys. Its coded in Java and freely distributed with
> source code at: http://www.optymalni.com/~marcin
> Any comments please direct to [EMAIL PROTECTED]
>
> Marcin
For those of you that downloaded my simple file encryption tool:
One of you have reported a bug in hashing the passphrase, the problem is now
corrected and update (v1.1) is posted on the above noted web site.
Thanks,
Marcin
------------------------------
From: Steve Portly <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Fri, 16 Feb 2001 19:05:29 -0500
wtshaw wrote:
> In article <[EMAIL PROTECTED]>, Steve Portly
> <[EMAIL PROTECTED]> wrote:
> >
> > Your system can only be as strong as the first key you use. An attacker
> > with an infinite amount of time could try all combinations of starting
> > keys until a coherent message appears.
>
> The chaining based clearly on previous messages might be easier to attack
> than if the key generation procedure is obscure.
Without supplying a fresh start key for each message that is independent of the
prior start key it is conceivable.
>
>
> > If your starting key is made up of
> > more elements than the sum of characters in the entire message then you
> > have a secure system since all possible messages might appear. Such a
> > large key size would be unwieldy and would require padding each message to
> > the agreed upon key size.
>
> Keys could change based on sheer throughput, even within a message if a
> threshold is reached.
>
This is a broad topic. When I first saw the subject line I thought it might be
dealing with quantum cryptography ;-) A good chaining method gives you a wide
range of possible key strengths that increases linearly with key size.
Obviously for maximum strength, the closer a key is to being a onetime pad the
better. I am an individual and do not have access to all the data that the key
length recommendations are based upon. I believe the cryptographic system one
uses need not appreciably exceed the physical security of the system it is
installed on. In my case it would be easier to tap the keyboard then try to
break my cipher.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: National Security Nightmare?
Date: Fri, 16 Feb 2001 23:24:16 GMT
Mok-Kong Shen wrote:
> ... In order to maintain the status quo,
> a necessary condition, I believe, is that the common
> people don't start to massively employ encryption, for
> that would bog down all computing resources, unless
> an extremely huge budget is available.
Okay, now I get your point -- it's not that the content
of Everyman's traffic is important, it's that picking out
the intended targets' traffic might be harder. That is
to some extent true, but the important factor lies in the
routing protocols, not in message content. I think it
will remain true for the foreseeable future that general
Internet routing will expose enough information to make
end-node targeting feasible. For it to be otherwise, the
standards for routers etc. would have to require secure
encryption of all address-related information, which
would introduce a massive PK-management problem.
> ... should or should not attempt to mobilize the
> sensitivity of the public in matters of protection of
> their privacy.
The problem is, the ignorant public tends to get their
"information" via what we call "the media", which rarely
do a good job of explaining the important issues and
recommended actions. Witness the outbreak of yet another
Melissa-like Word (.vbs) virus. The public understandably
are never going to learn enough to make their own
rational decisions on such matters, so they rely on the
experts to take care of these things for them, but the
experts who should do that (e.g. Microsoft application
developers) find that they are rewarded for producing
flashy features much more than for producing improved
security. So I don't think that addressing the end user
is going to do much good. The problem lies in the middle
of the development chain, and that is where security
experts need to concentrate their influence.
> Money always plays a role in this world that started with
> sins. The fanatics have that and hence they can always get
> some number of people willing to work for them, even if
> 99.9999999......% of the population refuse.
I don't see a connection between money and sin, but as to
the fact that individuals vary and there will always be
*some* who are willing to work for the Bad Guys, that's
not a big problem so long as there aren't very many of
them who are good at the technology. Small numbers of
evildoers can be kept track of fairly well compared to
large numbers (such as we created with our War on Drugs).
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Fri, 16 Feb 2001 23:31:48 GMT
Nicol So wrote:
> Interesting idea, but I see some practical difficulties. If the cipher
> is inside some general-purpose communication mechanism that makes no
> assumption about the traffic, how does it know when to switch to a new
> key?
That would be specified e.g. in a header. In fact real cryptosystems
often have expiration criteria associated with their keys. What I
described was an attempt to avoid introducing a big key distribution
problem for such a system.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Fri, 16 Feb 2001 23:35:39 GMT
Steve Portly wrote:
> Your system can only be as strong as the first key you use. An attacker
> with an infinite amount of time could try all combinations of starting
> keys until a coherent message appears.
No, the specification ensured that there would be multiple
possibilities for coherent messages.
There *is* a theoretical weakness in that each key span
could be independently reduced to keys sorted in order of
likelihood (based on source statistics), which would
enable one to chain the likelihoods backwards to improve
the estimates for likelihoods in earlier blocks. If this
scheme were put into practice, one would have to change
the key quite a ways short of the unicity distance.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Hardware RNG - Where can I order one?
Date: Fri, 16 Feb 2001 23:39:08 GMT
Paul Rubin wrote:
> [EMAIL PROTECTED] (Janusz A. Urbanowicz) writes:
> > Get a motherboard that is Intel 810 or 815 based. It has one.
> Is there a simple way to tell if my mb supports this? It's a Thinkpad
> a20p laptop, PIII processor. Thanks.
If you're using Windows, look in the system devices section
of the device manager; several chipset identities should be
given there. Then you can look up the part numbers on the
Intel Web site.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
