Cryptography-Digest Digest #769, Volume #11 Sun, 14 May 00 08:13:01 EDT
Contents:
Re: Crypto Export ("Stou Sandalski")
Re: UK issue; How to determine if a file contains encrypted data?
([EMAIL PROTECTED])
Re: S-BOX Construction Tutorial? (Terry Ritter)
Re: Destructive crypting ([EMAIL PROTECTED])
CipherText optimized for Page Tag Encryption. ("C. Prichard")
CipherText Optimized ("C. Prichard")
Re: Theoretical question (Mok-Kong Shen)
Re: On higher level Feistel schemes (Mok-Kong Shen)
Re: S-BOX Construction Tutorial? (Mok-Kong Shen)
Re: Destructive crypting (Daniel =?iso-8859-1?Q?=C5kerud?=)
Re: Destructive crypting (Daniel =?iso-8859-1?Q?=C5kerud?=)
Re: Destructive crypting (Daniel =?iso-8859-1?Q?=C5kerud?=)
Re: security (David Formosa (aka ? the Platypus))
Encryption of graphics by transposition (John Bailey)
----------------------------------------------------------------------------
From: "Stou Sandalski" <tangui [EMAIL PROTECTED]>
Subject: Re: Crypto Export
Date: Sat, 13 May 2000 22:00:45 -0700
Hey people thanx for the information, I am writing my paper now and its due
monday hehe, my idiotic ISP's news server was down all week so I couldn't
read this stuff (I am not down with deja)... but then again they run like NT
so how can I blame them... their MFM drives proly ran out of room or
something...
anyway thanks again
Stou
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: UK issue; How to determine if a file contains encrypted data?
Date: Sun, 14 May 2000 05:12:32 GMT
On Sun, 14 May 2000 02:26:24 GMT, zapzing <[EMAIL PROTECTED]> wrote:
<snip>
>>
>> The critical challenge to the UK law will not be using stenography to
>> hide the cipher text, but rather devising encryption apps that give no
>> appearance of being an encryption app.
>>
>> So who is going to be the first person to devise an encryption app
>> that is itself completely hidden and undetectable?
>>
>>
>But you could have a perfectly good reason
>for having that encryption app around
>Perhaps you actually do use encryption to
>send email to friends. Some files might just
>use a different key that you deny the
>existence of, that's all.
>You would give the police the key to your
>emails that you send to your "cover" friends.
>the other files, you say 'Gosh, I don't
>really know what that is".
Yes, I was supposing that most apps have a keyring which would give
away the existence of the other keys. So perhaps one doesn't need to
hide the app, but one does need the capacity to hide the existence of
keys.
Beyond the UK, in countries where the simple possession of an
encryption app might result in incarceration or even torture without
trial, I suspect an app that is itself hidden would be a decided
advantage. Especially since with the growing complexity of OSs, use
of caches, registry keys, etc etc, it is getting beyond the capacity
of all but the most sophisticated users to hide or remove all traces
of an app. and its use.
In such a situation, I suspect I'd use PGP loaded to a virtual drive
from a floppy on a DOS only machine, making sure the disk was removed
and physically hidden and secure when not in use.
>--
>Do as thou thinkest best.
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: S-BOX Construction Tutorial?
Date: Sun, 14 May 2000 05:26:39 GMT
On Sat, 13 May 2000 14:49:10 -0700, in
<8fjm8v$nqr$[EMAIL PROTECTED]>, in sci.crypt "Simon Johnson"
<[EMAIL PROTECTED]> wrote:
>Does any one have a PDF or HTML S-BOX construction tutorial?
>If So please, leave a post with the URL as a reply to this message thanxs.
"S-boxes" are used in different ways in different ciphers, making
different things more or less important. Any particular construction
approach probably will be oriented toward a particular design, and the
approach you need should be oriented toward your particular needs.
Typically, a modern S-box has an even binary power number of elements
(e.g., 2**4 or 16, 2**8 or 256, etc.). There is one element of each
possible value and these are permuted or shuffled. Up to this point,
all we need to know is how to count and how to shuffle.
Some designs use "small" (e.g., "4-bit") S-boxes, but such small boxes
are often weak, and so should be tested before being used. There are
various tests including diffusion, Boolean function nonlinearity,
etc., with at least one new test found for every new attack on S-box
structure. An alternative is to use "large" ("8-bit" or larger)
S-boxes, but that is a cipher design decision.
DES-style ciphers often have a fixed set of boxes; that means
opponents will know the complete structure, thus making their attacks
that much easier. An alternative is to key-select each box "at
random" from among all possible permutations, but that is another
cipher design decision.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Destructive crypting
Date: Sun, 14 May 2000 05:38:06 GMT
Problem with what you propose is that anyone can capture the hashed
password, and use that to impersonate the user. (AKA a replay attack)
So it is no more secure than sending password in clear text.
To be secure, you need some kind of challenge-response which is
session specific.
In simple terms, one approach is for the server to send a randomly
selected string of bytes as a session ID. The server one way hashes
the client password (from its passord register) with the session ID,
and the client also one way hashes password with the session ID and
sends the result to the server. The server compares the hashed output
from the client with its local result, and if they are identical, it
knows client must have been hashed it with the correct password.
Client is authenticated (ie logged on) and session ID is deleted.
Variation on this approach is required for user to change password.
Might be easiest to read up on Password Authentication Protocol and
Chalenge Handshake Authentication Protocol as used over PPP on the
'net.
On 13 May 2000 21:47:49 GMT, [EMAIL PROTECTED] (Daniel
=?iso-8859-1?Q?=C5kerud?=) wrote:
>
>Hi ppl,
>
>I need to know of a good (worldwide accepted) one-way crypt algorithm (like
>the linux crypt()) that you can use in commercial applications. (Yes, i am
>willing to pay a license, if it doesn't cost _too_ much).
>
>(I will use it to send a password over tcp/ip)
>
>Thank you all!
>
>--
>
>
>
>Daniel Åkerud
>Programvaruteknik, MAH
>Email: [EMAIL PROTECTED]
>Homepage: http://zilch.pvt.te.mah.se
>
>
>
>
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: CipherText optimized for Page Tag Encryption.
Date: Sun, 14 May 2000 06:18:39 GMT
The Perl implementation of CipherText has now been optimized for Page =
Tag Encryption.
The algorithm now exists in a Perl Class module so that keys can be set =
once before ciphering multiple strings. Coding is done as shown in the =
following example where multiple strings are encrypted without =
rebuilding the keys:
my @IN =3D ('hello', 'goodbye');
=20
my $key =3D '12345670';
=20
my $params =3D "MODE=3DLEVEL II;KEY=3D".$key;
=20
$cipher =3D new CipherText::CipherTextII( $params );
=20
foreach $_ (@IN){
=20
my $MSG =3D $cipher->encipher( $_ );
=20
print "RESULT1:$MSG =3D $_<br>";
=20
$MSG =3D $cipher->decipher( $MSG );=20
=20
if ($_ ne $MSG) { print "ERROR: Unexpected result from =
CipherText:<br>";}
=20
print "RESULT2:$MSG =3D $_<br>";
}
This increases throughput dramatically over previous performance.
A data-dependent shift is also applied to each key before ciphering to =
improve message integrity.=20
With these recent developments, the CipherText non-blocking cipher now =
has a pseudo-blocking mode as it is appropriately optional for use in =
encrypting messages a line at a time, with each line treated as a new =
message. The data-dependent shift is based on message length making =
key-pair attacks possible only on strings of the same length. However =
the applied cipher pattern will always exceed line length and the actual =
root key length is masked reducing the number of exposed pairs.=20
Although CipherText is somewhat vulnerable to key-pair analysis in this =
pseudo-blocking configuration, its easily possible to use double =
encryption to improve security.=20
A logical progression in the development of CipherText's security would =
seem to be the making of somehow-predictable alterations to the cipher =
with each new message line. However, its also possible to go the other =
way and use a non-repeating set of cipher combinations, also resolving =
to NOT reset the applied sequence with each line.=20
-Charles Prichard
www.greentv.com
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: CipherText Optimized
Date: Sun, 14 May 2000 05:53:48 GMT
Perl implemetation of CipherText has now been optimized for Page Tag =
Encyption.
The algorithm now exists in a Perl Class module so that keys can be set =
once before ciphering multiple strings. Coding is done as shown in the =
following example where multiple strings are encrypted without =
rebuilding the keys:
my @IN =3D ('hello', 'goodbye');
=20
my $key =3D '12345670';
=20
my $params =3D "MODE=3DLEVEL II;KEY=3D".$key;
=20
$cipher =3D new CipherText::CipherTextII( $params );
=20
foreach $_ (@IN){
=20
my $MSG =3D $cipher->encipher( $_ );
=20
print "RESULT1:$MSG =3D $_<br>";
=20
$MSG =3D $cipher->decipher( $MSG );=20
=20
if ($_ ne $MSG) { print "ERROR: Unexpected result from =
CipherText:<br>";}
=20
print "RESULT2:$MSG =3D $_<br>";
}
This increases throughput dramatically over previous performance.
A data-dependent shift is also applied to each key before ciphering to =
improve message integrity.=20
With these recent developments, the CipherText non-blocking cipher now =
has a pseudo-blocking mode as it is appropriately optional for use in =
encrypting messages a line at a time, with each line treated as a new =
message. The data-dependent shift is based on message length making =
key-pair attacks possible only on strings of the same length. However =
the applied cipher pattern will always exceed line length and the actual =
root key length is masked reducing the number of exposed pairs.=20
Although CipherText is somewhat vulnerable to key-pair analysis in this =
pseudo-blocking configuration, its easily possible to use double =
encryption to improve security.=20
A logical progression in the development of CipherText's security would =
seem to be the making of somehow-predictable alterations to the cipher =
with each new message line. However, its also possible to go the other =
way and use a non-repeating set of cipher combinations, also resolving =
to NOT reset the applied sequence with each line.=20
-Charles Prichard
www.greentv.com
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Theoretical question
Date: Sun, 14 May 2000 11:26:18 +0200
Nicol So wrote:
> A "random function" is usually taken to mean a function chosen uniformly
> at random from the set of all functions with a given domain and
> codomain. That's probably what the original poster meant.
Under that very general assumption (all functions without restrictions
to the properties) I don't yet see that much useful properties could be
derived therefrom.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On higher level Feistel schemes
Date: Sun, 14 May 2000 11:39:38 +0200
zapzing wrote:
> So we would be doing something like this:
>
> C=C+E(K1+A,K2+B)
> D=D+E(K1+B,K2+A)
> A=A+E(K1+C,K2+D)
> B=B+E(K1+D,K2+C)
>
> where E(K,P) indicates the encryption of P with key K.
> You could then do some other rounds with different keys.
I think it might be of interest to point out that the above when
compared to recursive application of the Feistel scheme is
analogous to a comparison of iteration with recursion in general
programming. Iteration is in most cases more computationally
efficient than recursion.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: S-BOX Construction Tutorial?
Date: Sun, 14 May 2000 11:51:43 +0200
Terry Ritter wrote:
> DES-style ciphers often have a fixed set of boxes; that means
> opponents will know the complete structure, thus making their attacks
> that much easier. An alternative is to key-select each box "at
> random" from among all possible permutations, but that is another
> cipher design decision.
I suspect that one factor that has favoured the use of fixed S-boxes
(and the same for all rounds) is ease of implementation (possibly
particularly in hardware).
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Daniel =?iso-8859-1?Q?=C5kerud?=)
Subject: Re: Destructive crypting
Date: 14 May 2000 10:02:49 GMT
>> I need to know of a good (worldwide accepted) one-way crypt algorithm (like
>> the linux crypt()) that you can use in commercial applications.
>
>That's called a one-way hash function.
>You could use MD5 or SHA-1.
Aah, i c...
>> (Yes, i am willing to pay a license, if it doesn't cost _too_ much).
>
>They are free.
Sounds great... :)
>> (I will use it to send a password over tcp/ip)
>
>You realize that an attacker can replay sessions anyway, right?
>And if you don't store hash of a hash on the server, it's actually
>worse than sending cleartext passwords.
Aah, that's why I through away that idea a while ago.
No at that moment I didn't realise that...
Good point :)
It really hurts to be a crypto newbie! ;)
>What are you trying to accomplish?
Exactly that...
I guess what I need is a public-private algorithm, and that the
server has to generate a new pair of keys at every connect...
A friend told me about blowfish, but AFAIK that is symmetric, so the key
will be easily stolen anyway... (the client for this project is public)
Yeah, i think I need an assymetric...
>--
>stanislav shalunov | Speaking only for myself.
Thanks!
--
Daniel Åkerud
Programvaruteknik, MAH
Email: [EMAIL PROTECTED]
Homepage: http://zilch.pvt.te.mah.se
------------------------------
From: [EMAIL PROTECTED] (Daniel =?iso-8859-1?Q?=C5kerud?=)
Subject: Re: Destructive crypting
Date: 14 May 2000 10:03:20 GMT
In article <8fkkh7$men$[EMAIL PROTECTED]>, Tom St Denis wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Daniel =?iso-8859-1?Q?=C5kerud?=) wrote:
>>
>> Hi ppl,
>>
>> I need to know of a good (worldwide accepted) one-way crypt algorithm
>(like
>> the linux crypt()) that you can use in commercial applications. (Yes,
>i am
>> willing to pay a license, if it doesn't cost _too_ much).
>>
>> (I will use it to send a password over tcp/ip)
>>
>> Thank you all!
>
>Try the *publicly* available SHA-1 one-way hash function.
>
>Tom
>
I'll look into that, thank you!
--
Daniel Åkerud
Programvaruteknik, MAH
Email: [EMAIL PROTECTED]
Homepage: http://zilch.pvt.te.mah.se
------------------------------
From: [EMAIL PROTECTED] (Daniel =?iso-8859-1?Q?=C5kerud?=)
Subject: Re: Destructive crypting
Date: 14 May 2000 10:06:27 GMT
>
>Problem with what you propose is that anyone can capture the hashed
>password, and use that to impersonate the user. (AKA a replay attack)
>So it is no more secure than sending password in clear text.
Hum, yeah I c that no...
>To be secure, you need some kind of challenge-response which is
>session specific.
Ok... new key everytime, I guess...
>In simple terms, one approach is for the server to send a randomly
>selected string of bytes as a session ID. The server one way hashes
>the client password (from its passord register) with the session ID,
>and the client also one way hashes password with the session ID and
>sends the result to the server. The server compares the hashed output
>from the client with its local result, and if they are identical, it
>knows client must have been hashed it with the correct password.
>Client is authenticated (ie logged on) and session ID is deleted.
Is there a one-way hash algorithm that takes an arbitrary key as a parameter?
>Variation on this approach is required for user to change password.
I have diffuculties following that, sorry...
>Might be easiest to read up on Password Authentication Protocol and
>Chalenge Handshake Authentication Protocol as used over PPP on the
>'net.
I certainly will do that...
Thank you!!
>>
>>Hi ppl,
>>
>>I need to know of a good (worldwide accepted) one-way crypt algorithm (like
>>the linux crypt()) that you can use in commercial applications. (Yes, i am
>>willing to pay a license, if it doesn't cost _too_ much).
>>
>>(I will use it to send a password over tcp/ip)
>>
>>Thank you all!
>>
>>--
>>
>>
>>
>>Daniel Åkerud
>>Programvaruteknik, MAH
>>Email: [EMAIL PROTECTED]
>>Homepage: http://zilch.pvt.te.mah.se
>>
>>
>>
>>
>
--
Daniel Åkerud
Programvaruteknik, MAH
Email: [EMAIL PROTECTED]
Homepage: http://zilch.pvt.te.mah.se
------------------------------
From: [EMAIL PROTECTED] (David Formosa (aka ? the Platypus))
Subject: Re: security
Date: 14 May 2000 11:24:00 GMT
Reply-To: dformosa@[202.7.69.25]
On Sat, 13 May 2000 17:41:17 GMT, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>There seems to be two products. PGP and Blowfish. Can anybody tell me
>the difference between the two, which oneprovides more security as far
>as some one being able to break the code and read my stuff, I mean real
>smart people.
Blowfish is a block cypher, it has a good reputation. PGP is a crytosystem
it has also got a good reputation. There not realy compartatable as
each proforms a diffrent role.
PGP makes use of diffrent cyphers.
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Interested in drawing platypie for money? Email me.
Crack my Hash win$200 http://dformosa.zeta.org.au/~dformosa/PlatyMAC.txt
------------------------------
From: [EMAIL PROTECTED] (John Bailey)
Subject: Encryption of graphics by transposition
Date: Sun, 14 May 2000 11:54:05 GMT
Are the usual encryption techniques, eg pgp, feistel ciphers, DES, etc
really suitable for encrypting graphics, eg gif files, pgp files, etc?
A more straightforward approach than using these substitution based
ciphers would be remapping the location of pixels within the image,
using any of several techniques which guarantee one to one mapping
consistency.
An example of raster transposition can be seen at
http://www.frontiernet.net/~jmb184/interests/fractals/Rasterless/
Perhaps the answer is as simple as the possibility that once a strong
encryption process has been used for pixels value, there is no point
in using raster transposition as well.
My questions:
1) Are graphics encrypted with conventional encryption vulnerable to
attacks different from (and possibly easier than) text encrypted with
the same techniques?
2) If raster location transposition was used would graphic encryption
be stronger?
What do you think?
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
******************************
