Cryptography-Digest Digest #449, Volume #14 Sat, 26 May 01 15:13:01 EDT
Contents:
Re: A generic feistel cipher with hash and gf(257) mixers (SCOTT19U.ZIP_GUY)
Re: "computationally impossible" and cryptographic hashs (Daniel Graf)
Re: A generic feistel cipher with hash and gf(257) mixers (David Wagner)
Re: A generic feistel cipher with hash and gf(257) mixers (David Wagner)
Re: Newbie question about algo ("Scott Fluhrer")
Re: A generic feistel cipher with hash and gf(257) mixers (Tom St Denis)
Re: Crypto NEWBIE, wants to create the 100% SAFE FRACTAL encoding... (Scientific
Language) ("BenZen")
Re: Essay on "The need for a look at real life crypto" (Ryan Phillips)
Re: Small (not fast) RIPEMD-160 ("Roger Schlafly")
Re: Essay on "The need for a look at real life crypto" ("Tom St Denis")
Re: Newbie question about algo (Martin Kiewitz)
Re: Hybrids (Terry Cooper)
Re: James Felling: Sorry to break your bubble (Kt)
Re: Newbie question about algo (Tom St Denis)
Re: A generic feistel cipher with hash and gf(257) mixers ("Roger Schlafly")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: A generic feistel cipher with hash and gf(257) mixers
Date: 26 May 2001 15:36:01 GMT
[EMAIL PROTECTED] (David Wagner) wrote in
<9eohhe$nf4$[EMAIL PROTECTED]>:
>Jim Steuert wrote:
>> What I am getting at, in general, though,
>>is a methodology which would take designing ciphers out of the hands
>>of the "experts" (no disrespect intended) and put it into the hands
>>of hobbyists, who could still come up with creative ideas, but based
>>on well-understood design principles.
>
>Why? Designing ciphers as a hobbyist is a Really Bad Idea, if you want to
>deploy the result in a real system: most such ciphers end up being weak.
>Read Bruce Schneier's Memo to an Amateur Cryptographer for details
>(see the Cryptograms at www.counterpane.com).
>
Actually this is another point where Wagner is really off base.
A hobbyist is not limited to many of the constrants that the so
called experts are. They seem to have forgotten Shannon whose work
is the realy basis of cryptography. I think the main reason they
reject his ideas are becasue they seem more concerned wit short
keys and methods that take a low number of computer cycles.
Fact is as computers only seem to get faster and memory only
gets cheaper. It far safer to use a large key slow cipher.
But even if your trust "modern ciphers" like AES version
of Rijndael. You can still vastly improve on what the "experts"
would use. I think with careful attension to information theory
so one does not use the underlying cpher in whys that add information
to the encryption. A hobbyist can build a much better cipher than
what the "experts" would recommend. Examle BICOM. Its full bijective
meaning no information added yet uses full Rijndael. I doubt Wagner
or Mr BS will give an honest comment about it. But you could easyly
use BICOM as the first part of a series of ciphers to build a far
more complex and secure kind of cipher.
Example use BICOM
reverse file use BICOM again different key.
This creates a fully bijective ouput file. Where any output file
is possible. And yet treats the whole plaintext as a single block.
Ask Wagner to comment on this hobbyist approach. Yes its slow
but it would be a hell of a lot more secure than a mode of AES
the "experts would recommend". The main reason they talk little
about this kind of think is becasue they truely want to keep the
hobbyiest out. So they only bring up examples where hobbyiest are
prone to make mistakes.
>I don't want to discourage you, but if you want to maximize the odds
>of making a contribution to the science of cryptography as a hobbyist,
>block cipher design is not exactly the area I'd pick.
>
Actaully this is what I love about BS responses he sends half
the message discouraging you then at end says the opposite. The
true sign of a politically correct statement.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: [EMAIL PROTECTED] (Daniel Graf)
Subject: Re: "computationally impossible" and cryptographic hashs
Date: Sat, 26 May 2001 17:41:03 GMT
On Tue, 22 May 2001 14:54:13 GMT, [EMAIL PROTECTED] (Daniel Graf) wrote:
> [Original Post Clipped]
Thanks to all that responded. I'm glad to see such kind and high
quality responses.
I should get a good beginner's book and learn more about this stuff.
Thanks again.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: A generic feistel cipher with hash and gf(257) mixers
Date: 26 May 2001 17:49:41 GMT
SCOTT19U.ZIP_GUY wrote:
>[... BICOM ...]
>Ask Wagner to comment on this hobbyist approach. Yes its slow
>but it would be a hell of a lot more secure than a mode of AES
>the "experts would recommend".
Sorry, I'm not familiar with BICOM, so I can't comment on it. Does it
come with a proof of security?
If the goal is `slow but secure', how does it compare to the GGR
tree-based scheme that I posted earlier? (I've posted the citation to
GGR several times before on this newsgroup, so I won't do it again.)
Note that the GGR scheme comes with a proof of the following statement:
Suppose AES is secure against all attacks that use four blocks of chosen
plaintext and a reasonable amount of computation. Then AES-GGR is
secure against all attacks that use a reasonable amount of computation,
even if the adversary has access to many blocks of adaptively-chosen
plaintexts and ciphertexts.
AES-GGR can be made to run pretty fast: It needs about 2 AES encryptions
per block of plaintext that you'd like to encrypt, I believe. In other
words, GGR provides very strong security at not too much performance cost.
As a consequence, if you want `slow but secure', GGR seems to be the
construction to beat.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: A generic feistel cipher with hash and gf(257) mixers
Date: 26 May 2001 17:58:53 GMT
Tom St Denis wrote:
>"David Wagner" <[EMAIL PROTECTED]> wrote:
>> If you want to maximize the odds
>> of making a contribution to the science of cryptography as a hobbyist,
>> block cipher design is not exactly the area I'd pick.
>
>Curious, what would you pick?
Cryptanalysis is one good choice, as you suggested. It is not an
easy field, but any cryptanalytic results you can find will be of
immediate interest.
Another might be `security engineering': how can we use all of these
advanced cryptographic techniques to improve real-world security
systems and strengthen them against their most common failure modes?
To pick a few random examples, see Dan Boneh's work on using batching
to speed up SSL webservers, on using cryptography to enable revocable
backup, on using threshold cryptography to improve intrusion tolerance
of cryptographic computation by distributing keys across many servers.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Newbie question about algo
Date: Sat, 26 May 2001 10:49:53 -0700
Martin Kiewitz <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi !
>
> I'm somehow a newbie to cryptology and i'm just building some stream
> encryption algorythmn.
> I don't want flames, please. I'm posting this, so other people can
> post their opinions about it.
>
> I want to encode a duplex-stream (named pipes, tcp-connection, etc.)
> using a really fast
> and safe algorythmn.
Obvious question: why don't you use SSL, which would appear to be written to
solve the same problem, and it was done by people who actually knew what
they were doing.
>
> Handshaking is done using PGP Public Key.
> The server sends its System-Key to the client.
> Client checks key by proofing signature with Super Key.
> Now client encodes LoginData & Crypto Hash using Public Key.
> Client sends that paket to server.
> Server decrypts LoginData & Crypto Hash with its own secret key.
>
> Now server sends unencrypted (raw) success of login. (that's done, so
> no byte guessing can take place).
> Server sends terminal operations, till actual interactive use needs to
> be done by client. (actually till Server thinks Crypt is needed).
>
> Now my own crypt algo looks like this:
>
> In and Out Stream, both have 2Kbyte Hash, both are generated by client
> and both are "true" randomized numbers.
>
> I suppose: CurPos = 0 (at begin of en/decryption)
>
> To encode:
> 1. EncodedChar = OrgChar xor Hash[CurPos]
> 2. Hash[CurPos] = Hash[CurPos] xor EncodedChar
> 3. CurPos = CurPos+OrgChar
> 4. CurPos is cut down to 2k range
> 5. Encode further data
>
> Decoding is performed accordingly.
>
> Is this algo good ? Is it breakable ?
For one, note that, at step 2, you update:
Hash[CurPos] = Hash[CurPos] ^ EncodedChar
= Hash[CurPos] ^ OrgChar ^ Hash[CurPos]
= OrgChar
Or, in other words, the encryption is xoring the current byte of plaintext
with a previous plaintext byte (except for the initial segment), and the
only nontrivial aspect is that the exact previous plaintext byte varies
based on the exact plaintext. For one, this means that the output of the
cipher, given ASCII, will be strongly biased away from uniform.
For another, if the attacker gets (say) 1k or so known plaintext, at the end
of it, he'll know enough about the state of the Hash array that continuing
onwards would be relatively simple.
In addition, if you encrypt a longish guessable phrase (say, 32 bytes or
more), then it becomes likely that a single location will be used twice
within that phrase. When that happens, that can be used as a test to verify
whether that phrase actually occurs within a stream of ciphertext. You can
use this to attack ciphertext-only, if the plaintext was low-redundancy
(say, boilerplate, or computer-computer communications).
--
poncho
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: A generic feistel cipher with hash and gf(257) mixers
Date: Sat, 26 May 2001 18:09:20 GMT
David Wagner wrote:
>
> Tom St Denis wrote:
> >"David Wagner" <[EMAIL PROTECTED]> wrote:
> >> If you want to maximize the odds
> >> of making a contribution to the science of cryptography as a hobbyist,
> >> block cipher design is not exactly the area I'd pick.
> >
> >Curious, what would you pick?
>
> Cryptanalysis is one good choice, as you suggested. It is not an
> easy field, but any cryptanalytic results you can find will be of
> immediate interest.
Not to sound a bit bitter but I didn't get alot if any feedback on my
observations of Noekeon. Sure I didn't break the entire cipher or the
real one for that matter...
> Another might be `security engineering': how can we use all of these
> advanced cryptographic techniques to improve real-world security
> systems and strengthen them against their most common failure modes?
> To pick a few random examples, see Dan Boneh's work on using batching
> to speed up SSL webservers, on using cryptography to enable revocable
> backup, on using threshold cryptography to improve intrusion tolerance
> of cryptographic computation by distributing keys across many servers.
Those are real topics they should teach in college!
Tom
------------------------------
From: "BenZen" <[EMAIL PROTECTED]>
Subject: Re: Crypto NEWBIE, wants to create the 100% SAFE FRACTAL encoding...
(Scientific Language)
Date: Sat, 26 May 2001 14:21:49 -0400
John Savard wrote in message <[EMAIL PROTECTED]>...
>On Sat, 26 May 2001 12:38:44 +0200, Mok-Kong Shen
><[EMAIL PROTECTED]> wrote, in part:
>
>>max { n | H(m,n) > 0 } means the largest of all candidate
>>n values that satisfy the condition H(m,n)>0 (for a given m).
>
>Although I could have told him _that_, I didn't see your earlier post
>to find the URL to translate it more fully into layman's language.
>(What's H(m,n), and why are we interested in it?)
>
>I'd have explained
>
>g(m) := max { n | H(m,n) > 0 }
>
>like this:
>
>The function of m called g, g(m), is being defined here. For any m,
>the value of g(m) is the largest value of n for which H(m,n) is
>positiive.
>
>But that's still mathematical language, not layman's language: to go
>to layman's language, I need the full context.
>
Thank you both,
For John, here is Mr Shen's page:
(I did a search for M.K.shen... Found a link on this page:
http://www.mandala.co.uk/links/cryptography/ ) Which led me to his page:
http://home.t-online.de/home/mok-kong.shen/
And there is (was) a reward for solving these problems... I gave-up on both,
from lack of scientific notation background.
I might not be good in advanced Mathematic notation, But I sure can Surf & read. ;)
Now, I'm rather annoyed to notice how Little my Electrical Engineering degree
is helping me with these advanced notations.
Even in the field of Algorithmics; which field I am rather prolific and good in
general. Having written sophisticated communication protocols embedded in
token-ring fiber-optic systems and Internal process communication for distributed
clusters.
Doing a quick search on "Layman's language"; I ended-up with Law text documents ?
Then I narrowed my findings to something closer:
http://www.netfunny.com/rhf/jokes/new90/nullang.html The NULL Language ;)
something for me I guess.. LOL.
Seriously;.. Is there a comprehensive web site that could introduce me to the
Layman's language and notation ?
Only after a hard search on the WWW, I could find this page:
http://tinymac.ecst.csuchico.edu/~keuneke/CSCI256Chapters/Chapter1.html
Still far from the introduction I am looking for.
(This short document is entitled: Lecture on: What is a proof)
http://theory.lcs.mit.edu/classes/6.042/spring01/handouts/spring00/L01.pdf
It does look better for a start.
This also looks like a pertinent start:
http://www.best.com/~szabo/kolmogorov.html
I guess I know the basics of it; I just want to be up to date with current litterature.
Regards,
Ben
BTW, I found yet another very comprehensive page that summarize modern
cryptology very well: http://www.alnitak.org/articles/articles20000725.html
Good Illustrated Lecture on Fractals:
http://astronomy.swin.edu.au/pbourke/fractals/fracintro/ With many references.
------------------------------
Subject: Re: Essay on "The need for a look at real life crypto"
From: [EMAIL PROTECTED] (Ryan Phillips)
Date: 26 May 2001 13:18:29 -0500
Tom St Denis <[EMAIL PROTECTED]> wrote in news:3B0F9EFE.907F2A73
@yahoo.com:
> Based on my turn about look at computer security...
>
> http://tomstdenis.home.dhs.org/on.pdf
>
> Please comment if possible. Does this hit the mark with what you guys
> are thinking?
>
> Tom
>
I thought it was a decent essay. The only complaint I have is related to
the PGP paragraph, it is just not about PGP; all public key algorithms have
the problem of identifying and verifying public keys and certficates issued
by users and the CA's.
If you create a key that has the same username and email of one my friends
keys, and I already know that I have a verified public key on my keyring (by
calling them up and verifying the fingerprint, or them giving it to me in
person), then I'm going to know that the message sent was with a bogus key
and is fradulent.
There are ways to minimize your risk, but any PKI algorithm has this
drawback.
-ryan
--
please delete NOSPAM from the email address to
uncover my real address.
====== 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: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: Small (not fast) RIPEMD-160
Date: Sat, 26 May 2001 17:32:48 GMT
If SHA-1 is smaller and something small is needed, then why not use SHA-1?
Does RIPEMD-160 have any advantage over SHA-1?
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Essay on "The need for a look at real life crypto"
Date: Sat, 26 May 2001 18:34:03 GMT
"Ryan Phillips" <[EMAIL PROTECTED]> wrote in message
news:3b0ff375$1_4@newsfeeds...
> Tom St Denis <[EMAIL PROTECTED]> wrote in news:3B0F9EFE.907F2A73
> @yahoo.com:
>
> > Based on my turn about look at computer security...
> >
> > http://tomstdenis.home.dhs.org/on.pdf
> >
> > Please comment if possible. Does this hit the mark with what you guys
> > are thinking?
> >
> > Tom
> >
>
> I thought it was a decent essay. The only complaint I have is related to
> the PGP paragraph, it is just not about PGP; all public key algorithms
have
> the problem of identifying and verifying public keys and certficates
issued
> by users and the CA's.
>
> If you create a key that has the same username and email of one my friends
> keys, and I already know that I have a verified public key on my keyring
(by
> calling them up and verifying the fingerprint, or them giving it to me in
> person), then I'm going to know that the message sent was with a bogus key
> and is fradulent.
>
> There are ways to minimize your risk, but any PKI algorithm has this
> drawback.
True, I was focusing on PGP because it's a buzzword. Sure there are other
PK programs out there that have the same flaws..
Tom
------------------------------
From: [EMAIL PROTECTED] (Martin Kiewitz)
Subject: Re: Newbie question about algo
Date: 26 May 2001 11:35:55 -0700
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
Hi Tom !
First, thanx for replying. In my reply i don't want to defend my
work, but simply put my thoughts down.
> Martin Kiewitz wrote:
> > be done by client. (actually till Server thinks Crypt is needed).
> > Now my own crypt algo looks like this:
> Question: Why did you invent your own algorithm?
Well, I wanted to have a really easy to implement algorithm, which
also is 100% done by me, so I would have no licensing, porting or other
issues. I need it for multiple OSes and I do not trust in RSA or such
stuff. I like PGP and Open Source encryption, but PGP is way too slow
for this. Additionally I wanted to be able to write everything of it
in plain assembler for speed issues.
If I ever want to put my project open-source, perhaps I could get
many problems using known techniques.
> > Decoding is performed accordingly.
> > Is this algo good ? Is it breakable ?
> Um fairly easily. A known plaintext attack can learn contents of Hash
> relatively easily. Also by encoding a stream of 1 bytes I can learn the
> entire table with 2kb worth of text.
Hmm and that's the point. The algo will not be used for message-encoding.
It will be used only in encoding Terminal Operation Codes, which are
different on every user and an attacker would not have anything plaintext.
You can not learn the whole table with 2k text, because the
pointer is not incremented by one. It's incremented by the original
character, which you would only know, when also knowing the correct
value at the correct offset within the table.
Because there is no data to be known on connection time, the attacker
can not know what is actually being sent. If he knows part of the transmission,
which would be possible, he would also not be able to get the complete table.
> > When suggesting that the hash is transmited without being captured, I
> > modified each decoded char, no byte guessing is possible, because
> > there is no data to check for.
> The problem is you are onlything thinking of known ciphertext attacks.
> If I know the plaintext I can break this.
Sure. But if you would know the plaintext, you would not need to.
The sender and receiver already have the hash.
The hash is also different on each logon, so you never get the same
encoding scheme.
> > What could I improve ? Is my handshaking good ?
> > I read somewhere, that a good algo does not have to be long or
> > complex, but it has to be strong.
> Well I dunno about your PGP hand shaking.... but the stream cipher is
> weak, and I think has a short period.
It's built really simple, I know. Enlarging the hash would not
enlarge strength, too, because the attacker is not able to know
just a single byte of the transmission (due the fact that I do not
encrypt the actual server ack paket, nor do I encode the first
pakets, which would bethe same on each session). I know of this
weakness, but I believe nearly every algo has it. Think of ZIP
encryption. In that case it's more bad, because you only have to
know about 10 bytes. In mine, you would need to know many more and
if the known bytes are not at the begin of the data, they are useless
anyway.
> Tom
cu Kiewitz
------------------------------
From: [EMAIL PROTECTED] (Terry Cooper)
Subject: Re: Hybrids
Date: 26 May 2001 11:50:32 -0700
Ed Kubaitis <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> Terry Cooper wrote:
> >
> > Where can I get information about hybrids (one-time secret keys sent with PK)?
> > --Terry Cooper
>
> ??
>
> SSL and TLS (see google.com) send one-time secret session keys
> with PK crypto and probably account for a healthy fraction of the
> encrypted bytes xmitted around the planet.
>
> What needs do you have that they don't meet?
>
> /ejk
None. PGP does likewise, using the IDEA cypher to supplement RSA or
the newer Diffie Hellman keys. The idea (no pun indended) is quite
clear; I simply hadn't heard them referred to as "hybrids (one-time
secret keys sent with PK)" before.
Thanks for the help.
------------------------------
From: Kt <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker,talk.politics.crypto
Subject: Re: James Felling: Sorry to break your bubble
Date: Sat, 26 May 2001 19:53:02 +0100
HiEv wrote:
> First of all, the phrase is "burst your bubble" not "break your bubble".
HiEv, this guy is one of life's embittered losers. Let him be.
Kt
--
http://www.althacker.org
Web: http://kt.althacker.org
PGP Fingerprint: 75B2 6525 A47D 7B5B B68B 4141 CAD9 8985 504B 580D
"Two fonts walk into a pub and the barman says, 'Sorry, we don't serve your
type here.'"
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Newbie question about algo
Date: Sat, 26 May 2001 18:57:20 GMT
Martin Kiewitz wrote:
>
> Tom St Denis <[EMAIL PROTECTED]> wrote in message
>news:<[EMAIL PROTECTED]>...
>
> Hi Tom !
>
> First, thanx for replying. In my reply i don't want to defend my
> work, but simply put my thoughts down.
>
> > Martin Kiewitz wrote:
> > > be done by client. (actually till Server thinks Crypt is needed).
> > > Now my own crypt algo looks like this:
> > Question: Why did you invent your own algorithm?
>
> Well, I wanted to have a really easy to implement algorithm, which
> also is 100% done by me, so I would have no licensing, porting or other
> issues. I need it for multiple OSes and I do not trust in RSA or such
> stuff. I like PGP and Open Source encryption, but PGP is way too slow
> for this. Additionally I wanted to be able to write everything of it
> in plain assembler for speed issues.
> If I ever want to put my project open-source, perhaps I could get
> many problems using known techniques.
You claim you don't like RSA but you do like PGP? Is it the company or
the algorithm? (Hint PGP uses the RSA PK algorithm). Also there are
already alot of open-type ciphers. You just have to look for them. RC4
comes to mind (call it ARC4 if you need). Or you could use a block
cipher in CTR mode (blowfish, 3des, any of the AES fianalists) ...
The only reason to make homebrew ciphers is to see if you can break
them, not to actually use them.
> > > Decoding is performed accordingly.
> > > Is this algo good ? Is it breakable ?
> > Um fairly easily. A known plaintext attack can learn contents of Hash
> > relatively easily. Also by encoding a stream of 1 bytes I can learn the
> > entire table with 2kb worth of text.
>
> Hmm and that's the point. The algo will not be used for message-encoding.
> It will be used only in encoding Terminal Operation Codes, which are
> different on every user and an attacker would not have anything plaintext.
> You can not learn the whole table with 2k text, because the
> pointer is not incremented by one. It's incremented by the original
> character, which you would only know, when also knowing the correct
> value at the correct offset within the table.
> Because there is no data to be known on connection time, the attacker
> can not know what is actually being sent. If he knows part of the transmission,
> which would be possible, he would also not be able to get the complete table.
I beg to differ. Scott Fluhrer pointed out some serious flaws as did I.
This gets back to the "good enough" issue. Sure at this very moment I
can't think of a full break (also because I would have to read the old
news to see the cipher description) but I recall pointing out serious
flaws that would be indicative of a bad design (no offense but it really
isn't a secure design IMHO).
> > > When suggesting that the hash is transmited without being captured, I
> > > modified each decoded char, no byte guessing is possible, because
> > > there is no data to check for.
> > The problem is you are onlything thinking of known ciphertext attacks.
> > If I know the plaintext I can break this.
>
> Sure. But if you would know the plaintext, you would not need to.
> The sender and receiver already have the hash.
> The hash is also different on each logon, so you never get the same
> encoding scheme.
Yes, but if I can break the scheme with say 16 bytes that doesn't appear
to be very secure to me.
How much data are you sending through this cipher?
> > > What could I improve ? Is my handshaking good ?
> > > I read somewhere, that a good algo does not have to be long or
> > > complex, but it has to be strong.
> > Well I dunno about your PGP hand shaking.... but the stream cipher is
> > weak, and I think has a short period.
>
> It's built really simple, I know. Enlarging the hash would not
> enlarge strength, too, because the attacker is not able to know
> just a single byte of the transmission (due the fact that I do not
> encrypt the actual server ack paket, nor do I encode the first
> pakets, which would bethe same on each session). I know of this
> weakness, but I believe nearly every algo has it. Think of ZIP
> encryption. In that case it's more bad, because you only have to
> know about 10 bytes. In mine, you would need to know many more and
> if the known bytes are not at the begin of the data, they are useless
> anyway.
Perhaps. I would seriously say this.
1. If you're a budding cryptographer think of your cipher *first* in a
theoretical model, then in a real life one. If the best attack against
your cipher requires 2^44 work, etc... then perhaps in the real-life
model it's good enough. In this case I bet there is an attack with
under 2^16 work and negible memory. That doesn't lead me to believe
that in real-life it will be of much use.
2. If you're a budding system designer don't bother making your own
cipher. It will most likely be a poor design (it takes alot of
practice, reading, learning and trying to make a decent design) anyways
and defeat the purpose of security.
I am not trying to be mean. Just that if you intend this to be secure
don't use homebrew crypto.
Tom
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: A generic feistel cipher with hash and gf(257) mixers
Date: Sat, 26 May 2001 17:56:46 GMT
"David Wagner" <[EMAIL PROTECTED]> wrote
> If the goal is `slow but secure', how does it compare to the GGR
> tree-based scheme that I posted earlier? (I've posted the citation to
> GGR several times before on this newsgroup, so I won't do it again.)
Sounds intriguing, but could you give us a clue? I missed your previous
cites. A search turned up references to GGM and CTR, but I don't
know if these are the same or not.
> Note that the GGR scheme comes with a proof of the following statement:
> Suppose AES is secure against all attacks that use four blocks of chosen
> plaintext and a reasonable amount of computation. Then AES-GGR is
> secure against all attacks that use a reasonable amount of computation,
> even if the adversary has access to many blocks of adaptively-chosen
> plaintexts and ciphertexts.
> AES-GGR can be made to run pretty fast: It needs about 2 AES encryptions
> per block of plaintext that you'd like to encrypt, I believe. In other
> words, GGR provides very strong security at not too much performance cost.
>
> As a consequence, if you want `slow but secure', GGR seems to be the
> construction to beat.
------------------------------
** 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
******************************
