Cryptography-Digest Digest #650, Volume #13 Wed, 7 Feb 01 13:13:00 EST
Contents:
Re: Questions about Diffie-Hellman ([EMAIL PROTECTED])
Re: Questions about Diffie-Hellman ([EMAIL PROTECTED])
Re: PGP 2.6.3ia-cb (now supports CAST5 and BLOWFISH) ("Sam Simpson")
relative key strength private vs public key (Steve Portly)
Re: File encryption with Rijndael ("Marcin")
Re: Encrypting Predictable Files (Richard Heathfield)
Re: Finite field/polynomial mathematics (Dido Sevilla)
Question on Randomized Blind Signature ([EMAIL PROTECTED])
Re: Affordable High-Quality Patents (Dido Sevilla)
Re: efficient coin flipping (Mok-Kong Shen)
Re: Low-tech homemade crypto keycards ("Paul Pires")
Re: Affordable High-Quality Patents ("Paul Pires")
Re: One way function for Passwords. ("Moritz Voss")
Re: relative key strength private vs public key ([EMAIL PROTECTED])
Re: relative key strength private vs public key (Tom St Denis)
Re: relative key strength private vs public key (Tom St Denis)
Re: Low-tech homemade crypto keycards (Steve Portly)
Re: Encrypting Predictable Files ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Questions about Diffie-Hellman
Date: Wed, 07 Feb 2001 16:05:42 GMT
(I don't believe this!)
If q is a generator of Zp*, then g = q**((p-1)/r) mod p is a generator
of a subgroup <g> with Ord(<g>) = r. All elements (except the identity)
of a cyclic group are generators. Consequently, for all 0 < k < r, it
is the case that g' = (q**((p-1)/r))**k = q**(k(p-1)/r) is also a
generator of <g>.
Hence, g = q**((p-1)/r) mod p is a generator of a subgroup <g> with Ord
(<g>) = r, if and only if there is an integer k and a generator s of
Zp* such that k > 0, GCD(k,r) = 1 and q = s**k mod p.
In article <95rolc$g25$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> > I.e. choose g = q**((p-1)/r) mod p, where q may be any number such
> > that GCD(q,p) = 1, and r is a large prime such that r|(p-1).
>
> Wrong, of course. All numbers 0 < q < p have GCD(q,p) = 1 since p is a
> prime. The correct condition is that q > 1 is any power of any
> generator of Zp*.
>
> Sent via Deja.com
> http://www.deja.com/
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Questions about Diffie-Hellman
Date: Wed, 07 Feb 2001 16:05:12 GMT
(I don't believe this!)
If q is a generator of Zp*, then g = q**((p-1)/r) mod p is a generator
of a subgroup <g> with Ord(<g>) = r. All elements (except the identity)
of a cyclic group are generators. Consequently, for all 0 < k < r, it
is the case that g' = (q**((p-1)/r))**k = q**(k(p-1)/r) is also a
generator of <g>.
Hence, g = q**((p-1)/r) mod p is a generator of a subgroup <g> with Ord
(<g>) = r, if and only if there is an integer k and a generator s of
Zp* such that k > 0, GCD(k,r) = 1 and q = s**k.
In article <95rolc$g25$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> > I.e. choose g = q**((p-1)/r) mod p, where q may be any number such
> > that GCD(q,p) = 1, and r is a large prime such that r|(p-1).
>
> Wrong, of course. All numbers 0 < q < p have GCD(q,p) = 1 since p is a
> prime. The correct condition is that q > 1 is any power of any
> generator of Zp*.
>
> Sent via Deja.com
> http://www.deja.com/
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP 2.6.3ia-cb (now supports CAST5 and BLOWFISH)
Date: Wed, 7 Feb 2001 16:21:08 -0000
Well, it's based on the 2.x code, and only includes OpenPGP compatible
algorithms - I'd say it's as much right to call itself PGP as the other
unofficial builds that add SHA-1 support etc.
--
Regards,
Sam
http://www.scramdisk.clara.net/
jungle <Use-Author-Address-Header@[127.1]> wrote in message
news:[EMAIL PROTECTED]...
> -----BEGIN PGP SIGNED MESSAGE-----
>
> 07 Feb 2001 in <[EMAIL PROTECTED]>
[EMAIL PROTECTED] wrote:
> > I just added another cipher to PGP 2.6.3ia - Blowfish
> > why? because it was easy :)
>
> and you are calling it PGP ?
> it is not PGP any more ...
>
> ~~~
> This PGP signature only certifies the sender and date of the message.
> It implies no approval from the administrators of nym.alias.net.
> Date: Wed Feb 7 13:50:04 2001 GMT
> From: [EMAIL PROTECTED]
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.2
>
> iQEVAwUBOoFSjU5NDhYLYPHNAQGVOwf9EASnw/N+zh8IDhFczBCRcU87Gx0og25w
> LnNDRKLAlbnHP0ER8zbSgOpCsQ7Ew6ZBaXVXsOIbuzvgqrihDWRCj4u2M9KWaDIr
> SuoNiAzBK+SSLI+wzwXki0tdEc0ZEhuhF/aWsFlOcSUQi9sWRWaDgwRs0Lenofwl
> bQolNtk3KXDnACygbpvTOcaZZaXtxKDFgdwbI/Dy+OTfi0Evy8CQgQwQJIuQnJNR
> uN+DmZfBwLkw0vbLZ+8JxlPzq437LJLbGyQQu7eHIA0q/87JW3Kstn3y/YzJBkW2
> 4InhSICCVW0JozjpeYzgqA9umjbYYwGGDJyb3r8Ute2kfBEzSLxYzw==
> =TKf1
> -----END PGP SIGNATURE-----
------------------------------
From: Steve Portly <[EMAIL PROTECTED]>
Subject: relative key strength private vs public key
Date: Wed, 07 Feb 2001 11:26:38 -0500
In cryptographic applications a symmetric key is often negotiated and
passed using a public key method. There is often some confusion
concerning relative strength of RSA public keys and smaller but more
efficient symmetric keys. As an example, I remember reading somewhere
that a 1024 bit RSA key should be treated as having an effective
strength of an ~80 bit symmetric key. In the ideal situation where one
did not have to discount the effects of hash collisions does this
correspondence continue? Specifically if we were charged with the task
of passing a symmetric key for the following key strengths, ideally what
strength public key should be used?
112 bit double DES?
168 bit Triple DES?
350 bit custom?
------------------------------
From: "Marcin" <[EMAIL PROTECTED]>
Subject: Re: File encryption with Rijndael
Date: Wed, 07 Feb 2001 16:28:08 GMT
Ok, you got me there. I meant to say that changing any byte(s) in the
stream has an extremely high probability of being detected. And
understanding of the message sent without knowledge of the key has an
extremely low probability, around 1/(2^256) assuming that one chooses a
strong enough key.
Marcin
"Jirka Klaue" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Marcin wrote:
> [snip]
> >
> > 3) Streams support frame numbers and frame message digests so if
> > you were to send the encrypted file through the internet,
> > no attack will go undetected.
> >
>
> This isn't a serious statement, is it ? *NO* attack will go undetected ?
> It's a sentence one expects in a booklet. Or do you mean (horrible) JAVA
> supports quantum-cryptography in its streams ?
>
> Jirka
------------------------------
Date: Wed, 07 Feb 2001 11:01:27 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Encrypting Predictable Files
Joseph Ashwood wrote:
>
<snip>
>
> Now to get back on topic, when you are encrypting predictable files you
> _want_ information to be added, or rather you want entropy added to obscure
> the information in the file. This information can be in the form of padding,
> cryptographic keys, IVs, etc depending on the requirements of the system.
> Just to point out a rather painful example for the strict 1-1 onto mapping
> without change of file length that certain individuals vocally support in
> spite of being continually corrected, take a known transmission of one of 2
> messages:
> "yes"
> "I'd like to discuss this in great detail with you at my earliest
> convenience, how about you call me about 8:05 AM on December 26, 2007"
>
> encrypting these using a non-padded method that retains the file length, it
> is fairly easy to distinguish the two messages. I assume you want to use
> encryption to hide what's being said.
I hope I don't count as one of those "vocal individuals". :-) I'm just
curious.
I see your point about message length being a clue to an attacker, but
it strikes me that it's trivial to defeat. If I want to send one of the
two messages you quote, and if I am concerned about "known-length"
attacks, it's pretty easy to pad the first message to the length of the
second, and /then/ encrypt, is it not?
[ Hidden agenda - my algorithm doesn't change the message length, and I
don't want to throw the algorithm away. ;-) ]
I agree that pre-encryption padding is slightly messier, but I don't see
that it's any less secure. What have I missed?
<snip>
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: Finite field/polynomial mathematics
Date: Thu, 08 Feb 2001 00:36:22 +0800
Brendan Lynskey wrote:
>
> Sorry for posting such a basic request, but does anyone out there know of a
> well-made tuorial that covers the above types of mathematics?
>
Try John B. Fraleigh: "A First Course in Abstract Algebra".
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
From: [EMAIL PROTECTED]
Subject: Question on Randomized Blind Signature
Date: Wed, 07 Feb 2001 16:36:11 GMT
Dear Subscribers...
I have a question on randomized blind signature.
Randomized blind signature was originally
proposed by David Chaum. Niels Ferguson used
randomized blind signature to build an
offline ecash system. In his paper "Single Term
Off-Line Coins" (eurocrypt93) he introduced this
signature scheme in detail. I would those who
read this paper, or familliar with randomized
blind signature, to answer following question.
It would help me greatly in my research.
n: RSA modulus of the bank
v: Bank's public exponent
g: publicly known element of larger order in Z^*_n
f(): oneway function mapping Z^*_n into Z_v
Alice first choose a_1 and r from Z^*_n
and chooses b from Z_v.
Then sends r^v a_1 g^b.
Bank selects a_2 from Z^*_n and sends a_2 to
Alice. Alice sends e=f(a_1a_2)-b.
Bank calculates following.
A' = r^v a_1 g^b a_2 g^e
and sends (A')^{1/v}. Alice removes r from the
received value.
The final signature is (ag^{f(a)})^{1/v}.
I understand what is going on. But one thing
I cannot figure out. Probably this is due to my
lack of knowlege on number theory.
Anyway here e is computed using modulo v.
Why is the purpose of using modulo v computation
in this signature. In his paper, following is the
explanation. "To make the blinding perfect".
Why does uing modulus v makes this blinding
perfect. Why modulus n or modulus phi(n)?
I know that Alice cannot calculate phi(n) or
even should not be able to know phi(n).
Anyway Help Me.
Sincerely Yours,
Sangjin Kim
[EMAIL PROTECTED]
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: Affordable High-Quality Patents
Date: Thu, 08 Feb 2001 00:39:26 +0800
Actually, most of us who live on sci.crypt take a very dim view of
patents, and feel that as applied to the computer industry, they have
done incredible harm...
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: efficient coin flipping
Date: Wed, 07 Feb 2001 17:57:06 +0100
Benjamin Goldberg wrote:
>
> [EMAIL PROTECTED] wrote:
> >
> > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > >
> > > I use dice to determine my password.
> >
> > 26+10=36, very nice! All alphanumeric values. I hadn't seen that
> > before. That implies your passwords have no capital letters or
> > ampersands or such.
> >
> > If I wanted bits, I could ignore pairs of dice that hit the top 4 of
> > the 36 states, giving me 5 bits per pair of dice thrown. The man on
> > the street would probably consider that suspicious, though. 8-sided
> > or 16-sided dice would also seem awfully peculiar.
>
> How do you know Mok's not using diceware? Roll a die a 5 times to pick
> a word from a list of 7776 words, and 10 words equals about 128 bits of
> strength. Since the words are english, more or less, they are much
> easier to remember than random letters.
>
> The diceware passphrase homepage is at http://www.diceware.com/
>
> As to the idea of non-six-sided dice (4, 8, 10, 12, 20), the might seem
> peculiar by themselves, but if you put them in a box of AD&D stuff,
> noone would think them odd. Of course, some people might consider you
> odd for having an AD&D set, but you can't please everyone :)
It's in my humble view difficult to argue about the question
whether it is better/easier or worse/difficult to remember a
short sequence of 'nonsense' characters in comparison to a
longer sequence of common English words or even a meaningful
complete sentence. I suppose that the issue depends very
much on the individual person and the needed 'entropy'
and in part also on how many passwords need be remembered
(and the frequency of change). Since my passwords are
limited to 8 characters (besides no top secrecy is at stake),
I have chosen to select within the set {a-z, 0-9}, which in
fact is well adapted to casting of (ordinary) dices. There
being in my environment no need to change these very
frequently, I personally find the task of remembering a
couple of these to be not very difficult/inconvenient.
Certainly, I am aware that other people may much prefer to
use meaninful passphrases.
M. K. Shen
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Low-tech homemade crypto keycards
Date: Wed, 7 Feb 2001 09:03:49 -0800
Ray Dillinger <[EMAIL PROTECTED]> wrote in message
news:3a5g6.1031$[EMAIL PROTECTED]...
>
> I've been reading in another thread about the work and worry of
> destroying a compromised crypto module, and it occurs to me that
> there is a nice way to create a hardware device that physically
> embodies a key, and is cheap and durable, simple to make and
> simple to destroy.
Electricians have had the means to trace the physical routing
of circuits in hidden locations for a long time. They pump a RF
signal down the wire to make it "sing" and trace it with a localized
probe. As was already pointed out, even an Ohm meter can map
this thing.
The difference between a smart card and a key card is profound.
A smart card never reveals it's secret, it proves knowledge of the
secret by demonstrating what it can do. It's the difference between
using a key to open a door in public where all things are controlled
by an adversary.
They may have put in a dummy lock that analyzes your key and
braoadcasts it. Any number of weaknesses. They might pick
your pocket, copy it and replace it.
A smart card is more like walking up to a doorman and proving you have
the key without divulging it and putting it at risk but doing it in a way that
makes the doorman confident enough to open the door and let you in.
How an electric key is an advancement over a mechanical key for
impoverished people is beyond me. They have access to brass
files and hammers now. They need wire, epoxy and the circuity
to operate the lock? Why? What does this get them for their
efforts?
Paul
>
> First, get a small chunk of cardboard, like a playing card.
>
> Next, use a small punch to create 54 holes in the left side
> and 54 holes in the right side. These holes need to be evenly
> spaced.
>
> Now, take 54 wires and strip the insulation off the ends.
>
> Poke one end of each wire through a randomly selected,
> otherwise-unoccupied hole on the left side of the card.
> Poke the other end through a randomly selected, otherwise
> unoccupied hole on the right side of the card.
>
> Now put another playing card on top of the tangle of
> insulated wires, which places them in the center of a
> cardboard sandwich.
>
> Wrap the exposed ends around the left and right edges of
> the cards and trim any excess.
>
> Now, cast this card-and-wire sandwich in an opaque epoxy
> resin, leaving contact points of the wires exposed along
> the edges.
>
> This device represents a mapping of left to right contacts
> with about 220 bits of entropy. It's simple to build a
> reader for these devices. It's simple to destroy them
> so that the key cannot be recovered. And it is possible
> to verify visually that they have been destroyed.
>
> It's not a smart card by any means; in fact, it may be the
> dumbest card ever proposed. But it stores a key nicely,
> can be built by hand or with relatively simple tools out
> of readily-available parts, and can't be read remotely or
> surreptitiously (I think). With the appropriate picture and
> frame, it could look like the sort of locket or religious
> medallion that is common in some areas, and it could have
> applications in a fair number of third-world countries
> where people who need it don't necessarily have access to
> chip fabs or lots of money for commercial hardware.
>
> Variations; the "wire web" card described here could be
> built (with various construction techniques) inside all kinds
> of ordinary things, like wallets, purses, knife handles, or
> (with some effort) even the teeth of a comb.
>
> Bear
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Affordable High-Quality Patents
Date: Wed, 7 Feb 2001 09:04:50 -0800
Dido Sevilla <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Actually, most of us who live on sci.crypt take a very dim view of
> patents, and feel that as applied to the computer industry, they have
> done incredible harm...
Nonsense.
Paul
>
> --
> Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
> ICSM-F Development Team, UP Diliman +63 (917) 4458925
> OpenPGP Key ID: 0x0E8CE481
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: "Moritz Voss" <[EMAIL PROTECTED]>
Subject: Re: One way function for Passwords.
Date: Wed, 7 Feb 2001 18:14:49 +0100
I don't fully understand yet but am thankful for your patience...
You pointed me to the stuff I need, so I won'T bother you anymore with
newbie questions!
Thanks a lot,
Moritz...
"Ichinin" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
news:95qvrk$rpl$[EMAIL PROTECTED]...
> Regards,
> Glenn
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: relative key strength private vs public key
Date: Wed, 07 Feb 2001 17:06:48 GMT
In article <[EMAIL PROTECTED]>,
Steve Portly <[EMAIL PROTECTED]> wrote:
> In cryptographic applications a symmetric key is often negotiated and
> passed using a public key method. There is often some confusion
> concerning relative strength of RSA public keys and smaller but more
> efficient symmetric keys. As an example, I remember reading somewhere
> that a 1024 bit RSA key should be treated as having an effective
> strength of an ~80 bit symmetric key. In the ideal situation where
one
> did not have to discount the effects of hash collisions does this
> correspondence continue? Specifically if we were charged with the
task
> of passing a symmetric key for the following key strengths, ideally
what
> strength public key should be used?
> 112 bit double DES?
> 168 bit Triple DES?
> 350 bit custom?
>
The facts are nobody really knows what sizes to use. If
you can use secret key nonpublic crypto that is the best.
If you most rely on public key crypto use the longest key
that does not seem to slow you down.
Or better yet send the key in 3 different public key
methods where an XOR of all three would be your private
key that way a break of RSA or DH EC would not hurt you
unless all 3 methods are weak.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: relative key strength private vs public key
Date: Wed, 07 Feb 2001 17:09:51 GMT
In article <[EMAIL PROTECTED]>,
Steve Portly <[EMAIL PROTECTED]> wrote:
> In cryptographic applications a symmetric key is often negotiated and
> passed using a public key method. There is often some confusion
> concerning relative strength of RSA public keys and smaller but more
> efficient symmetric keys. As an example, I remember reading somewhere
> that a 1024 bit RSA key should be treated as having an effective
> strength of an ~80 bit symmetric key. In the ideal situation where one
> did not have to discount the effects of hash collisions does this
> correspondence continue? Specifically if we were charged with the task
> of passing a symmetric key for the following key strengths, ideally what
> strength public key should be used?
> 112 bit double DES?
> 168 bit Triple DES?
> 350 bit custom?
Comparing lengths is truly a STUPID DUMB idea. They are apples and oranges.
Factoring and a brute force search are completely different tasks. For
example, you mention a 1024-bit PK key (RSA/DH/ECC?) is just as resistant to
brute force as a 80-bit symmetric key. However you disregard the fact that
technology to factor 1024-bit numbers doesn't exist. We can't for example
brute force a 256-bit key because there is not enough energy in the universe
to do it. etc..
I would if I were you read up on the space/time requirements of factoring
algorithms etc.
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: relative key strength private vs public key
Date: Wed, 07 Feb 2001 17:12:51 GMT
In article <95rvav$mko$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> Steve Portly <[EMAIL PROTECTED]> wrote:
> > In cryptographic applications a symmetric key is often negotiated and
> > passed using a public key method. There is often some confusion
> > concerning relative strength of RSA public keys and smaller but more
> > efficient symmetric keys. As an example, I remember reading somewhere
> > that a 1024 bit RSA key should be treated as having an effective
> > strength of an ~80 bit symmetric key. In the ideal situation where
> one
> > did not have to discount the effects of hash collisions does this
> > correspondence continue? Specifically if we were charged with the
> task
> > of passing a symmetric key for the following key strengths, ideally
> what
> > strength public key should be used?
> > 112 bit double DES?
> > 168 bit Triple DES?
> > 350 bit custom?
> >
>
> The facts are nobody really knows what sizes to use. If
> you can use secret key nonpublic crypto that is the best.
> If you most rely on public key crypto use the longest key
> that does not seem to slow you down.
Or realize that it's unlikely that RSA keys between 1024-2048 bits are not
going to be factored because the space requirements are prohibitive.
(Solving 768+ bit DH problems requires alot more space and time then
factoring so it's probably just as good).
Sure I could use a 5K-bit RSA key but that would be pointless since nobody
can factor beyond 512-bits so far (I would speculate 768-bits will fall
within two years, just a wild guess, assuming a machine with the required
memory+speed exists).
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Steve Portly <[EMAIL PROTECTED]>
Subject: Re: Low-tech homemade crypto keycards
Date: Wed, 07 Feb 2001 12:29:29 -0500
This is a neat idea for hobbyists but in a practical application given todays
technology, wouldn't it
be a lot more secure to use a very low current induction loop that only a TE device
could read? The
cost of TE readers would not be prohibitively expensive for an ATM application. Maybe
I have just been
watching too many X file episodes lately.
Paul Pires wrote:
> Ray Dillinger <[EMAIL PROTECTED]> wrote in message
>news:3a5g6.1031$[EMAIL PROTECTED]...
> >
> > I've been reading in another thread about the work and worry of
> > destroying a compromised crypto module, and it occurs to me that
> > there is a nice way to create a hardware device that physically
> > embodies a key, and is cheap and durable, simple to make and
> > simple to destroy.
>
> Electricians have had the means to trace the physical routing
> of circuits in hidden locations for a long time. They pump a RF
> signal down the wire to make it "sing" and trace it with a localized
> probe. As was already pointed out, even an Ohm meter can map
> this thing.
>
> The difference between a smart card and a key card is profound.
> A smart card never reveals it's secret, it proves knowledge of the
> secret by demonstrating what it can do. It's the difference between
> using a key to open a door in public where all things are controlled
> by an adversary.
>
> They may have put in a dummy lock that analyzes your key and
> braoadcasts it. Any number of weaknesses. They might pick
> your pocket, copy it and replace it.
>
> A smart card is more like walking up to a doorman and proving you have
> the key without divulging it and putting it at risk but doing it in a way that
> makes the doorman confident enough to open the door and let you in.
>
> How an electric key is an advancement over a mechanical key for
> impoverished people is beyond me. They have access to brass
> files and hammers now. They need wire, epoxy and the circuity
> to operate the lock? Why? What does this get them for their
> efforts?
>
> Paul
>
> >
> > First, get a small chunk of cardboard, like a playing card.
> >
> > Next, use a small punch to create 54 holes in the left side
> > and 54 holes in the right side. These holes need to be evenly
> > spaced.
> >
> > Now, take 54 wires and strip the insulation off the ends.
> >
> > Poke one end of each wire through a randomly selected,
> > otherwise-unoccupied hole on the left side of the card.
> > Poke the other end through a randomly selected, otherwise
> > unoccupied hole on the right side of the card.
> >
> > Now put another playing card on top of the tangle of
> > insulated wires, which places them in the center of a
> > cardboard sandwich.
> >
> > Wrap the exposed ends around the left and right edges of
> > the cards and trim any excess.
> >
> > Now, cast this card-and-wire sandwich in an opaque epoxy
> > resin, leaving contact points of the wires exposed along
> > the edges.
> >
> > This device represents a mapping of left to right contacts
> > with about 220 bits of entropy. It's simple to build a
> > reader for these devices. It's simple to destroy them
> > so that the key cannot be recovered. And it is possible
> > to verify visually that they have been destroyed.
> >
> > It's not a smart card by any means; in fact, it may be the
> > dumbest card ever proposed. But it stores a key nicely,
> > can be built by hand or with relatively simple tools out
> > of readily-available parts, and can't be read remotely or
> > surreptitiously (I think). With the appropriate picture and
> > frame, it could look like the sort of locket or religious
> > medallion that is common in some areas, and it could have
> > applications in a fair number of third-world countries
> > where people who need it don't necessarily have access to
> > chip fabs or lots of money for commercial hardware.
> >
> > Variations; the "wire web" card described here could be
> > built (with various construction techniques) inside all kinds
> > of ordinary things, like wallets, purses, knife handles, or
> > (with some effort) even the teeth of a comb.
> >
> > Bear
>
> -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
> http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
> -----== Over 80,000 Newsgroups - 16 Different Servers! =-----
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Encrypting Predictable Files
Date: Wed, 07 Feb 2001 17:22:22 GMT
In article <[EMAIL PROTECTED]>,
Richard Heathfield <[EMAIL PROTECTED]> wrote:
...
> I hope I don't count as one of those "vocal individuals". :-) I'm just
> curious.
>
> I see your point about message length being a clue to an attacker, but
> it strikes me that it's trivial to defeat. If I want to send one of
the
> two messages you quote, and if I am concerned about "known-length"
> attacks, it's pretty easy to pad the first message to the length of
the
> second, and /then/ encrypt, is it not?
>
> [ Hidden agenda - my algorithm doesn't change the message length, and
I
> don't want to throw the algorithm away. ;-) ]
>
> I agree that pre-encryption padding is slightly messier, but I don't
see
> that it's any less secure. What have I missed?
>
> <snip>
You may not have missed anything. Most of my disscussion
is about plain bare encryption methods. I too have a mode where
random padding is added. But feel its best to analyze the method
without padding.
One problem with variable length padding is how one adds it
to a file so that no extra information is given to an attacker.
I have a solution for that too. I call it my DSC program to
use it for padding just add the padding in front of file any
number of bytes you want. Then put your file to be encrypted.
The last data in this file would be a long pointer to where
the real file starts.
Now run DSC http://members.nbci.com/ecil/compres8.htm
this will combine the pointer to the file without adding information.
You may have trouble understand how it does this but take a look.
You can also run it through for another pass if you wish to
rotate the file before encryption.
Dave
Sent via Deja.com
http://www.deja.com/
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
