Cryptography-Digest Digest #965, Volume #10 Mon, 24 Jan 00 09:13:01 EST
Contents:
Re: RSA survey ([EMAIL PROTECTED])
Re: from DEAL to ZEAL (Francois Grieu)
Re: The Code Book Challenge ("Michael Darling")
Re: MIRDEK: more fun with playing cards. (Paul Crowley)
Re: MIRDEK: more fun with playing cards. (Paul Crowley)
Re: MIRDEK: more fun with playing cards. (Paul Crowley)
Re: "Trusted" CA - Oxymoron? ("Auke ten Brink-Suyker")
PGP background info (Raymond Hermans)
newbie question: symmetric versus asymmetric ("dee")
Re: MIRDEK: more fun with playing cards. (Rex Stewart)
Re: From DEAL to ZEAL (Lars Ramkilde Knudsen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RSA survey
Date: Mon, 24 Jan 2000 11:23:09 GMT
On Mon, 17 Jan 2000 17:48:48 GMT, Tom St Denis <[EMAIL PROTECTED]>
wrote:
>Just a quick survey... What size of RSA key would you feel safe with
>for your crypto needs?
>
In terms of maths, I can see no need for >1024. But in terms of
accountacy (or maybe its economics?), while the marginal benefit of
>1024 may be exceedingly small, the marginal cost of >1024 is also
close to negligible. So if it's as easy to write and as easy to use a
crypto app with 4096, why not use 4096? Who loses by it? Does it use
more fossil fuel, generate more pollution, reduce my discretionary
spending power, corrupt kids, lead to premature hair loss...? So what
the hell, write it with 4096. It's not like most > pentium 200
processors haven't got the CPU cycles to spare (to run the app at
4096). Not everything in life has to be mathematically justified, nor
when it comes to bits must we use only what is absolutely necessary,
(unlike some other things, eh?).
Am I making myself clear, here? ;-)
------------------------------
From: [EMAIL PROTECTED] (Francois Grieu)
Subject: Re: from DEAL to ZEAL
Date: Mon, 24 Jan 2000 12:47:38 +0100
In article <86cst9$mr3$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
> One property which DEAL has, but ZEAL apparently does not,
> is symmetry of encryption and decryption.
Agreed, there is a minor difference in this area.
With DEAL, decryption can be expressed as
- reverse the ciphertext halves
- encipher with reversed round keys
- reverse the plaintext halves
With ZEAL, one must to add: and use DES decryption instead
of DES encryption.
Thus one has to assume DES encrypt and DES decrypt have the
same cryptographic strength to show ZEAL encryption and ZEAL
decryption are of equivalent strength.
Pictorially, the ZEAL encipher function is :
------- -------
| Pl | | Pr |
------- -------
| |
/-------\ |
RK1 --> ENC | /---\
\-------/ /-->--|XOR|
| / \---/
*---->--/ |
| /-------\
/---\ | ENC <-- RK2
|XOR|--<--\ \-------/
\---/ \ |
| \--<----*
/-------\ |
RK3 --> ENC | /---\
\-------/ /-->--|XOR|
| / \---/
*---->--/ |
| /-------\
/---\ | ENC <-- RK4
|XOR|--<--\ \-------/
\---/ \ |
| \--<----*
/-------\ |
RK5 --> ENC | /---\
\-------/ /-->--|XOR|
| / \---/
*---->--/ |
| /-------\
| | ENC <-- RK6
| \-------/
| |
------- -------
| Cl | | Cr |
------- -------
where ENC is the DES encrypt primitive,
and the decipher function is:
------- -------
| Cl | | Cr |
------- -------
| |
| /-------\
/---\ | DEC <-- RK6
|XOR|--<--\ \-------/
\---/ \ |
| \--<----*
/-------\ |
RK5 --> DEC | /---\
\-------/ /-->--|XOR|
| / \---/
*---->--/ |
| /-------\
/---\ | DEC <-- RK4
|XOR|--<--\ \-------/
\---/ \ |
| \--<----*
/-------\ |
RK3 --> DEC | /---\
\-------/ /-->--|XOR|
| / \---/
*---->--/ |
| /-------\
/---\ | DEC <-- RK2
|XOR|--<--\ \-------/
\---/ \ |
| \--<----*
/-------\ |
RK1 --> DEC | /---\
\-------/ /-->--|XOR|
| / \---/
*---->--/ |
| |
------- -------
| Pl | | Pr |
------- -------
where DEC is the DES decrypt primitive.
Francois Grieu
------------------------------
From: "Michael Darling" <[EMAIL PROTECTED]>
Subject: Re: The Code Book Challenge
Date: Mon, 24 Jan 2000 10:53:51 -0000
The CipherChallenge web site has the files in it's files section. It also
has an ongoing discussion about the
ciphers.
http://www.onelist.com/community/CipherChallenge
Regards,
Mike.
G. R. Bricker <[EMAIL PROTECTED]> wrote in message
news:01bf6635$62537640$5806ebd0@default...
> Has anyone typed these examples, especially the later ones? I could solve
> the first few examples with a whiskey in one hand and a pen in the other.
> However, when I started looking ahead to the later examples, I began to
> despair. If anyone has already sweated on a keyboard and typed these out,
> or, better yet, scanned and ocr'ed them, I would GREATLY appreciate having
> the examples posted. Perhaps a web site has already done this.
>
> Also, I have begun to toy with programming some simple frequency analysis
> programs. For instance, a program to scan a message and generate a list of
> the characters used in decreasing order. Ditto for words. Ditto for common
> pairings of characters. As I began tinkering with writing the program, I
> realized that certainly somebody else has already done this. Why reinvent
> the wheel? Anyone know where I can find such elementary tools?
>
> Thanx, George
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: 24 Jan 2000 08:17:50 -0000
"r.e.s." <[EMAIL PROTECTED]> writes:
> "Rex Stewart" <[EMAIL PROTECTED]> wrote ...
> [...]
> : On output feedback cyphers based on ARC4 variants (like
> : Solitaire) insulating the state information (and therefore the key)
> : from the output seems fairly straightforward, and in fact Solitaire
> : seems to have two layers of such insulation. The downside of
> : course is the requirement to use a new key for each message.
> [...]
>
> But it's a "downside" required for any stream cipher, and hence
> applies to all of the card ciphers mentioned in this thread.
It's not a downside that necessarily applies to randomised stream
ciphers where the randomiser is sent along with the message; this is
true of Mirdek, and we've heard some ideas about how that could be
done for ARC4-52 and ARC4-Rubin (the CRT-based variant).
> IMO, I don't think it's accurate to describe Solitaire as an
> "ARC4 variant", although it may have been influenced by ARC4.
Well, perhaps "ARC4 inspired" would be fairer.
> (As I posted before, I'm actually interested in the whole class
> of what we might call ARC4-M variants -- where M is the length
> of the state vector -- whether implemented by cards or computer.
> The lack of response to those earlier postings suggests that
> this may be an unexplored area.)
I know of two academic papers covering RC4 - Bob Jenkins's and Jovan
Golic's - and both discuss such variants where M is a power of two.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: 24 Jan 2000 08:22:26 -0000
"r.e.s." <[EMAIL PROTECTED]> writes:
> An IV that accompanies the ciphertext must actually be used to produce
> a new *key* each time, so the procedure you describe would not be secure.
> Just putting some junk at the start of the plaintext won't do. Have I
> misread your meaning here?
I think he's talking about Mirdek, which uses plaintext feedback so
the state depends on what the plaintext was. Incidentally this is
entirely for speed and convenience reasons - I'd prefer to design a
pure OFB cipher which is easier to analyse - but it does have its
advantages.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: 24 Jan 2000 08:40:51 -0000
Ouch! Halfway through responding this, I found a fatal flaw in
Mirdek's resistance to a chosen plaintext attack. Back to the drawing
board...
Rex Stewart <[EMAIL PROTECTED]> writes:
> First is that, because I haven't done much with card deck cyphers
> in a while I am rusty, and it appears to require about 15 hours
> to get proficient. This is an important fact to convey to anyone
> planning to use these cyphers in a "real world" situation. The
> first several hours of this will be spent getting their mind used to
> seeing the letters of the alphabet on the red and black cards and
> learning the rules of the encryption system. You can't just agree
> on a system and run off to a hostile area and expect to do this
> cold turkey. Also, this means if they have trouble at first they
> should not give up too easily.
My flatmates have learned it, so it doesn't seem to require too much
obsessiveness, but getting good enough to encrypt a message accurately
seems to be difficult. I have seriously contemplated the possibility
of programs that try and guess various mistakes you might have made in
an effort to generate readable plaintext from ciphertext badly
generated.
> I was first bothered by the open transmission of the IV in
> the message, but on closer observation, swapping the
> decks between keying and mixing seems to effectively
> hide this information by reordering the IV based on the
> key. This cypher adds entropy to the state information in
> much the same way as Terry Ritter's Dynamic Substitution,
> and that could be a problem, although the simultaneous
> adding of entropy from the right hand deck should provide
> enough confusion (it adds 3.5 bits entropy each round, the
> plain text adds 1.3 bits) to preclude recovery of significant
> state information in the case of a known plaintext attack
I'm not sure what your entropy calculations mean. The point about the
count cut is that if you know nothing about the right pile, then you
know nothing about what count cut is coming up and so even if you know
the next plaintext character every ciphertext character is equally
probable.
If you knew the state of the left pile and the plaintext, you'd be
able to infer each right hand character as it came up, and so you'd
have more information about each subsequent character until the last
one was determined with certainty as the one that hadn't come up yet.
> (I am not so sure about a chosen plaintext attack).
I strongly suspect that a chosen plaintext attack would choose the
plaintext "AAAAA...." since that makes least use of the state of the
left deck.
Oh bugger. If you guess where this letter appears in the left pile,
then you can infer the state of the right deck within 25 characters,
and thus get the state of both decks in 50. If you're using Mirdek -
don't encrypt the sequence "A" x 50 :-)
Redesign time, I think.
> The 26 mixing steps themselves seemed at first to be
> aimed at insulating the key from the state information,
> but because the IV is sent in the clear this is not the case
> and in fact Paul Crowley, the author, clearly warns it is not
> the case. These steps appear aimed at using the key
> information to hide the IV.
These steps are meant to ensure that both decks depend strongly on the
key, if that's what you mean.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: "Auke ten Brink-Suyker" <[EMAIL PROTECTED]>
Crossposted-To:
alt.privacy,alt.security.pgp,comp.security.pgp,comp.security.pgp.discuss
Subject: Re: "Trusted" CA - Oxymoron?
Date: Mon, 24 Jan 2000 14:10:35 +0100
Take a look at www.regedoc.com
Jim Bennett <[EMAIL PROTECTED]> wrote in message
news:6ENi4.12674$[EMAIL PROTECTED]...
> I have been reviewing the Certification Practice Statements of various
> issuers of X.509 digital certificates for S/Mime email. I have been trying
> to find one that really tries to verify the identity of the certificate
> applicant and will do it for the general public. I haven't been too
thrilled
> with what I found.
>
> Why do I care? If you are going to use a personal digital certificate for
> signing an email that has significant legal implications, like a request
to
> withdraw $100,000 from your bank and have the funds wired somewhere else,
> you sure as hell want to make sure the person who has signed the message
is
> really the person he says he is.
>
> Now let's see how various vendors have attacked the problem.
>
> VERISIGN (www.verisign.com)- The best you can get from them is a
requirement
> that you respond to a challenge email sent to the email address you have
> asserted is yours. Well, whoopee. Anyone with access to your POP inbox can
> assert they are you. Value: minimal.
>
> THAWTE (www.thawte.com)- Your identity must be vouched for by a group of
> people whom Thawte has determined are trustworthy. How does Thawte
determine
> this? If you have had your identity vouched for a selected number of times
> by different people, you are considered capable of vouching for other
> people's identity. Better than Verisign, but not much. A group of several
> co-conspirators could vouch for false identities for each other fairly
> easily. Value: still not good enough for a high value transaction.
>
> USERTRUST (www.usertrust.com) - Better. These guys will do a background
> check on you to try to confirm your identity claims, and will arrange for
> you to buy a fidelity bond to cover people who rely on your certificate.
But
> they are currently only doing this for "contracted projects", which to me
> sounds like big jobs.
>
> PGP - You have to trust the key signers, but if you are dealing with a
> stranger, you are unlikely to know any of the key signers. Value: usually
> zero, occasionally good.
>
> Does anyone know of a CA who will do what UserTrust claims to do, but on
an
> individual basis for the general public?
>
> Thanks,
>
> Jim Bennett
> Offshore Asset Protection Lawyer
> http://www.jim-bennett.com
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> PGP public key at http://www.jim-bennett.com/about/pgp.htm
>
>
------------------------------
From: Raymond Hermans <[EMAIL PROTECTED]>
Subject: PGP background info
Date: Mon, 24 Jan 2000 14:25:04 +0100
Reply-To: [EMAIL PROTECTED]
Where can I find background info concerning PGP (version 5i) as compared
to other encryption software.
Also, what's the recommended read for a starter in crypto.
Thanks,
Raymond
------------------------------
From: "dee" <[EMAIL PROTECTED]>
Subject: newbie question: symmetric versus asymmetric
Date: Mon, 24 Jan 2000 13:36:03 -0000
What essential differences between asymmetric key and symmetric
key crypto-protocols, including tamper evident hardware, when is
it neccessary to support revocation of stolen keys?
------------------------------
From: Rex Stewart <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Mon, 24 Jan 2000 13:36:49 GMT
I think you may misunderstand the operation of MirDek. I am guessing -
I don't know how much time you spent looking at its spec, which changed
somewhat in the middle of this month. I had to actually work through a
few dozen cycles to get everything straight in my head.
Yes I know Mr. Ritter's definitions, and "in general" (his own words)
they are correct. An OFB stream cypher produces a keystream completely
independent of the plaintext being encyphered, and most CFB stream
cyphers have a specific quantity of cyphertext used in their
transformation function. If a single bit is changed in the plaintext
of a OFB stream cypher, a single bit is changed in the cypher text (or
a small amount, depending on the design of the mixing function). In
most CFB steam cyphers a single bit change will change a specific
amount of cypher text in general equal to the amount of cyphertext used
in their transformation function.
MirDek is somewhat different. Its internal state depends on not only
the key and IV, but on ALL previous encyphered text. Hence a one bit
change in the input stream will change all future outputs. This means
it can be used to encypher different texts with the same key - as long
as the opponent cannot mount a known plaintext attack from the first
encyphered bytes.
The downside to this cypher design is usually a vulnerability to a
chosen plaintext attack. In this case, I could see how an adaptive
chosen plaintext attack could be mounted against it *in theory* -
forcing the output to reveal the count cuts driven by the right deck,
which would in turn would become the left deck and continuing the
process until that deck is compromised as well. This would require
tricking the user into encrypting repeatedly with the same key and IV
and as such I don't see how it could be mounted in real life. I believe
the original version of Sapphire by Michael P Johnson fell victim to
such an attack, and indeed this cypher is a distant cousin of
Sapphire.
As to your previous comments, BTW, I concede.
Calling Solitaire an "ARC4 variant" was incorrect.
Another note, I intend to try ARC4-m again, because I think it would be
advantageous to have both card deck ciphers and Cipher Sabre working
from a common root design.
--
Rex Stewart
PGP Print 9526288F3D0C292D 783D3AB640C2416A
In article <86grsv$asl$[EMAIL PROTECTED]>,
"r.e.s." <[EMAIL PROTECTED]> wrote:
> "Rex Stewart" <[EMAIL PROTECTED]> wrote ...
> : It is a downside for any OFB stream cypher, but for cyphers that add
> : either the plaintext or the cyphertext to the state entropy, simply
> : starting the message with a few randomly chosen letters is
sufficient.
>
> The need for an IV or message key seems to apply to any stream cipher,
> OFB or otherwise. It's actually part of what I had in mind, and has
the
> "downside" of increasing the message length.
>
> http://www.io.com/~ritter/GLOSSARY.HTM#StreamCipher
> has a brief discussion:
>
> "In general, all stream cipher designs must use a message key to
assure
> that the cipher is keyed with a random value for every new ciphering."
>
> An IV (message key) seems especially important if passphrases are used
> with any of the card-ciphers mentioned in this thread, for just that
> reason.
>
> : In a cypher like Mirdek, the users could aggree on an arrangement
for
> : both the right and left decks ahead of time, and simply encrypt each
> : new message with a few random characters. As long as they never
begin
> : with the same series, and as long as the series was truely random
this
> : would be a safe plan. And in fact, they would not have to send
those
> : characters in the clear. Each message would simply decrypt with a
few
> : letters of garbage at the beginning.
>
> An IV that accompanies the ciphertext must actually be used to produce
> a new *key* each time, so the procedure you describe would not be
secure.
> Just putting some junk at the start of the plaintext won't do. Have I
> misread your meaning here?
>
> --
> r.e.s. [EMAIL PROTECTED]
>
> : --
> : Rex Stewart
> : PGP Print 9526288F3D0C292D 783D3AB640C2416A
> :
> : In article <86g63d$72l$[EMAIL PROTECTED]>,
> : "r.e.s." <[EMAIL PROTECTED]> wrote:
> : > "Rex Stewart" <[EMAIL PROTECTED]> wrote ...
> : > [...]
> : > : On output feedback cyphers based on ARC4 variants (like
> : > : Solitaire) insulating the state information (and therefore the
key)
> : > : from the output seems fairly straightforward, and in fact
Solitaire
> : > : seems to have two layers of such insulation. The downside of
> : > : course is the requirement to use a new key for each message.
> : > [...]
> : >
> : > But it's a "downside" required for any stream cipher, and hence
> : > applies to all of the card ciphers mentioned in this thread.
> :
> [...]
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Lars Ramkilde Knudsen <[EMAIL PROTECTED]>
Subject: Re: From DEAL to ZEAL
Date: Mon, 24 Jan 2000 15:09:00 +0100
Francois,
First of all, the best known attack on DEAL in terms of total speed is
(still) my attack from the DEAL-documentation (also appears in the
reference you give). Lucks attacks are variants of my attack, they use
more time, but less texts. None of these attacks are likely to be a
problem for the next 30 years (or much more), so if these attacks stay the
best on DEAL you should not worry.
As for your construction: you got your decryption figure wrong. Other
than that, your (correct) decryption is actually equal to encryption in
Matsui's MISTY-structure, see FSE3 and FSE4.
I looked at it briefly and see an attack with complexities comparable
to my attack on DEAL (maybe even slightly better). I would not be
surprised if even better attacks exist, since the MISTY-structure has been
shown to be "one round weaker" than the Feistel construction in certain
attacks.
/Lars
On Sat, 22 Jan 2000, Francois Grieu wrote:
> [ I posted this on sci.crypt.research, an thought/hoped you
> might be interested - thanks for your reading time ]
>
>
> Lately, I have been looking at DEAL, a former AES candidate
> <http://www.ii.uib.no/~larsr/papers/deal.pdf>
> Lars R Knudsen's idea of constructing a 128 bit block cipher from
> a number of DES operations is attractive in Smart Cards, where DES
> is often a hardware primitive.
>
> But Stefan Lucks found attacks on DEAL in "On the security of the
> 128-bit block cipher DEAL," Fast Software Encryption Workshop,
> March 24-26, 1999, pp 60-69.
> <http://th.informatik.uni-mannheim.de/People/Lucks/papers.html>
>
> I wonder if more security could be obtained using, instead of
> DEAL's Feistel network, a structure like
>
> ------- -------
> | Pl | | Pr |
> ------- -------
> | |
> /-------\ |
> RK1 --> ENC | /---\
> \-------/ /-->--|XOR|
> | / \---/
> *---->--/ |
> | /-------\
> /---\ | ENC <-- RK2
> |XOR|--<--\ \-------/
> \---/ \ |
> | \--<----*
> /-------\ |
> RK3 --> ENC | /---\
> \-------/ /-->--|XOR|
> | / \---/
> *---->--/ |
> | /-------\
> /---\ | ENC <-- RK4
> |XOR|--<--\ \-------/
> \---/ \ |
> | \--<----*
> /-------\ |
> RK5 --> ENC | /---\
> \-------/ /-->--|XOR|
> | / \---/
> *---->--/ |
> | /-------\
> | | ENC <-- RK6
> | \-------/
> | |
> ------- -------
> | Pl | | Pr |
> ------- -------
>
> This cipher, which I call 6 round ZEAL, is clearly reversible.
> It uses as much DES operations as 6 round DEAL. I conjecture
> it could be safer, because each round modifies both sides.
> I fail to modify Stefan Lucks's attacks to ZEAL's structure.
>
> Any comment, idea, of better pointer to literature on this
> structure would be appreciated.
>
> Francois Grieu
>
>
>
------------------------------
** 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
******************************
