Cryptography-Digest Digest #803, Volume #11 Wed, 17 May 00 19:13:01 EDT
Contents:
Re: What is a good Encryption program?? (Tim Tyler)
Re: AES final comment deadline is May 15 (DJohn37050)
Re: NIST releases final AES comments (DJohn37050)
Re: Jobs at Cloakware ("Steve Hollasch")
Re: Key generation ("C. Prichard")
Re: Jobs at Cloakware (Dan Day)
Re: What is a good Encryption program?? (Dan Day)
Re: bamburismus (Mok-Kong Shen)
Re: Unbreakable encryption. (Jerry Coffin)
Re: AES Comment: the Hitachi patent (Jerry Coffin)
Re: Chosen plaintext attack, isn't it absurd? (Jerry Coffin)
Re: QUESTIONS About ALGOS !! (Jerry Coffin)
Re: Chosen plaintext attack, ("C. Prichard")
Re: AES Comment: the Hitachi patent ("Lyalc")
Syncronized Atomic Time in Vb ("RecilS")
Re: Key generation (Eric Lee Green)
Re: Syncronized Atomic Time in Vb ("Adam Durana")
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: What is a good Encryption program??
Reply-To: [EMAIL PROTECTED]
Date: Wed, 17 May 2000 19:58:54 GMT
C. Prichard <[EMAIL PROTECTED]> wrote:
: A program that uses more than E +40 cipher combinations is good
: encryption, but E +63 is even better.
I guess (from your examples) you're describing the size of the keyspace in
decimal exponent notation.
The size of the keyspace is not normally strongly connected with
the strength of the cypher - though cyphers with a small enough
keyspace are always weak.
: FYI: 56 bit DES is about E +19. 128 bit DES is E +38.
2^56 ~= 10^17, not 10^19. DES uses a 64-bit (10^19) key - but a byte of
it is not used as key material. Also, what is 128-bit DES?
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Goodbye cool world.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: AES final comment deadline is May 15
Date: 17 May 2000 20:21:05 GMT
Every finalist has its proponents. I see advantages for every finalist.
Balancing all this and deciding will be challenging. It will be interesting to
see what NIST decides. Some of the comments even say to delay things a bit,
e.g. Schroeppel.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: NIST releases final AES comments
Date: 17 May 2000 20:22:57 GMT
Yes, a few of the comments were to increase rounds in some finalists.
Don Johnson
------------------------------
From: "Steve Hollasch" <[EMAIL PROTECTED]>
Subject: Re: Jobs at Cloakware
Date: Wed, 17 May 2000 12:19:06 -0700
Marlies Vincken wrote: << Knowledge of computational graph theory,
complexity theory, number theory and discreet [sic] mathematics. >>
David A Molnar wrote about "discreet mathematics" << This is a joke? >>
Isn't it correct to say that cryptography is the study of discreet
mathematics? =^)
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: Re: Key generation
Date: Wed, 17 May 2000 20:43:50 GMT
No,, that is very impressive. However you can weigh the seriousness of =
an attempt and log the affected user names, passwords attempted, =
related time etc. to be more able to compensate the affected user.
Policies like dummying a user account and letting it get hacked are =
something to consider, if you can gain from it. Prosecution probably =
needs more evidence than a login attempt. I would thing that to "get =
serious" they need tangible proff that something was taken. Just an idea =
about your policy regarding hacking.
Right now I'm working on a contract that requires the system to log =
failed authentications and deal with unauthenticated users after so many =
attempts. This constitutes a fairly high level of security that can be =
improved with the right human policy in place.
As part of the solution I am considering what encrypting user_ids or =
other page tags will accomplish besides making it impossible to =
impersonate a threaded user. Encrypting page tags prevents access of =
unauthorized content, and the solution is viable but it seems like =
something more can be done to really make security tighter. Can't seem =
to figure out another angle to it.
Once the user is authenticated, he either navigates using links =
presented or not at all. Contending for same identity disconnects the =
loser, possibly both as collaborating to obtain unauthorized use. =
Page-tag encryption seems worth more of my time to develop it. Its =
unobtrusive requiring no user cookie for authentication with each =
response (this is possibly the biggest plus.) The authenticated thread =
feature inherently has more integrity than assuming that all users =
requesting a page tag have been authenticated previously.
Impersonation, is a little trouble to prevent. Authentication is part of =
the solution but the system either needs to repeatedly challenge the =
user, or assume that the request came from an authenticated user. I =
think Page Tag encryption wins here as a compromise allowing the =
assumption to be used if the encrypted tag turns out to be valid.
-Charles Prichard
www.greentv.com
Eric Lee Green <[EMAIL PROTECTED]> wrote in message =
news:[EMAIL PROTECTED]...
> "C. Prichard" wrote:
> > (this is not dis-information now)
> [Should keep people from just banging away with bad keys for network
> authentication.]
> > (Returning you now to your previous military dis-information =
service.)
>=20
> I'm not sure we were discussing network authentication. In any event, =
I think
> you have stated an obvious observation that needed to be stated: =
limits need
> to be placed in order to prevent, e.g., "flood" attacks that exploit =
the
> limited entropy of PRNG's, for example.=20
>=20
> Unfortunately, what you then have is the opportunity for denial of =
service
> attacks. The attacker can sniff the network (either with a network =
scanner, or
> because he's already an employee with non-admin access and can use the =
OS's
> native directory function to gather the user names), detirmine what =
user names
> are in use, and then systematically attempt to log in to the server =
with each
> of those user names plus an invalid password. The result is an =
inaccessible
> server.=20
>=20
> Heading off that DOS attack means logging the connector's network ID =
and
> locking out that network ID. Unfortunately, that's nigh impossible, =
because I
> can shut down my network stack and bring it back up with a different =
IP and
> MAC address without difficulty (I run Linux, and happen to be using a =
network
> card that has a programmable MAC address -- a fact which causes our =
local
> network monitor system, ARPWATCH, some disconcertation, because I =
dual-boot
> with FreeBSD, and FreeBSD and Linux program the MAC address =
differently).=20
>=20
> A switched network fabric would help in that it would make network =
scanning
> much harder (you would have to have compromised the server, in which =
case,
> what's the point?), but would not otherwise help. My network switch, =
for
> example, has no problem with me switching my MAC address to some other =
MAC
> address -- it thinks I simply brought another machine online on my hub =
out
> here, and happily routes packets to said MAC address. =20
>=20
> The best I can think of is what the Linux and Solaris PAM (Pluggable
> Authentication Module) libraries do -- they insert an arbitrary delay =
into
> each failed authentication attempt, so that attackers cannot flood the =
system
> with arbitrary attempts, and they inform the system logger so that if =
you have
> LogWatch programmed right, it can beep you that someone's trying to =
break into
> the system. Thus the attacker is limited to, say, 6 attempts per =
minute,
> meaning that if he wanted to try all 2^30 likely passwords and pass =
phrases,
> he's going to be a while :-). This allows protecting the system from a =
flood
> attack, without allowing the attacker to deny service to the users on =
the
> system.=20
>=20
> I'm curious if you have any insights here that I haven't pulled out of =
the
> depths of my brain?=20
>=20
> --=20
> Eric Lee Green [EMAIL PROTECTED]
> Software Engineer Visit our Web page:
> Enhanced Software Technologies, Inc. http://www.estinc.com/
> (602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: Jobs at Cloakware
Date: Wed, 17 May 2000 21:16:20 GMT
On 17 May 2000 18:47:57 GMT, David A Molnar <[EMAIL PROTECTED]> wrote:
>Marlies Vincken <[EMAIL PROTECTED]> wrote:
>
>> · Knowledge of computational graph theory, complexity theory, number theory
>> and discreet mathematics.
> ^^^^^^^^
>
>This is a joke?
Intentional or not, it *is* funny, especially given the context.
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: What is a good Encryption program??
Date: Wed, 17 May 2000 21:29:06 GMT
On Mon, 15 May 2000 22:58:34 GMT, [EMAIL PROTECTED] (Steve) wrote:
>On 15 May 2000 20:13:31 GMT, [EMAIL PROTECTED] (S. T. L.) wrote:
>
>>PGP can.
>
>So can Scramdisk-- it makes "container files" that work like
>small, extra hard drives when mounted.
...or not so "small". While Scramdisk volumes can be as
small as 256K, they can be as large as 4GigB (if created
as a Windows file) or even 2047GigB (if created as a
disk partition).
>Everything that goes in
>is encrypted on the way in, everything that comes out is
>decrypted on the way out, but the container itself is never
>decrypted. A very secure way to store local files, and an easy
>program to use.
Yes, it's very nice. Instant, transparent, on-the-fly encryption.
Rather than manually decrypting your file to use it (which leaves
a plaintext version on the disk for a while) and then encrypting
it again when you're done with it, you can just store the file
on a Scramdisk volume, and examine/use it directly from the
Scramdisk volume, as easily as if it were not encrypted at all.
All you need to do is supply your passphrase to mount (open)
the volume, and then dismount it when you want to "lock" it back
up again.
Scramdisk can be found at http://www.scramdisk.clara.net/
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: bamburismus
Date: Wed, 17 May 2000 23:48:03 +0200
John Savard wrote:
> In the kappa test, two enciphered texts are compared to one another at
> various offsets (displacements in characters) and where the number of
> matching letters is similar to the higher number that would be
> produced by two unrelated plaintexts, rather than the lower number by
> two random sequences of letters, it becomes likely that the two texts
> were enciphered in the same key.
>
> Banburismus (the name derived from Banbury) was a refinement of this
> that gave extra weight to coincidences of more than one contiguous
> letter, since languages have additional structure (or redundancy) at
> the digraph, trigraph, and word levels, for example.
A presumably very dumb question: Is it correct to consider
that such techniques are no longer of interest in the era
of modern cryptography, i.e. they are for historical
records only? Thanks in advance.
M. K. Shen
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Unbreakable encryption.
Date: Wed, 17 May 2000 15:49:12 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> I find the spam posted by OP to be hilarious, particularly the
> FAQ on his web page. I guess we all learn something new
> everyday. Some highlights include:
Thank you! This definitely brightened up what had been a rather dull
morning. I especially liked the author of a calculation program not
knowing the term "truncate", so he had to explain what it was
instead...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: AES Comment: the Hitachi patent
Date: Wed, 17 May 2000 15:49:10 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> A comprehensive patent databank is offered by IBM on the
> internet, if I don't err.
A database, yes. Comprehensive, no.
> Now MARS comes from IBM. IBM is such
> a big firm and has itself numerous and numerous patents and hence
> must have a large staff of very competent patent specialists. I can't
> imagine that it could be a very difficult task for IBM to do a search
> for potential patent conflicts with MARS, if it ever cares to do so.
Yes and no -- conducting a search for potential conflicts is easy.
Being sure you've caught all possible conflicts is impossible. About
the best you can hope for is to be reasoanbly sure that you've caught
most of the most relevant conflicts, and even that takes a great deal
of time, effort and skill to do well.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Chosen plaintext attack, isn't it absurd?
Date: Wed, 17 May 2000 15:49:08 -0600
In article <8fu7ov$505$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> I mean, if the attacker is able to access the encipher machinery (but not
> the actual key) and then test the ciphertexts she wants, what stops her to
> access the DEcipher machinery?
Lots of things. Just for example, assume you've tapped into a
connection on a secure network -- all the data sent over the network
wire is automatically encrypted when it's sent, and automatically
decrypted when it's received. No user has direct access to
decryption capabilities at all.
It's fairly conceivable that you could get somebody hired as a
janitor or somesuch and have them copy some files over the network
for you to intercept. It would be MUCH more difficult to arrange to
send your own signal over their wire and have him intercept the
decrypted transmission.
Also note that once you've broken the cipher, you can decrypt ALL the
transmissions you've intercepted. If your janitor gets 5 minutes
alone with a machine that somebody forgot to log off of, he can send
one file over the network and be back to work in a few seconds. He
doesn't even necessarily need to bring any data with him; he can just
copy a reasonably well-known file (e.g. the executable to a word
processor or spreadsheet) that's already on the machine.
Having him catch data as it's decrypted is MUCH riskier. It's almost
certainly going to take longer, and he's going to need to copy the
decrypted data to some sort of removable media so he can take it with
him. Assuming security at the site is reasonably good, he's almost
certain to be caught if the tries to leave the secure area carrying a
disk or tape full of classified documents.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: QUESTIONS About ALGOS !!
Date: Wed, 17 May 2000 15:49:06 -0600
In article <8fu3it$osb$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> I'm new in Encryption, and I've to implement an Encryption Algo
> for an application.
> But I have to make a choice between efficiency and speed !
> Well I'd like to know if the DES / 3DES is a very fast algo ?
No. Rather the opposite: DES is fairly slow and 3DES is about one
third that speed.
> I've been told that Blowfish algorithm was very fast and secure.
> What do you think about it ?
BlowFish takes a while to set up the key, but encrypts quite quickly
once you've done the initial setup. A newer algorithm partly by the
same designer is TwoFish; it has many of the same characteristics to
at least some degree. You might also want to consider using Rijndael
-- like TwoFish, it's a candidate for AES; it's fast, and AFAIK,
nobody knows of an effective attack on its security. Code for
TwoFish and Rijndael (as well as all other AES finalists) is
available from:
http://csrc.nist.gov/encryption/aes/round2/r2algs.htm
Most of these (and certainly both TwoFish and Rijndael) are faster
than DES under most circumstances, especially in software. I should
point out that for pure speed, RC6 (which is one of the AES
finalists) is quite good. Unfortunately, quite a few people
conjecture it to be the weakest of the AES finalists, and unless it
IS selected for AES, you can't use it freely. As such, I'd stay away
from it unless it's worth the possibility of paying royalties to get
what may be weaker security, purely to gain a little bit of speed.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: Re: Chosen plaintext attack,
Date: Wed, 17 May 2000 21:16:36 GMT
Thanks for the information.
I'm glad CipherText has a small, key-dependent offset making the cipher =
optionally non-symmetric.
This was possibly another reason for the whitener. It prevents the known =
plaintext attack nicely. However, overall security is better when the =
decryption process for the whitened message is using some kind of =
non-involuted method.
I'll have review some of my references about using complementary values =
to make more of a non-symmetric cipher.
-Charles Prichard
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: AES Comment: the Hitachi patent
Date: Thu, 18 May 2000 08:28:45 +1000
and many, many hours of often tedious reading.
lyal
Jerry Coffin wrote in message ...
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>says...
>
>[ ... ]
>
>> A comprehensive patent databank is offered by IBM on the
>> internet, if I don't err.
>
>A database, yes. Comprehensive, no.
>
>> Now MARS comes from IBM. IBM is such
>> a big firm and has itself numerous and numerous patents and hence
>> must have a large staff of very competent patent specialists. I can't
>> imagine that it could be a very difficult task for IBM to do a search
>> for potential patent conflicts with MARS, if it ever cares to do so.
>
>Yes and no -- conducting a search for potential conflicts is easy.
>Being sure you've caught all possible conflicts is impossible. About
>the best you can hope for is to be reasoanbly sure that you've caught
>most of the most relevant conflicts, and even that takes a great deal
>of time, effort and skill to do well.
>
>--
> Later,
> Jerry.
>
>The universe is a figment of its own imagination.
------------------------------
From: "RecilS" <[EMAIL PROTECTED]>
Subject: Syncronized Atomic Time in Vb
Date: Wed, 17 May 2000 18:43:37 -0400
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Some of you may remember me making postings involving time-sensitive
encryption. The largest problem I encountered was creating a time
standard between both computers. The discrepancy involved was
anywhere from a few seconds to many minutes. Answer? Syncronize
both communicating clients by using the NIST Network Time Service.
NIST lists a total of 12 servers that provide the current time
(mostly retrieved from the US atomic clock in Boulder, Colorado) to
anyone who logs into the server.
This service is good enough to even (at least it claims) send not the
current time, but an estimate of what the time will be when it
arrives at your computer (I'm assuming by adding half the ping).
Still, the method I've programmed pings the 6 most reliable servers
(at least for my connection) and averages the times.
If you want to test it, log into port 13 of 132.163.4.101 with a
winsock TCP/IP or UDP/IP connection. The server will immediately
send a string which contains the current time, info on daylight
savings, server health, date, and tags verifying the data's
integrity.
If you're interested in the VisualBasic 6.0 (should work down to 4.0)
code I've written to take the average of 6 servers then let me know
and I'll post a follow up detailing the methods.
NOTE : If anyone knows a server (or webpage) with a realtime updating
level of the stock market (any of them will do, pref. the Dow Jones
index) pleas let me know. I want to test it as a random number
generator.
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBOSMglxJETAFqh0RgEQKx7gCdGiKsRCOlIbizLKclmBA3LCbRLesAoN+J
9/B7dyse5c6JOBDEGX9rcapy
=RL9i
=====END PGP SIGNATURE=====
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Key generation
Date: Wed, 17 May 2000 22:44:39 GMT
"C. Prichard" wrote:
> Right now I'm working on a contract that requires the system to log failed
>authentications and deal with unauthenticated users after so many attempts. This
>constitutes a fairly high level of security that can be improved with the right human
>policy in place.
PAM definitely logs failed authentications. We have a program called
'logwatch' running that will inform us when <n> number of failed
authentications have taken place. Unfortunately, any user on our internal
network can easily get the list of valid users (but not the passwords for
those users). What that means is that if a disgruntled worker (the usual
source of hack attacks) decides to do a denial of service attack against our
internal network, with your policy all he would need to do would be to
repeatedly attempt to log into the server using an invalid password and one of
each user's passwords. They'd all get locked out, and the sysadmins would be
pulling their hair out trying to track down what's happening. Because of that,
we don't lock passwords out for too many failed attempts, we simply log them
and alert the system administrator (who can then either remove the password
and suck the person in while tracking down the person, or block all IP/MAC
addresses other than "known good" ones and thus track down the IP/MAC address
of the attacker, or whatever).
> As part of the solution I am considering what encrypting user_ids or other page tags
>will accomplish besides making it impossible to impersonate a threaded user.
>Encrypting page tags prevents access of unauthorized content, and the solution is
>viable but it seems like something more can be done to really make security tighter.
>Can't seem to figure out another angle to it.
What I might do is use public key encryption. The process of obtaining an
authentication ticket includes chatting public keys between the client and
server, perhaps using a PKI third party if available. This is then used to
exchange a shared symmetric key, or you could use Diffie-Hellman to derive a
shared symmetric key. The password plus a random challenge sent by the server
is then encrypted using the shared symmetric key and sent to the server.
Subsequent transactions include a MD5 MAC encrypted with the private key of
the originator, along with a challenge string and sequence number that are
also part of that MAC. If one of those three values does not match, the ticket
is logged out.
Unfortunately, I have found no way of implementing this in an ordinary HTTP
client. SSL, as used for HTTPS, is a reasonable alternative. Assuming you use
a large-enough random ticket number so that re-use is unlikely, you can use
the ticket as the place-holder for authentication information. That is, each
generated page gets the ticket number inserted into its forms data or links.
> Once the user is authenticated, he either navigates using links presented or not at
>all.
Right, because the links will contain the ticket number encoded into them, and
without the ticket number, nothing happens. Assuming you're doing HTTPS, of
course. In HTTP, this would be trivially compromised by simply sniffing the
ticket numbers off the network.
> unauthorized use. Page-tag encryption seems worth more of my time to develop it.
I'm not sure what you are referring to. HTTPS encrypts the entire connection,
including the HTTP URL, right?
> Impersonation, is a little trouble to prevent. Authentication is part of the
>solution but
Not really, if you're talking about replay attacks, there are well-known
defenses against it (challenge strings, sequence numbers) that are included in
the SSL protocol. The biggest problem is that people leave their sessions
logged in and walk away from their computers. This requires timing out tickets
in an aggressive manner. Which is a pain in the @!#%! for users, because they
spend too long reading a page, they end up SOL next time they try to move
around :-(.
> > The best I can think of is what the Linux and Solaris PAM (Pluggable
> > Authentication Module) libraries do -- they insert an arbitrary delay into
> > each failed authentication attempt, so that attackers cannot flood the system
> > with arbitrary attempts, and they inform the system logger so that if you have
> > LogWatch programmed right, it can beep you that someone's trying to break into
> > the system. Thus the attacker is limited to, say, 6 attempts per minute,
> > meaning that if he wanted to try all 2^30 likely passwords and pass phrases,
> > he's going to be a while :-). This allows protecting the system from a flood
> > attack, without allowing the attacker to deny service to the users on the
> > system.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Syncronized Atomic Time in Vb
Date: Wed, 17 May 2000 18:53:29 -0400
That's the old daytime service (port 13), you should look into NTP if you
want to get good synchronization. If you search for XNTPD, or even NTP you
should be able to find some information.
- Adam
> If you want to test it, log into port 13 of 132.163.4.101 with a
> winsock TCP/IP or UDP/IP connection. The server will immediately
> send a string which contains the current time, info on daylight
> savings, server health, date, and tags verifying the data's
> integrity.
------------------------------
** 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
******************************
