Cryptography-Digest Digest #163, Volume #12 Wed, 5 Jul 00 09:13:01 EDT
Contents:
Re: TC5 Completed Paper (Runu Knips)
Re: DES Analytic Crack (Mok-Kong Shen)
Re: AONT (Mok-Kong Shen)
Re: RC4 question ("Joseph Ashwood")
Re: AONT (Benjamin Goldberg)
Re: Diffie Hellman Primes : Speed Tradeoff Q (Mark Wooding)
Re: Blowfish for signatures? (Mark Wooding)
Re: Hash and Entropy (Helger Lipmaa)
Re: AES: It's been pretty quiet for some time... (Helger Lipmaa)
Re: cray and time needed to attack (Bob Silverman)
Re: AES: It's been pretty quiet for some time... (John Savard)
Re: AES: It's been pretty quiet for some time... (Mark Wooding)
Difference between A5/1 and A5/2 (Klaus Schmeh)
Re: Java & Win32 (Mark Wooding)
Re: Public-domain Blowfish (Future Beacon)
Re: Help programming ("Hans Husman")
----------------------------------------------------------------------------
Date: Wed, 05 Jul 2000 09:25:37 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: TC5 Completed Paper
"David A. Wagner" wrote:
> TC5 is very pretty in its simplicity, but alas, it can be distinguished
> from random with 2^33 chosen plaintexts.
>
> TC5 is a four-round Feistel with a bijective round function, and there
> are generic attacks on such constructions known in the literature.
Okay.
> Here is one. Consider the encryption of a plaintext (L,R). Let X
> denote the input to the F-function in the third round, and Y=F(X) the
> output. Then we can recover Y xor F(R) from the plaintext
> and its corresponding ciphertext by just xor-ing appropriate quantities.
I didn't understood this part....
In the following, K0 to K3 are the 4 128 bit parts of the key.
L variable and known
R fixed and known
L' := F(R, K0) xor L
R' := F(L', K1) xor R
= F(F(R, K0) xor L, K1) xor R
L'' := F(R', K2) xor L'
= F(F(F(R, K0) xor L, K1) xor R, K2) xor (F(R, K0) xor L)
R'' := F(L'', K3) xor R'
= F(F(F(F(R, K0) xor L, K1) xor R, K2) xor (F(R, K0) xor L), K3)
xor F(F(R, K0) xor L, K1) xor R)
We have (L, R) and (L'', R''). Now your X, Y are defined as
X := R' = F(F(R, K0) xor L, K1) xor R
Y := F(R', K2) = F(F(F(R, K0) xor L, K1) xor R, K1)
Now how may one recover that "F(R', K2) xor F(R, K0)" ???
..... OOOPS. Right now I wrote this I've seen it:
L'' xor L = F(R', K2) xor F(R, K0)
No more question 8-)
Okay.
> Consider 2^33 chosen plaintexts of the form (L_i,R), where R is fixed
> and L_i varies over 2^33 values. Let c = F(R); c is unknown but fixed.
> Then X_i = R xor F(L_i xor c) is a bijective function of L_i, and hence
> all the X_i's are distinct. Consequently, all the Y_i's should be
> distinct if we're using TC5, since the F-function is bijective.
Okay.
> Next we recover Y_i xor c from the plaintexts and their encryptions.
> This allows us to verify whether all the Y_i's are distinct. For the
> cipher TC5, the Y_i's will all be distinct, guaranteed. For an ideal
> cipher (a random permutation), the inferred Y_i values will be distributed
> like 2^33 independently chosen 64-bit values, so by the birthday paradox,
> with good probability there will be collision between the suggested Y_i's
> if we've got a cipher on our hands.
Okay.
> This lets us distinguish TC5 from an ideal cipher with 2^33 chosen texts.
>
> As a possible fix, it appears that using 8 rounds at every stage instead
> of 4 provides a more than adequate defense against this attack.
And slows the thing even more down ... (6 rounds would be enough,
don't they ?)
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: DES Analytic Crack
Date: Wed, 05 Jul 2000 09:41:14 +0200
"Douglas A. Gwyn" wrote:
> Mok-Kong Shen wrote:
> > Do you know any literature about obtaining and solving the set of
> > equations for DES? Could you give any reference or are you merely
> > postulating on a miscalculation? Thanks.
>
> As previously reported here, many years ago a colleague constructed
> the complete, explicit set of DES encipherment equations and printed
> them on a line printer, resulting in output just a few inches thick.
> That much data can easily be held in RAM on today's computers.
It would be interesting to know in which form these equations are,
i.e. whether these are a set of equations that can be solved by
simple methods of the genre of Gaussian elimination or are they in
some more involved and hence more compact form (in math one
can often have different formulations and thus different sizes of
description). Could you answer that question or ask your colleague
to do that? For that might eventually encourage analytical works
being done on other block ciphers, e.g. AES. If the set of such
equations is not too large and the solution method is straightforward,
then a solution could be within reach.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: AONT
Date: Wed, 05 Jul 2000 09:41:38 +0200
Benjamin Goldberg wrote:
> Start with a hash function H, which outputs N bits.
> Partition the file into M N-bit blocks [it's ok if the last block is
> short, but not-ok if the file is less-than one block]
>
> To transform:
> for i = 1 to M
> // hash of all the data before and after block i
> Z = H( data[1..(i-1)], data[(i+1)..M] )
> data[i] = data[i] XOR Z
> end for
> To detransform:
> for i = M to 1
> // hash of all the data before and after block i
> Z = H( data[1..(i-1)], data[(i+1)..M] )
> data[i] = data[i] XOR Z
> end for
I don't yet see why the second process is the inverse of the first.
The elements of the array data are dynamically successivly overwritten
by new values in the first process, aren't they? Further, you don't
specify
H. Can it be any hash function? Can you illustrate with an explicit
example
with, say, 3 or 4 blocks?
M. K. Shen
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: RC4 question
Date: Wed, 5 Jul 2000 00:33:27 -0700
I didn't particularly mean to make it interoperate with
implementations of CipherSaber, but instead to make use of
the knowledge gained through the experiment, and add to it
using my own thoughts, and potentially the thoughts of
others.
Joe
"Guy Macon" <[EMAIL PROTECTED]> wrote in message
news:8ju3vn$[EMAIL PROTECTED]...
> Joseph Ashwood wrote:
>
> >Unfortunately, doing that would open some avenues for a
> >chosen-plaintext attack, by giving an attacker the
ability
> >to influence the likelihood of each output value. I would
> >recommend against it, but the CipherSabre idea presented
by
> >someone else remains quite good. Oh and don't forget to
> >prime the pRNG by first removing several values from the
> >beginning (512 is certainly sufficient).
>
> Doing that would malke the resulting program incompatable
with
> ciphersaber [ http://www.ciphersaber.gurus.com ], and is
not
> necessary, as ciphersaber is considered strong without
such
> modification.
>
> I think that adding a random number of random printable
ASCII
> characters at the start and end of your plaintext has
merit as
> an improvement of ciphersaber, but the benefit, if any is
very,
> very small.
>
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: AONT
Date: Wed, 05 Jul 2000 09:04:25 GMT
Mok-Kong Shen wrote:
>
> Benjamin Goldberg wrote:
>
> > Start with a hash function H, which outputs N bits.
> > Partition the file into M N-bit blocks [it's ok if the last block is
> > short, but not-ok if the file is less-than one block]
> >
> > To transform:
> > for i = 1 to M
> > // hash of all the data before and after block i
> > Z = H( data[1..(i-1)], data[(i+1)..M] )
> > data[i] = data[i] XOR Z
> > end for
> > To detransform:
> > for i = M to 1
> > // hash of all the data before and after block i
> > Z = H( data[1..(i-1)], data[(i+1)..M] )
> > data[i] = data[i] XOR Z
> > end for
>
> I don't yet see why the second process is the inverse of the first.
> The elements of the array data are dynamically successivly overwritten
> by new values in the first process, aren't they? Further, you don't
> specify H. Can it be any hash function? Can you illustrate with an
> explicit example with, say, 3 or 4 blocks?
H can be any secure hash function: I haven't chosen to specify it.
You can use SHA1 or MD5 or pretty much anything you want.
As an example,
data-o[1..4] is the original data
data-t[1..4] is the transformed data
Transform:
data-t[1] = data-o[1] XOR H( data-o[2..4] )
data-t[2] = data-o[2] XOR H( data-t[1], data-o[3..4] )
data-t[3] = data-o[3] XOR H( data-t[1..2], data-o[4] )
data-t[4] = data-o[4] XOR H( data-t[1..3] )
Inverse Transform:
data-o[4] = data-t[4] XOR H( data-t[1..3] )
data-o[3] = data-t[3] XOR H( data-t[1..2], data-o[4] )
data-o[2] = data-t[2] XOR H( data-t[1], data-o[3..4] )
data-o[1] = data-t[1] XOR H( data-o[2..4] )
I've changed the labeling slightly, but the algorithm is the same. I
hope that describing it like this makes it clearer.
As a memory optimization, note that in the transform, at no point after
data-t[i] is created from data-o[i], do we ever use data-o[i];
Therefor, we can store data-t[i] in the same block of memory that
data-o[i] used to be in {so we don't *really* need two arrays, except
for descriptive purposes).
The inverse transform can be similarly optimized.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Diffie Hellman Primes : Speed Tradeoff Q
Date: 5 Jul 2000 09:18:17 GMT
David Hopwood <[EMAIL PROTECTED]> wrote:
> Ideally yes, although it's worth pointing out that when p = 2q + 1 for
> q prime, there's no reason to believe that working in the whole group of
> size 2q is less secure in practice.
Firstly, working in the subgroup means that exponents are one bit
shorter, which improves efficiency to by an almost worthless amount. ;-)
Secondly, consider an active attack against Diffie-Hellman whereby the
adversary exponentiates both public values by q as they go by. i.e.,
A --> M: g^\alpha mod p
M --> B: g^{q \alpha} mod p
B --> M: g^\beta mod p
M --> A: g^{q \beta} mod p
A and B will both compute the same shared value K = g^{q \alpha beta}
mod p. They can confirm this by doing some test encryptions.
M knows that g^{q \alpha} = +/-1 (mod p). If g^{q \alpha} = 1 (mod p)
then K = 1. Otherwise, g^{q \alpha} = -1 (mod p), so K = 1 iff \beta is
even, which is iff g^{q \beta} = 1 (mod p). Otherwise K = p - 1.
Using a prime group order prevents this unpleasantness. (So does
authenticating the actual Diffie-Hellman negotation rather than the
shared secret.)
> It also makes parameter generation faster, because r can be fixed, and
> then it's only necessary to find the smaller prime q such that 2qr + 1
> is prime.
Why do we have a problem if r is composite?
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Blowfish for signatures?
Date: 5 Jul 2000 09:33:16 GMT
Thierry Nouspikel <[EMAIL PROTECTED]> wrote:
> Which makes them both extremely inconvenient. Or is there a way to a)
> hash a message to, say a 16-bit word, then b) sign this word with a key
> (and a signature) of reasonable lengths?
>
> Or am I missing something?
This: ;-) I'd have thought that my comments on using Blowfish in
a Davies-Meyer mode for hashing would have given clues about the
location of my tongue during writing.
One-time signatures aren't very useful. Use proper signature algorithms
and hash functions.
-- [mdw]
------------------------------
From: Helger Lipmaa <[EMAIL PROTECTED]>
Subject: Re: Hash and Entropy
Date: Wed, 05 Jul 2000 14:51:58 +0300
David A Molnar wrote:
> Future Beacon <[EMAIL PROTECTED]> wrote:
>
> > that confounds the order of the original numbers and possibly makes
> > a string of numbers that is longer than the original string.
>
> Let {0,1}^k be a string of k bits. Let {0,1}^* be a string of 0 or more
> bits. A hash function is a function h : {0,1}^* ---> {0,1}^k for some
> fixed k. In the case of MD5, k is 128. In the case of SHA1, k is 160.
> I'm not sure that having {0,1}^* as a domain is actually kosher, so
> to be formal we might have to do something like consider the hash
> as a family of functions, one for each such that h_j : {0,1}^j --> {0,1}^k
> but you get the idea.
> As far as I know, "hashing" just by itself means that the function outputs
> a fixed length, usually small output.
If anybody his interested, here is the formal definition of the
collision-resistant hash function families.
A CRHFF $H$ for some index set $I\subseteq \{0,1\}^*$ is a pair $(g,h)$, such
that
(1) $g$ is an expected polynomial time \emph{generation algorithm}, such that
$g(1^k)\in
\{0,1\}^k\cap I$; (2) for an index $i\in I$, $h(i,\cdot)$ is an expected
polynomial time function $h(i,\cdot):\{0,1\}^{p(|i|)}\to \{0,1\}^{|i|}$, for
some polynomial $p$, where $p(k)>k$; (3) for
all expected polynomial time algorithms $A$, the probability family
$Adv(h,k,A)$ is negligible in $k$, where
\[
Adv(h,k,A):=Pr[i<-g(1^k),(x_1,x_2)<-Adv(1^k,i):x_1\neq x_2\land
h(i,x_1)=h(i,x_2)] .
\]
> Many, many, many proofs of security treat hash functions as random
> oracles, because it leaves aside the issue of analysing the function
> directly and allows for efficient implementation. In principle,
> it might be possible to derive which relations, exactly, that these
> proofs assume is "hard" to do with the hash function. Abdalla, Bellare,
> and Rogaway actually did this in their DHAES paper -- they got rid
> of the "random oracle" assumption and replaced it with some more specific
> assumptions. The next step after that would be to create a hash function
> which provably provides what you need -- Gennaro, Halevi, and T. Rabin
> did that at Eurocrypt '98 (although there's a paper in Eurocrypt '00
> claiming to break this which I haven't seen yet).
Gennaro et al showed that their signature scheme is secure under the next two
assumptions: strong RSA assumption and division-intractability of the hash
function.
Coron and Naccache showed that their hash function can be broken in
L[\sqrt{2\log 2}/2,1/2]. Hence, to get the same security as for RSA, they
suggest to use approximately the same key length.
Helger Lipmaa
http://www.tcm.hut.fi/~helger
------------------------------
From: Helger Lipmaa <[EMAIL PROTECTED]>
Subject: Re: AES: It's been pretty quiet for some time...
Date: Wed, 05 Jul 2000 14:54:16 +0300
Bruce Schneier wrote:
> On Thu, 29 Jun 2000 15:22:31 +0000, Volker Hetzer
> <[EMAIL PROTECTED]> wrote:
>
> >Hi!
> >Does anyone know what's going on?
> >The last announcement was on may, 15.
>
> May 15th was the deadline for public comments. NIST has now retreated
> into their organization and is making a decision. They hope to have a
> final decision by Crypto--mid August--but have made no promises.
Whichever their solution is, it is going to be disputed quite loudly. There
is no general consensus amongst the cryptographers that one of the
algorithms is superior compared to others.
Only MARS seems to be a loser.
Helger Lipmaa
http://www.tcm.hut.fi/~helger
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: cray and time needed to attack
Date: Wed, 05 Jul 2000 11:24:35 GMT
In article <[EMAIL PROTECTED]>,
Jerry Coffin <[EMAIL PROTECTED]> wrote:
> In article <8jsif9$8br$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
<snip>
> Just to get an idea of the general sort of thing I'm talking about,
> consider that Micron Technology is currently building and selling
> memory at a rate of roughly $1.5 billion/quarter (according to their
> most recent quarterly statement). Given current RAM prices and
> Micron's market share, that means that if all the world's production
> of RAM were dedicated to producing memory for this project, it
> appears that it would be possible to do so within a somewhat
> reasonable period of time (i.e. a matter of months to years, not
> decades or centuries).
Not good enough. The final matrix must be solved modulo the order
of the group whereas factoring solves it mod 2.
(1) Even assuming we can scrape together enough hardware/memory,
solving
the matrix *mod 2* will be 6-7 million times harder than that for
RSA-512. RSA-512 took ~10 days on a CRAY C90. This problem does
not run well in parallel. So solving the matrix mod 2 will take
60 million days at a minimum.
(2) We must solve it mod p-1. This requires solving O(log p)
instances modulo some single precision primes then using the CRT.
Each instance will be at least several times harder than solving a
single instance mod 2.
I suggest you do the arithmetic. I also suggest you not make further
pronouncements until you study what is really involved.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: AES: It's been pretty quiet for some time...
Date: Wed, 05 Jul 2000 11:29:41 GMT
On Wed, 05 Jul 2000 14:54:16 +0300, Helger Lipmaa <[EMAIL PROTECTED]>
wrote, in part:
>Only MARS seems to be a loser.
Pity, since that's one of the ones we won't get to use unless it wins.
Of course, the same applies to RC6, I think.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: AES: It's been pretty quiet for some time...
Date: 5 Jul 2000 11:43:22 GMT
John Savard <[EMAIL PROTECTED]> wrote:
> On Wed, 05 Jul 2000 14:54:16 +0300, Helger Lipmaa <[EMAIL PROTECTED]>
> wrote, in part:
>
> >Only MARS seems to be a loser.
>
> Pity, since that's one of the ones we won't get to use unless it wins.
> Of course, the same applies to RC6, I think.
No. IBM changed policy in round 2: MARS is free for all uses. See the
round 2 MARS intellectual property statement.
-- [mdw]
------------------------------
From: Klaus Schmeh <[EMAIL PROTECTED]>
Subject: Difference between A5/1 and A5/2
Date: Wed, 05 Jul 2000 13:49:48 +0200
The A5 encryption algorithm (used for GSM cell phones) exists in the two
versions A5/1 and A5/2. A5/2 is said to be less secure.
Does anybody know what the difference between the two versions is?
Regards
Klaus Schmeh, [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Java & Win32
Date: 5 Jul 2000 12:31:20 GMT
David Thompson <[EMAIL PROTECTED]> wrote:
> If the code you're using can just sign data (rather than combining the
> hash and sign/verify) I suggest running it on some trivial values that
> can be hand-checked easily; if it includes the hash, you could use
> known test vectors for the hash, although the results will be more
> tedious to hand-check.
Here are some test vectors, which I use for ensuring that my own
implementation works. Note that the second one is the test vector
supplied in FIPS 186-1.
# --- Quick simple test ---
q = 0x84d192cd06ae59691897fa409da6198d5269325d
p = 0xc9c7feaeaedb16505389c5582df1858d0fdb3eecfe61c230d612661bef8c1bc5
g = 0x5cd41fc97d0db5322bab7d659354db2ed9f88e39d2c6fae9f29acab5a522131e
x = 0x1234
m = "An example message"
k = 0x649b1058e0fe7ee849d3cb00b8ec3053ad0793b8
s = 0x2718bf488b981992b164e664224dd00ca1ed4e1c
t = 0x5c085679fbfa9ee806781bdbd86a67dbf14df640;
# --- The FIPS-186 test vector ---
q = 0xc773218c737ec8ee993b4f2ded30f48edace915f
p = 0x8df2a494492276aa3d25759bb06869cbeac0d83afb8d0cf7cbb8324f0d7882e5
d0762fc5b7210eafc2e9adac32ab7aac49693dfbf83724c2ec0736ee31c80291
g = 0x626d027839ea0a13413163a55b4cb500299d5522956cefcb3bff10f399ce2c2e
71cb9de5fa24babf58e5b79521925c9cc42e9f6f464b088cc572af53e6d78802
x = 0x2070b3223dba372fde1c0ffc7b2e3b498b260614
m = "abc"
k = 0x358dad571462710f50e254cf1a376b2bdeaadfbf
s = 0x8bac1ab66410435cb7181f95b16ab97c92b341c0
t = 0x41e2345f1f56df2458f426d155b4ba2db6dcd8c8;
# --- 1024-bit modulus test ---
q = 0xfd367bd179b5425ef9bb1f51d7d9a916e58288f9
p = 0xdde5808744e1cd37c88667e7033694b2513a7429f035f11c0bafc4dff2b96a67
2bd0a3ca16aba2ea526df00c8571106ba4a1d83eb62605fc9274ab70bef0a111
cd070cca2d8b10edf042d6c44f863c36fabea8bb0d7340eb8c169da27a4b0ba2
713c166152a0244235093391c5f71aee8c03dcaf2335a2e4689ccb27ba365ec7
g = 0x65985e4c2d6027a8afdeb9b44cc619e1c4d46bde873e0d4b45325412a2f8365e
51245324f888704295fe8233a6666624d9a4701172dbfcab5c9643e1caab79eb
2a0c85284d1b858688b8f16804326321f53a723502a6d6ae08dcbffccf2187a7
99f6281c2478ef0faed5c5c80adeabc5ee435cff8b9ae0b603e47fb08d73b014
x = 0x23a252f60bae4907a8ed5b6203e2b1da32848cd9
m = "A message signed with a 1024-bit DSA key."
k = 0x12ccb231683a3d9c13dca6fe882349537eebfd03
s = 0x2a301061ac185440fbf595f8f7d894158b8d1897
t = 0x51aedaa73cb8d47e07281d14dda5ea8c0ddf7503;
I've used SHA1 for all of the messages. All numbers are written in
hexadecimal, most significant digit first. Large numbers have been
wrapped over several lines.
-- [mdw]
------------------------------
From: Future Beacon <[EMAIL PROTECTED]>
Subject: Re: Public-domain Blowfish
Date: Wed, 5 Jul 2000 08:59:31 -0400
On Wed, 5 Jul 2000, Runu Knips wrote:
> Future Beacon wrote:
> > "Blowfish is unpatented, and will remain so in all countries. The
> > algorithm is hereby placed in the public domain, and can be freely
> > used by anyone".
>
> Whow. Three times the same answer for something which was
> actually as clear as it can be.
>
> If the creator of the algorithm states it is free, who damned
> who can have a patent on it ? You can't patent ideas which are
> provably not your own ! And Blowfish is too simple to contain
> something which is separately patentable.
Runu,
It used to be (and I think it still is the case) that one could
patent a published idea within one year of the publication if
there was evidence that the idea had been under secret development
in accordance with patent rules. Apparently, Blowfish made it passed
the year after publication. If it was fully disclosed, it would be
in the public domain even if the inventor didn't say it should be.
I don't have recent updates of this part of patent law, I could be
mistaken, I don't practice law, disclaimer, disclaimer, disclaimer.
Be well.
Jim Trek
Future Beacon Technology
http://eznet.net/~progress
[EMAIL PROTECTED]
------------------------------
From: "Hans Husman" <[EMAIL PROTECTED]>
Subject: Re: Help programming
Date: Wed, 5 Jul 2000 15:07:41 +0200
"Jeff Moser" <[EMAIL PROTECTED]> wrote in message
news:8jtaa6$iqo$[EMAIL PROTECTED]...
> <[EMAIL PROTECTED]> wrote in message news:8jt6ss$mlg$[EMAIL PROTECTED]...
> > I have an idea for an encryption that takes one file to encrypt
> > another. So the key is the would be 3 pic files and each byte of the
> > pics would change the file to be encrypted. I have work out an
> > algorithm. And could use a lot of help to turn it into code. Is
> > their any other programs like this or am I wasting my time?
>
> Basically, it's a One Time Pad if you only use the pictures once and only
> once and therefore have new ones for each encryption. Also, only the
sender
> and the receiver can know the pictures.
>
Better to use the picture to generate a key for a block chiphers using a
a secure
hash function and a pseudo-random generator. If the picture is secret it
should
be a better alternative compared to passwords used to generate keys.
Still if
we have to keep the picture feel keept secret, so an even better
alternative would
to generate a symmetric encryption key in a more conservative way, by
using
several sources.
At the RSA conferans in Europe a couple of presentations was about the
possibility to use pictures instead of passwords. Because pictures might
be easier to remember compared to traditional passwords.
Hans Husman
[EMAIL PROTECTED]
Security Specialist
Mynta Management & IT AB
Sweden
> If any of the above is not followed.. it'll be terribly insecure.
>
> Cheers,
>
> Jeff
>
------------------------------
** 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
******************************
