Cryptography-Digest Digest #707, Volume #10 Thu, 9 Dec 99 00:13:02 EST
Contents:
Re: NSA should do a cryptoanalysis of AES (Tim Tyler)
Re: Synchronised random number generation for one-time pads (Tim Tyler)
Re: Synchronised random number generation for one-time pads (Tim Tyler)
Re: NSA future role? (CLSV)
Re: AES Randomness Testing (Tim Tyler)
Re: MMPC - A multi-message encryption algorithm (Jim Shapiro)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (Greg)
weak algorithm, too hard for me (Gaccm)
Re: NSA future role? (SCOTT19U.ZIP_GUY)
Re: NSA future role? (Steve K)
SRP - a secure alternative for authentication >> Nice reading ...
([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Reply-To: [EMAIL PROTECTED]
Date: Thu, 9 Dec 1999 00:28:29 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
[DES]
:> Really?
: Yes.
I feel you need some quotation treatment ;-)
In discussing the strength of DES, Bruce Schneier wrote in "Applied
Cryptography":
``A brute force DES-cracking machine that can find a key in an average of
3.5 hours cost only $1 Million in 1993. DES is so widespread that it is
naive to pretend that the NSA and its counterparts haven't built such a
machine.''
...and...
``Winn Schwartau writes that the NSA had built a massively parallel
DES-cracking machine as early as the mid-1980s. At least one such
machine was built [...] Supposedly there are a series of algorithms
that can reduce the complexity of a DES brute-force search by several
orders of magnitude. Contextual algorithms, based on the inner workings
of DES, can scrap sets of possible keys based on partial solutions.
Statistical algorithms reduce this effective key size still further.
And other algorithms choose likely keys - words, printable ASCII, and so
on [...] - to test.
The rumour is that the NSA can crack DES in 3 to 15 minutes, depending
on how much preprocessing they can do. And these machines cost only
$50,000 each, in quantity.''
As for expected lifespan:
DES was adopted as a federal standatd in 1976. It became an ANSI standard
in 1981.
The terms of the DES standard stipulate it be reviewed every five years.
It was renewed in the 1983 review. It was renewed again in 1987 - and
*again* in 1992.
DES did not outlive its expected life - from the perspective of the
1992 review, anyway. It was almost certainly cracked, probably easily
and en-masse while it was still in service as an officially endorsed
US government standard.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
It's been lovely, but I have to scream now.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Synchronised random number generation for one-time pads
Reply-To: [EMAIL PROTECTED]
Date: Thu, 9 Dec 1999 00:37:53 GMT
amadeus wrote:
: OTP is totally secure given it is properly used. The problems are key
: distribution and key cancellation/deletion. [...]
Then there's the issue that a known-plaintext attack reveals the key - and
possibly allows inauthentic messages to be passed off as the real one.
Authenticity is a problem for OTPs.
With your typical block cypher, knowing the plaintext does *not*
instantly reveal the message key, and allow forged message(s) to be sent.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Love is chemistry; sex is physics.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Synchronised random number generation for one-time pads
Reply-To: [EMAIL PROTECTED]
Date: Thu, 9 Dec 1999 00:42:30 GMT
Scott Nelson <[EMAIL PROTECTED]> wrote:
: It's quite conceivable that OTP technology
: of the near future could be used to send _video_ messages.
No doubt it *could* be done today. However - for most applications - I'm
sure that there must be better ways of doing things than this.
OTPs face the key-distribution problem more strongly than any other type
of cypher.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
It's not enough to succeed - others must fail.
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: NSA future role?
Date: Thu, 09 Dec 1999 01:19:45 +0000
albert wrote:
>>> If you walk into the library of the University of Michigan, you can actually find
>>> all you need to know as far as how to make a nuclear bomb.
CLSV wrote:
>> One of those myths started by popular science magazines.
JCA wrote:
> Actually, it is true. However, you are right in that popular science magazines
> have been responsible for misleading one into thinking that just about anyone could
>in
> fact build a nuclear bomb.
To yank this thread more towards the charter of sci.crypt
(I don't receive alt.politics.org.nsa so I will refrain
from crossposting there) what about the following proposition:
If you walk into a decent university library you can find all
you need to build a good encryption algorithm.
True or false?
Regards,
Coen Visser
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: AES Randomness Testing
Reply-To: [EMAIL PROTECTED]
Date: Thu, 9 Dec 1999 00:47:13 GMT
Ernst G. Giessmann <[EMAIL PROTECTED]> wrote:
: In the paper of Juan Soto "Randomness Testing of the AES Candidate
: Algorithms" a Random Excursion Test (and a variant of it)
: is used.
: Have you any further links to these tests?
You may want to try NIST's Round 1 randomness testing report - which
has quite a lot of information in it about the tests used:
http://csrc.nist.gov/encryption/aes/round1/r1-rand.pdf
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
I've seen better discussions in aphabet soup.
------------------------------
From: [EMAIL PROTECTED] (Jim Shapiro)
Subject: Re: MMPC - A multi-message encryption algorithm
Reply-To: [EMAIL PROTECTED]
Date: Thu, 09 Dec 1999 01:41:58 GMT
On Mon, 06 Dec 1999 08:31:25 GMT, zapzing <[EMAIL PROTECTED]> wrote:
>I read the article and it was very interesting.
>But doesn't MMPC provide a large subliminal
>channel, through which malicious software,
>for example, could communicate information
>about the key? Do you have any suggestions
>for eliminating the subliminal channel?
>
>Thanx, ZZ
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
A subliminal (literally "beneath threshold") message is one that is
hidden within an otherwise _unencrypted_ message. With MMPC there is
no unencrypted message -- all sub-messages are encrypted. In that
sense, MMPC encourages additional messages, although I would not call
them subliminal. All users of MMPC are, or at least should be, aware
that every transmission may contain sub-messages in addition to any
they have key(s) for.
Jim Shapiro
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: If you're in Australia, the government has the ability to modify your
files. >> 4.Dec.1999
Date: Thu, 09 Dec 1999 01:51:29 GMT
> If you're in Australia, the government has the ability
> to modify your files. Its cyber spooks have been given
> legal power not only to monitor private computers
> around the country, but to change the data they contain.
News flash: (for those of you who missed it)
If you have Microsoft Windows and Internet Explorer, your
government has the ability to modify your files. The bugs
that are in these fine pieces of software allow the governments
of the world to do lots of shit with the files on your hard disk.
Don't worry about the law- they certainly don't.
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Gaccm <[EMAIL PROTECTED]>
Subject: weak algorithm, too hard for me
Date: Wed, 08 Dec 1999 18:09:09 -0800
Reply-To: [EMAIL PROTECTED]
let me start off saying: 1)i don't know if this is the right place to
post, and 2)
I AM A MORON
ok, the reason that i am a moron, is that i forgot an important
password. I had it connect automatically, and thus forgot it. I connect
to a server with WS_FTP Pro 6.02, and it saves your passwords but does
not display them. so, i tried a few combos and saved the encrypted
version of the password. I checked the manual, and it said that is was
very easy to break the encrytion, but i can't. I was hoping that someone
here could: 1)do it for me, 2)show me how to, 3) tell me where i should
post.
here is the encryted version of what i need
VCF44BDDF6568BE16FC5C6734D1798F56574F679858563C
here are some sample tries:
V0BED4F9ED46B198113AC5A05036ABCA997646979A170AB
gabriel
V4AB626C797DCF4A9CB10D0DEE910CC1E9B63679CA37B77A3B5B3716F82A63DB67887
[EMAIL PROTECTED] //my email
VAD6A04E6BBE5995F3499C886473BF425556A693386A63D //guesses
of what i thoung it should be
Te1/Rm2
V91C9B61E09E141F9A5514A0AE0E4E3F88D9A366B58A869
Th1/Rm2
V9ADA77221D7D01FC93F30431C3FDABDB8D4A37338D896A
TH1/RM2
VF84E96C178EDF3FE587FE049F2A374065A7E67378F883B
TE1/RM2
V61F0C94835A1C3E640C81EC28AC621808A97378574
Te/Rm
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: alt.politics.org.nsa
Subject: Re: NSA future role?
Date: Thu, 09 Dec 1999 04:21:31 GMT
In article <[EMAIL PROTECTED]>, JCA <[EMAIL PROTECTED]> wrote:
>CLSV wrote:
>
>> albert wrote:
>>
>> > If you walk into the library of the University of Michigan, you can
> actually find
>> > all you need to know as far as how to make a nuclear bomb.
>>
>> One of those myths started by popular science magazines.
>
> Actually, it is true. However, you are right in that popular science
> magazines
>have been responsible for misleading one into thinking that just about anyone
> could in
>fact build a nuclear bomb.
>
> There is a long distance from the (well-understood) theoretical
> underpinnings of
>nuclear weapons to their realization. No clever clogs kid, or underfunded
> terrorists
>are likely to put together one any time soon.
>
Well it's true no terroist group is likel to put a clean effiecent nuclear
device together with out lots of expertise or money to the correct US
politican. Any terroist group with money and enriched uranium could
build a simple dirty nuclear bomb that could do a lot of damage. It
raelly ain't that much to them.
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: [EMAIL PROTECTED] (Steve K)
Subject: Re: NSA future role?
Date: Thu, 09 Dec 1999 03:50:22 GMT
On Thu, 09 Dec 1999 01:19:45 +0000, CLSV <[EMAIL PROTECTED]> wrote:
>albert wrote:
>>>> If you walk into the library of the University of Michigan, you can actually find
>>>> all you need to know as far as how to make a nuclear bomb.
>
>CLSV wrote:
>>> One of those myths started by popular science magazines.
>
>JCA wrote:
>> Actually, it is true. However, you are right in that popular science magazines
>> have been responsible for misleading one into thinking that just about anyone could
>in
>> fact build a nuclear bomb.
>
>To yank this thread more towards the charter of sci.crypt
>(I don't receive alt.politics.org.nsa so I will refrain
>from crossposting there) what about the following proposition:
>
>If you walk into a decent university library you can find all
>you need to build a good encryption algorithm.
>
>True or false?
Probably *very* true. Tom St Denis, a 17 year old HS student, is
working on the 2.0 revision of Peekboo, which so far looks like a very
decent encryption application. The 50 KB executable includes DH/DSS
key exchange, a decent PRNG, and a selection of 7 strong block ciphers
using 160 bit session keys. The GUI and Help menu are adequate for
use by crypto newbies.
http://www.cell2000.net/security/peekboo/index.html
Steve K
---Continuing freedom of speech brought to you by---
http://www.eff.org/ http://www.epic.org/
http://www.cdt.org/
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp
Subject: SRP - a secure alternative for authentication >> Nice reading ...
Date: Wed, 08 Dec 1999 23:14:38 -0500
Nice reading ...
--
Thanks, Richard
===============================================
SRP - a secure alternative for authentication by Kurt Seifried
December 8, 1999 - If users want to log into
servers we usually make them authenticate first. This has consisted mostly of a
username and password pair passed to the server, in cleartext, which is fine if you
have a 100% physically secure network using switches and no interlopers between
you and the server. Of course there are very few networks like this, so people have
invented schemes to encrypt and otherwise protect the authentication data when it
is sent across the network. This has been aided by the growth of cryptography,
where you have the same basic issues (prove to me who you are, in a secure
manner, across an unsecured channel).
EKE verses AKE
No this is not a wrestling match between a pair of Swedish brothers (sorry, I couldn't
resist). One of the most fundamental problems to encryption is the key exchange.
Finding an algorithm or method to securely mangle the data so that only the other
party can make sense of it is easy (there were 50+ algorithms in the initial AES
candidate selection, now narrowed down to 5). Securely exchanging keys with a
party that you probably have not communicated with before, especially across an
insecure channel is difficult at best. There are two primary methods currently in use,
EKE (Encrypted Key Exchange protocol) and AKE (Asymmetrical Key Exchange
protocol), and there are several others (such as IKE, Internet Key Exchange
protocol). EKE uses a variety of methods such as RSA, DSA or Diffie-Helman, and is
susceptible to a number of attacks, one of the more important ones being a man in
the middle attack. To combat this most authentication systems use some form of pre
shared secret, or use digital signature technology (where trusted third parties verify
the identity of one or both parties, and is used as the pre-shared secret).
EKE based transactions fill a wide variety of needs, and are the de facto standard for
SSL based transactions (which includes the vast majority of online commerce). SSL
typically employs certificates, which consists of a public and private portion, the
public portion not only contains a key, but information about the owner (such as
name, expiry date of the certificate, and so on). This public certificate is signed by
a
trusted third party, such as Verisign or Thawte, who have typically convinced large
www browser companies (like Netscape and Microsoft) to include their certificates
with the browser software (so by default most users blindly accept it). This is the
"pre-shared" secret typically used, and it works quite well (although it isn't
perfect).
This systems become much less practical however when you want to prove the
identity of the client (or large numbers of entities). The costs involved of getting a
third party to verify your identity and issue a certificate are quite high (Verisign
used
to sell them at $20 US but stopped). The costs involved in making that certificate
portable are even higher (a hundred dollars US for a smart card and smart card
reader is well within the average price range). In addition to this the amount of
information provided by a certificate is overkill, the majority of authentication
transactions only require a username and password. This is the area of
authentication that SRP works to solve.
It can be argued that SRP uses a form of preshared secret, the username and
password, however there are some differences. SRP makes use of AKE, essentially
each party exchanges some generated information (I'm not going to explain the math
here, please read Tom Wu's whitepaper on it, listed at the bottom) that is used to
prove the veracity of the data sent (but cannot actually be used to figure out say the
username and password). As far as I can tell SRP is the only protocol that uses AKE
currently, so it's also useful as a "reference" implementation, that is if you want to
learn about AKE and see how it's done, SRP is a good place to start (especially being
that it is OpenSource).
Other SRP benefits
SRP provides several benefits over traditional methods, the biggest being that no
actually encryption of the data takes place, meaning SRP can be exported legally
from the US. SRP also makes no use of the patented RSA algorithm (typically used in
key exchanges), so you can legally use it in the US (without having to pay RSA). SRP
does not use preshared secrets (in the typical sense of preshared secrets), so there
is nothing to steal (i.e. no certificate, server key, etc.) meaning to impersonate
someone you have to resort to stealing their username and password in some
manner (essentially you need to steal the authentication data in a time honored
fashion such as bashing the persons head in and kidnapping them, you cannot
generate the authentication data even if you manage to impersonate the server). SRP
is also quite simple compared to many encryption algorithms I have seen, which
should make testing and proving it is valid a bit simpler (peer review is always a
good thing).
Kurt: What prompted you to create SRP?
Tom: In the process of designing the authentication infrastructure for a Java-based
Webtop that was being developed at Stanford, I encountered the same problem that
has plagued countless software developers and engineers: I had to design and
implement a simple, yet secure password system to authenticate users and protect
both their sessions and their data. After doing a bit of research, I concluded that
there had to exist a method that was resistant to on-the-wire attacks while being
friendly to Open Source terms. Thus, SRP was invented.
Kurt: Do you feel that for authentication that AKE based protocols are better then
EKE based protocols?
Tom: AKE protocols like SRP have the advantage that the information stored on the
server side cannot be stolen and used to impersonate the clients. "Verifier-based"
protocols keep the data used for verification one step removed from the password
itself, and this one step is computationally difficult to reverse. Although EKE-style
protocols can be extended to achieve verifier-based functionality, it involves a
significant performance disadvantage relative to SRP.
Still the difference between the various strong password methods is minor compared
to the massive gulf that separates any of these methods from weak
challenge-response or any of the "classical" password authentication schemes.
Kurt: What is the patent (if any) on SRP?
Tom: Although Stanford is in the process of seeking patent protection for the SRP
technology, any issued patents will not affect the Open Source-friendly terms for
SRP. It is my intention to keep SRP available for Open Source projects everywhere,
since I believe that the Open Source community must continue to have access to
fundamental cryptographic technologies if it is to compete successfully with
proprietary products from closed-source vendors.
Kurt: I notice there are draft RFC's with it. Do you think SRP will achieve status as
a widely accepted protocol?
Tom: I believe it is up to the Internet crypto community as a whole to recognize the
considerable advantages SRP offers and to contribute to the SRP project. Because of
its flexibility (it decouples authentication from encryption so it can be incorporated
into products exported from the US), openness, and security, SRP already has made
its way into countless security-related products, both commercial and
non-commercial, and its installed base is growing rapidly. Programmers don't have
to design their own ad-hoc, weak password systems when they want to add
authentication to an existing product anymore, now they just use SRP and call it a
day.
"Tom Wu attends Stanford University where he created the SRP protocol, and now
works for Arcot Systems Inc. (http://www.arcot.com/)"
Summary
If you need to authenticate with a username and password SRP is definitely a good
protocol to do it securely. SRP has several advantages over programs like OpenSSH,
it is somewhat easier to implement in software (it doesn't require things like
OpenSSL for example), and since it is not cryptographic in nature export issues are
avoided. SRP does not make use of RSA or other patented ideas in any way, meaning
you do not need to worry about compiling it against RSAREF or anything strange like
that. As stated in the interview it appears that Stanford University will allow SRP to
remain "free" and unencumbered by patent issues, which is a definite issue to
consider when using a new (patented) protocol. SRP also supports encryption, but
this portion cannot be exported out of the USA or Canada, making it of somewhat
limited usefulness. If you need to secure logins, but are not as worried about the
actual data being exchanged (for example email which tends to fly around
unencrypted to start with), then SRP is an excellent protocol to use.
Kurt Seifried is a security analyst and the author of the "Linux Administrators
Security Guide", a source of natural fiber and Linux security, part of a complete
breakfast.
------------------------------
** 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
******************************
