Cryptography-Digest Digest #863, Volume #12 Sat, 7 Oct 00 09:13:00 EDT
Contents:
Re: NSA quote on AES ("Brian Gladman")
Re: Q: does this sound secure? (Paul Rubin)
Block Cipher Question ("musashi_x")
Re: i should have finished high school (ca314159)
Re: Block Cipher Question (David Crick)
Re: Advanced Encryption Standard - winner is Rijndael ("Rick Braddam")
Re: NSA quote on AES (Tim Tyler)
Re: TC8 -- Yet Another Block Cipher (Tom St Denis)
Re: Idea for Twofish and Serpent Teams (Tom St Denis)
Re: one time pad using a pseudo-random number generator (Simon Johnson)
Re: NSA quote on AES ("Brian Gladman")
Re: one time pad using a pseudo-random number generator (Herman Rubin)
Re: Error-correcting code ? (John Bailey)
----------------------------------------------------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: NSA quote on AES
Date: Sat, 7 Oct 2000 11:17:39 +0100
"David Schwartz" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Brian Gladman wrote:
>
> > I am absolutely certain that NSA attempts to manipulate the perceptions
of
> > outsiders by issuing statements designed to be misinterpreted. This
does
> > mean that considerable care is needed in reading them. I hence don't
blame
> > people for being sceptical about their content but they won't always be
> > right in taking this line.
>
> When a statement appears to be carefully crafted, I assume it means
> exactly and only what it says. I disregard all implications. I think
> this is the correct way to read NSA statements.
In principle I agree with this approach and I believe that it leads to a
sensible conclusion in this case. Unfortunately, however, very few
statements of any length in english are devoid of the need for
interpretation of some kind so the approach does not always produce the
right answer (if there ever is such a thing).
Brian Gladman
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Q: does this sound secure?
Date: 07 Oct 2000 03:27:55 -0700
"William A. McKee" <[EMAIL PROTECTED]> writes:
> I have to ask the user for an user id and password in a Java applet (client)
> then validate it on a server. Does this sound like a secure scheme?
No.
> 1) the server issues a random session key (32 bits).
> 2) the user id and password are hashed (MD5) by the client.
> 3) the session key and hash key from 2 are hashed (MD5).
Wait a sec, how did the hash key from 2 and the session key come into
contact so they could be hashed together? Do you mean the server sent
the session key unencrypted to the client? That means it's not really
a key, but more like a salt. It's known to the attacker.
> 4) the user id and hash key from 3 are sent to the server.
Oops. Now the attacker, knowing the session ID, and the hash from step 3,
can recover the password by brute force search.
> 5) the server looks up the user id in a password file then hashs the session
> key and the stored hash key (previously computed, the same as in 2).
> 6) the two hash keys (from 3 and 5) are compared.
> 7) the server issues a "PASS" if 6 compares true (and moves into a "logged
> on state") else it issues a "FAIL"
>
> Passwords are at least 6 characters long with at least one non-alpha
> character.
This is nowhere near enough.
> Is there any advantage to using SHA instead of MD5?
No. The scheme is insecure either way.
> I also have a registration dialog box in the client that asks for a
> new user id and password. The data is hashed as in 2 and the user
> id and hash key are sent directly to the server to be added to the
> password file. Does this compromise security?
Yes, now the new password is compromised just like the old one.
Look, do yourself a favor, stop trying to design protocols. The
simplest way to do what you're describing is encrypt the whole channel
with SSL if you can. Then you can just send the unhashed password
over the encrypted channel and hash it on the server side if you're
storing hashed passwords in the database. If you're writing a web
application, this also lets you avoid needing an applet, and avoiding
applets is always a good thing.
If you can't use SSL and you're serious about protecting the
passwords, you have to use something like SRP
(http://srp.stanford.edu) or one of its many equally complicated
competitors. But I don't recommend that because it's a big hassle,
plus AFAIK all these schemes require secure random numbers on the
client side, which are not necessarily easy to come by.
------------------------------
From: "musashi_x" <m u s a s h i _ [EMAIL PROTECTED]>
Subject: Block Cipher Question
Date: Fri, 6 Oct 2000 23:00:48 -0400
Something got me thinking recently...(I am, of course, a crypto-newbie). I
have a question about CBC output. If you were to encrypt something with,
say, Blowfish in cipher block chaining mode and then remove the first 7
characters of the output, wouldn't that make cryptoanalysis a great deal
harder? From what I understand every block is dependent/related to the
first block, so wouldn't keeping the first 7 characters either altered or
missing (until end-recipient manually adds them in) really screw things up
for analysis?
example of what i mean:
input: My dog is green
<runs through CBC cipher>
output: sk38asldfj8iur3r3kljffasf33473fjaseru (etc.....)
Now I manually change the first characters from "sk38asl" to "1skn398"
Or I just add a phrase like "1zkr" to the very beginning of the output.
The end recipient is the only other person who knows that I alter the output
in this way, and manually changes things back to the proper ciphertext
before decrypting as normal.
As kludgy and esoteric as this method might be, would it make analysis
harder in CBC ciphertext or not?
just curious
------------------------------
From: ca314159 <[EMAIL PROTECTED]>
Crossposted-To: sci.astro,sci.physics.relativity,sci.math
Subject: Re: i should have finished high school
Date: Sat, 07 Oct 2000 11:41:25 GMT
In article <apnD5.9983$[EMAIL PROTECTED]>,
"Paul Lutus" <[EMAIL PROTECTED]> wrote:
> Dv18 of trp <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>
> > an object 5117961800 miles in diameter rotating once per day would
be
> traveling
> >
> > faster than the speed of light on the surface.
>
> These seeming paradoxes aren't really paradoxes. In relativity,
velocities
> do not add up as they do in normal arithmetic.
>
> http://math.ucr.edu/home/baez/physics/headlights.html
>
> http://math.ucr.edu/home/baez/physics/velocity.html
>
> --
>
> Paul Lutus
> www.arachnoid.com
It might be interesting though to consider how
this effect may be used for FTL computation.
For instance, if a hologram is made of a slide rule
with a displacement between the slides, then
the apparent FTL motion due to the lighthouse effect,
would rapidly shift one's perspective on the two or
more slides, providing rapid computation.
The problem of resolution can't be any harder than
programming, decoherence, and error correction in
quantum computers ? If a transmission hologram is
used then the intereference problem becomes a diffraction
(aliasing) problem, but aliasing seems easier to deal
with than interferences.
The holographic slide rules begin to look more like
computing with Moires in an analog manner much the
same way holographic recognition can rapidly scan
bar codes at a supermarket checkout counter.
I/O though, is always a classical bottleneck as
it is in quantum teleportation, and the mind-body
problem as well.
--
--
http://www.bestweb.net/~ca314159/
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: Re: Block Cipher Question
Date: Sat, 07 Oct 2000 12:54:07 +0100
musashi_x wrote:
>
> input: My dog is green
> <runs through CBC cipher>
> output: sk38asldfj8iur3r3kljffasf33473fjaseru (etc.....)
> Now I manually change the first characters from "sk38asl" to "1skn398"
> Or I just add a phrase like "1zkr" to the very beginning of the output.
>
> As kludgy and esoteric as this method might be, would it make analysis
> harder in CBC ciphertext or not?
However it hinders cryptonalysis, you now have the situation whereby
for each message you somehow have to transmit your changes to the
output of the cipher for that message.
This implies you have a secure method of exchanging this information,
which - other than reducing the amount of text you have to transfer
securely - is still the same problem you'll always have with
symmetric (non public key) encryption systems.
--
+-------------------------------------------------------------------+
| David A. Crick <[EMAIL PROTECTED]> PGP: (OCT-2000 KEY) 0xE0F73D98 |
| Damon Hill Tribute Site: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
+-------------------------------------------------------------------+
------------------------------
From: "Rick Braddam" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk
Subject: Re: Advanced Encryption Standard - winner is Rijndael
Date: Sat, 7 Oct 2000 05:32:59 -0500
Reply-To: "Rick Braddam" <[EMAIL PROTECTED]>
[EMAIL PROTECTED] (David Schwartz) wrote in
[EMAIL PROTECTED]>:
>
>Rick Braddam wrote:
> >
> > When approved, the AES will be a public algorithm designed to protect
> > sensitive government information well into the 21st century. It will
> > replace the aging Data Encryption Standard, which NIST adopted in 1977
> > as a Federal Information Processing Standard used by federal agencies
> > to protect sensitive, unclassified information.
>
> This doesn't say that the U.S. has decided that Rijndael is unsuitable
>for protecting classified information. In fact, at the time this was
>written, it wasn't even known that the AES was Rijndael.
It doesn't matter that they didn't know that the AES would be Rijndael.
The security laws and military regulations have been in effect for a long
time, and apply to all aspects of handling classified information. They
are very explicit, and apply even to civilian contractors who must use
classified in performing their contracts.
>From the National Industrial Security Program Operating Manual (NISPOM) at
http://www.tscm.com/Nispom.html :
<quote>
1-104. Security Cognizance.
a. Consistent with 1-101e, above, security cognizance remains with each
federal department or agency unless lawfully delegated. The term
"Cognizant Security Agency" (CSA) denotes the Department of Defense (DoD),
the Department of Energy, the Nuclear Regulatory Commission, and the
Central Intelligence Agency. The Secretary of Defense, the Secretary of
Energy, the Director of Central Intelligence and the Chairman, Nuclear
Regulatory Commission may delegate any aspect of security administration
regarding classified activities and contracts under their purview within
the CSA or to another CSA. Responsibility for security administration may
be further delegated by a CSA to one or more "Cognizant Security Offices
(CSO)." It is the obligation of each CSA to i nform industry of the
applicable CSO.
b. The designation of a CSO does not relieve any Government Contracting
Activity (GCA) of the responsibility to protect and safeguard the
classified information necessary for its classified contracts, or from
visiting the contractor to review the securi ty aspects of such contracts.
5-402. TOP SECRET Transmission Outside a Facility.
Written authorization of the GCA is required to transmit TOP SECRET
information outside of the facility. TOP SECRET material may be
transmitted by the following methods within and directly between the U.S.,
Puerto Rico, or a U.S. possession or trust territory.
a. The Defense Courier Service (DCS), if authorized by the GCA.
b. A designated courier or escort cleared for access to TOP SECRET
information.
c. By electrical means over CSA approved secured communications security
circuits provided such transmission conforms with this Manual, the
telecommunications security provisions of the contract, or as otherwise
authorized by the GCA.
<end quote>
The first sentence in paragraph 5-402 specifies that for transmission by
electrical means written permission is required before Top Secret
information can even be transmitted outside a facility. Subparagraph c
specifies "approved secured communications security circuits" which will
be implemented by *hardware encryption devices* -- at least until Motorola
gets the AIM-100 certified as an encryption device.
This means, of course, that *if* the Department of Defense, the Department
of Energy, the Nuclear Regulatory Commission, or the Central Intelligence
Agency approves the AES, its use is provided for in the contract, or it is
otherwise authorized by the GCA, that it can be used for Top Secret
information.
Note that it is extremely unlikely that a GCA will authorize, or allow in
contract provisions, any method of transmitting TS information which has
not previously been authorized by a CSA. No one who works with classified
information will stick their neck out by approving actions which they
don't already have approved by their chain of command. That would be the
fast track to getting out of the business.
Also note that SECRET information may also be sent by Express Mail,
registered mail, or commercial carrier, and CONFIDENTIAL information may
be sent by Certified mail in addition to the methods for SECRET.
Look over the NISPOM, that's as close to the security training given
(annually!) to those who work with classified information as you're likely
to get unless you start working with it yourself.
If this doesn't clear up the controversy, it may be necessary for you to
apply for a job in the government which requires handling classified in
order to get the necessary training. There you will find out what
"paranoid" really means. (Yes, I have had that training... several years
ago, now).
Rick
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: NSA quote on AES
Reply-To: [EMAIL PROTECTED]
Date: Sat, 7 Oct 2000 11:42:32 GMT
Brian Gladman <[EMAIL PROTECTED]> wrote:
: "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> Brian Gladman <[EMAIL PROTECTED]> wrote:
:> : You see 'where appropriate' as a 'let out' clause but you fail to notice
:> : that the statement also says that NSA intends to use the AES in meeting
:> : the national security ***information protection*** needs of the
:> : United States government".
:>
:> The get-out clause reduces the positive statement about intended use
:> to meaninglessness.
: What you mean is that *you* see this statement as meaningless because you
: judge that NSA is being insincere in making it.
I don't doubt their sincerity.
You can draw practically no conclusions about what use the NSA will put
AES to - besides the fact that they'll use it for something.
This is, of course, as it should be. NSA press releases should not convey
any information about the inner workings of the agency - except when it is
deemed necessary for PR purposes. If we had found out much about what
the NSA were going to be doing the AES, we would have gained information
we did not need to know, as would any opponents of the US government.
This sort of vacuous hot air at least makes the taxpayers feel that
they're getting their money's worth ;-)
:> As always, information flows into the NSA, but not much is seen to emerge
: from it.
: Quite a bit of information does flow out of NSA but people are not willing
: to trust the organisation. [...]
Probably with good reason - since the organisation is essentially an
espionage agency. Would you trust the words of an agent known to be a spy?
Certainly for many years not much came out of the NSA into the public view.
The organisation didn't even officially exist.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: TC8 -- Yet Another Block Cipher
Date: Sat, 07 Oct 2000 11:56:00 GMT
In article <8rgpr1$4pj$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> This cipher is designed after CS-Cipher but is much simpler and uses
> little ram/rom. It's a cute cipher and I would appreciate any
comments.
>
> This cipher has awesome diffusion amongst the bytes (64-bit block
> cipher) and is very simple to look at.
>
> I noticed very little comments on MyFish... oh well...
Oops... there was a problem with the keyschedule. I forgot to take the
keys and additive constant modulo 256. I posted revised source code on
my website.
Tom
http://www.geocities.com/tomstdenis/files/tc8.c
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Idea for Twofish and Serpent Teams
Date: Sat, 07 Oct 2000 11:58:07 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (JPeschel) wrote:
> Benjamin Goldberg [EMAIL PROTECTED] writes:
>
> >JPeschel wrote:
> >> Runu Knips writes:
> >> >Helger Lipmaa wrote:
> >> >> There was a thread recently in this newsgroup, about the general
> >> >> attitude that guys who understand nothing about security try to
> >> >> strut and to demand and to insult those who know better.
> >> >
> >> >Tom might insult people unnecessarily in this NG, but
> >> >AFAIK he's far from being a 'guy who understand nothing
> >> >about security' !
> >>
> >> Much of what Tom posts is insulting, patronzing, wrong or
exaggerated.
> >
> >You sure you're not confusing Tom with David Scott?
>
> No. David Scott has been posting here a lot longer, and doesn't
> use commas. I can see why you might confuse the two, though:
> they're a lot alike, but don't like each other. One is an old cat
> like me, and, also like me, not about to change; the other is
> young enough to decide not to grow up to be like his nemesis.
Right, well why not comment on my research (tc1..8, myfish, etc...)
instead of my manners?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: one time pad using a pseudo-random number generator
Date: Sat, 07 Oct 2000 12:06:24 GMT
In article <[EMAIL PROTECTED]>,
"William A. McKee" <[EMAIL PROTECTED]> wrote:
> Is using a strong pseudo-random number generator (2^19937) as a one-
time pad
> a good way to encrypt data? If not, why?
>
> TIA,
> Will McKee.
>
>
It is, but its can never be secure as a one-time pad. The reason is
that the keystream is a determinsitic function the input key. Thus,
cryptanalysis can (atleast in theory) recover the key from the cipher-
text.
e.g. LFSR's -> Produce good pseudo-random output, but can be broken
easily by stepping the outputs through the feedback register,
backwards :)
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: NSA quote on AES
Date: Sat, 7 Oct 2000 13:38:34 +0100
"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Brian Gladman <[EMAIL PROTECTED]> wrote:
> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> :> Brian Gladman <[EMAIL PROTECTED]> wrote:
>
> :> : You see 'where appropriate' as a 'let out' clause but you fail to
notice
> :> : that the statement also says that NSA intends to use the AES in
meeting
> :> : the national security ***information protection*** needs of the
> :> : United States government".
> :>
> :> The get-out clause reduces the positive statement about intended use
> :> to meaninglessness.
>
> : What you mean is that *you* see this statement as meaningless because
you
> : judge that NSA is being insincere in making it.
>
> I don't doubt their sincerity.
>
> You can draw practically no conclusions about what use the NSA will put
> AES to - besides the fact that they'll use it for something.
I can draw the conclusion that NSA will use AES to protect some US national
security information - not just 'something', which is much less specific.
Others have drawn other conclusions.
Brian Gladman
------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Subject: Re: one time pad using a pseudo-random number generator
Date: 7 Oct 2000 07:44:13 -0500
In article <8rluqi$9ru$[EMAIL PROTECTED]>,
Bill Unruh <[EMAIL PROTECTED]> wrote:
>In <[EMAIL PROTECTED]> "William A. McKee" <[EMAIL PROTECTED]> writes:
>>Is using a strong pseudo-random number generator (2^19937) as a one-time pad
>>a good way to encrypt data? If not, why?
>Depends on your definition of strong. Some cryptosystems are just that (eg
>RC4). Some random number generators are terrible for crypto, though wonderful
>for random simulations.
This is questionable. The correct version is that some
generators are better for calculation by simulation of
well-behaved integrals than random numbers, but these do
not pretend to behave like random numbers. These are
called quasi-random.
A good set of pseudo-random numbers should be practically
indistinguishable from random numbers. What happens is
that a generator may be considered good until someone
finds a situation where it fails.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
------------------------------
From: [EMAIL PROTECTED] (John Bailey)
Subject: Re: Error-correcting code ?
Date: Sat, 07 Oct 2000 13:03:07 GMT
On Sat, 07 Oct 2000 05:45:27 GMT, [EMAIL PROTECTED] wrote:
>Does anyone know an algorithm, simple or well-documented (like, source code)
>enough that an idiot like me can implement it, for error-correcting short
>strings of digits ?
I assume you meant by hand using arabic numbers.
This is very crude, but it should satisfy your requirements:
Based on three principles:
1) Use sum of digits mod 10 to detect an error in a pattern.
2) Use multiple checks with a set of patterns chosen so every digit
position is checked by a unique set of checks
3) Hope only one error occurs
Call 1001110 pattern A
Call 0110011 pattern B
Call 1010100 pattern C
Positions 2,4, and 7 are reserved for check digits, to be computed
after the other digits are entered.
Using pattern A, set digit 4 so that the sum of digits 1, 4,5, and 6
is zero mod 10.
Using pattern B, set digit 2 so that the sum of digits 2,3,6, and 7 is
zero mod 10
You can figure out the last pattern. and if you need more than 4
digits encoded, you can extend this to 12 digit input by adding a
pattern D.
I assume its obvious how a single error in any digit location can be
detected and corrected based on a resultant pattern of check digit
mismatches.
If you meant binary digits, this works too, but some of the more
sophisticated schemes allow simpler code.
John
------------------------------
** 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
******************************
