Modification on AES
McDohl
simplicity, correct? I'm no expert, but would replacing rijndaels key
schedule & s-box with something like blowfishes method help?
--
"The beginning of knowledge is the discovery of something we do not
understand."-Frank Herbert
Globemaker
> The two major concerns of AES is its weak key schedule and its algebraic
> simplicity, correct?
No. There are higher level concerns than the algorithm. For example,
why would people with secrets want the efficiency of AES rather than
the security of a "LONG KEY CRYPTOSYSTEM"? Rijndael was chosen as the
best of class, where the class was a collection of 12 efficient
algorithms. All candidates were prohibited from creating a standard
algorithm using key lengths that reflect the state of the art of
semiconductor hardware. We can call that "key schedule weakness" by
using the most liberal interpretation of your first question.
>I'm no expert, but would replacing rijndaels key
> schedule & s-box with something like blowfishes method help?
Yes, it would help, in some dimension. This incremental "help" is not
as practical as the vast benefits from using a long key algorithm like
scott19u.zip
Richard Outerbridge
<484fb9d6-724a-4cdf...@h14g2000pri.googlegroups.com>,
Globemaker <alanfo...@cabanova.com> wrote:
> ....
> All candidates were prohibited from creating a standard
> algorithm using key lengths that reflect the state of the art of
> semiconductor hardware.
Which prohibition might that be, precisely?
And exactly which state-of-the-art, when?
outer
adacrypt
Merry Christmas first of all.
I am taken by your knowledge of AES togetether with the replies from
other readers. Frankly I do not know anything about AES and would
like to know more. Could you expand a bit on what it means "The
algebra is weak etc". Because it is breakable by brute forcing I am
not prepared to spend a lot of time studying it at home. Could you
give me an idea of the basis of AES - as simple as possible - how much
does it lean on the sheer density of contiguous bibary digits ? -
there's more I need to ask later but its Christmas - later - Austin O'
Byrne
PaulLiu (GrandPaul)
Hash: SHA512
McDohl 提到:
> The two major concerns of AES is its weak key schedule and its algebraic
> simplicity, correct? I'm no expert, but would replacing rijndaels key
> schedule & s-box with something like blowfishes method help?
>
>
>
Why not use twofish?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIcBAEBCgAGBQJLM8ypAAoJEPgLgUbQQog2r5wP/3XanpO0Krk7QWyKBI/8ru61
ha7eJ7q8aqPkq6hmuCPmE7BBgUz7CUUBQoxi7zQtDaJQOQJQGKRGyUQm+ygN756H
6mfSZYEO9nbUTKeoUFObLxgqaid0h8RC5rdmvJkQw6ml57L3B6uB2yc8QWRidB6V
Yc3OJmuakiDI7sGzcqtsqWDWUhdLsGPsinuCNpxuY0HuaRoKhSjhV9/B8k/RSzRu
0LfrXSMEjdsZ/tq/++VhheRO7ymeFiZH/edL1YHFdcWT8RafCSmcR+ZgnfnOFLV3
snii1l8ipFOJRkAkmdXA+fcnz9q11oXB7D5n4lN2Poz4QkOo4J9r4nhPFuDpya4f
Cr2V1eJFP9AjBwMi4k9Nuz+qHt+UZ/Ku8RZHkUEAhec+KskOcuna2mnZ4U3iIWOY
sOiPKpJIF1ZYf4uOHyAZpRW39CR8vOzTNRQIbC8etl1rsSm5E3edTRZqk7qm2aq6
GQvS9+3rMn4xdL5NJyQn1f2QHecVQiQgfbPAzwMzZtGqkfd0xv37LXkEZVzldIn8
5GC05pfUpRNZYtshEhWPxeuK9xoSekYmy58fUx2ZUU2Rfa69PdEBBuZRA+v2e154
JhidhYKVr2qE9sDOzLz7Dsvl4dbpiWWlVl0n/FhrbLociPFNgTT28ykuLNhOhb61
Agjc/rKXWlqmQPxLFc9N
=tyUT
-----END PGP SIGNATURE-----
Peter Fairbrother
> The two major concerns of AES is its weak key schedule and its algebraic
> simplicity, correct? I'm no expert, but would replacing rijndaels key
> schedule & s-box with something like blowfishes method help?
The key schedule weakness in AES is only relevant to versions other than
AES-128, which afawct doesn't have any significant key weaknesses.
AES-192 and AES-256 do have some key schedule weaknesses, but they are
only really relevant when they are used in hash constructions. Even then
the attack is more of theoretical than of practical importance
You could perhaps use Rindjael-192 and -256 if you are worried about key
schedule weaknesses, I *think* they don't have the weaknesses of AES
-192 and -256.
The algebraic structure is something of a potential worry, but no-one
has been able to break AES using an algebraic attack, and the
theoretical attacks are worse than brute force unless better systems for
solving large numbers of quadratic equations with many unknowns are
developed.
People are working on this, and may or may not get anywhere - at the
moment we just don't know. However it doesn't look likely to have much
practical significance.
Changing the s-boxes might be a help against algebraic attack, but it
introduces many potential problems of it's own - it's not a simple
solution to implement without weakening the cipher.
BTW, algebraic attacks can in theory be applied to most block ciphers,
it's just easier with AES due to the simpler algebraic structure.
-- Peter Fairbrother
degol...@yahoo.com
> The two major concerns of AES is its weak key schedule and its algebraic
> simplicity, correct? I'm no expert, but would replacing rijndaels key
> schedule & s-box with something like blowfishes method help?
I assume by "something like blowfish" you mean the following: use AES
itself, initialized with the user key and a 'default' s-box, to
iteratively generate a bunch of pseudo-random, key-dependent gibberish
that is then plugged into the entries of the s-box, in effect making
the s-box key-dependent.
This will not work. AES is an SPN (substitution permutation network),
and in order for it to be invertible (i.e. if someone ever wanted to
decrypt and read the messages you encrypt with it) the s-box must be a
permutation ("permutation" in the sense of a bijective function where
the domain and range are both the same set). Blowfish's round
function is not a permutation, but it can get away with that because
it has a Feistel structure, which is considerably more forgiving in
that regard than an SPN.
If you simply fill in the 256 entries of AES's s-box with pseudo-
random key-dependent junk then the odds are very low that the
resulting s-box will be a permutation (and hence very low that the
cipher will be invertible/decryptable). You would need a very
specialized algorithm that can generate 256 eight-bit entries that are
i) pseudo-random and key-dependent, and ii) which together comprise a
permutation (Twofish essentially does this). AES, no matter how you
initialize it, simply is not right for that task, and hence cannot be
used to iteratively generate the s-box in the Blowfish manner.
McDohl
wikipedia is the easiest to read. The guy at http://www.samiam.org/
rijndael.html has a great page for more in depth information. He
implements the algorithm in C while explaining all the steps.
I know there are some better algorithms out there that should be used for
higher security. I'm just being a geek.
The key schedule weakness I'm referring to was a related key attack
blogged by Bruce Schneier. Of course it can be provented with a hash. By
algebraic simplicity, I mean it can be represented with millions of
equations and solved for the key with only a few pain/ciphertexts. It is
only theoretical, as solving it would take lots of memory and time
(lookup XLS attack, I don't know much about it).
Vary good point degolyer181. We can still run the encryption (hash?) in
cfo/ofb/ctr/etc.. where only the encryption function is needed for
encryption and decryption.
Marry Christmas to all.
J.D.
> Vary good point degolyer181. We can still run the encryption (hash?) in
> cfo/ofb/ctr/etc.. where only the encryption function is needed for
> encryption and decryption.
That is true. But in addition to the s-box not being invertible/
decryptable if it is not a permutation, any n-by-n s-box that is not a
permutation will necessarily have some entries that are duplicates of
each other, opening the door to collision attacks.
McDohl
> That is true. But in addition to the s-box not being invertible/
> decryptable if it is not a permutation, any n-by-n s-box that is not a
> permutation will necessarily have some entries that are duplicates of
> each other, opening the door to collision attacks.
Thanks. I didn't know that. After the s-box is generated, cycle through
the bytes, checking if they were used before. If they were, increase by 1
until an unused value is found.
McDohl
>Because it is breakable by brute forcing I am
>not prepared to spend a lot of time studying it at home.
Did you say AES is breakable by brute force? Maybe you misread your
information.
J.D.
> On Fri, 25 Dec 2009 20:45:01 -0800, J.D. wrote:
> > That is true. But in addition to the s-box not being invertible/
> > decryptable if it is not a permutation, any n-by-n s-box that is not a
> > permutation will necessarily have some entries that are duplicates of
> > each other, opening the door to collision attacks.
>
> Thanks. I didn't know that. After the s-box is generated, cycle through
> the bytes, checking if they were used before. If they were, increase by 1
> until an unused value is found.
That, I suppose, could work. But it is a somewhat inelegant and
unnecessarily time-consuming approach. Check out Twofish's key
schedule for a (IMO) better way of constructing key-dependent 8-by-8 s-
boxes.
On a larger point, making AES's s-box key-dependent like those in
Twofish probably would add to its security*, but it also adds to the
complexity of the algorithm (making it harder to program and more
prone to implementation mistakes), and it makes for a slower, more
cumbersome key-schedule, and is probably harder and more expensive to
implement in hardware. So the question is, "Is the gain in security
worth these trade-offs?" There was an entry in the NESSIE competition
called "Grand Cru" that was essentially identical to Rijndael, except
that some of its functions were key-dependent (though not, IIRC, the s-
box) -- Grand Cru was not selected, possibly for the sort of trade-off
reasons described above.
* Though again it might not: Random 8-by-8 s-boxes on average have
good LPMax and DPMax properties, but it is possible that a certain
percentage of keys could produce poor quality s-boxes, and that this
could lead to viable attacks.
J.D.
> On Fri, 25 Dec 2009 00:24:26 -0800, adacrypt wrote:
> >Because it is breakable by brute forcing I am
> >not prepared to spend a lot of time studying it at home.
>
> Did you say AES is breakable by brute force? Maybe you misread your
> information.
AES is breakable by 'brute force' (so to speak). Doing so would
require on average about 2^(n-1) encryption operations, where n = the
size of the key. This, however, is sufficiently difficult that for
all practical purposes it is near enough to impossible as to make no
difference.
Maaartin
> The two major concerns of AES is its weak key schedule and its algebraic
> simplicity, correct? I'm no expert, but would replacing rijndaels key
> schedule & s-box with something like blowfishes method help?
Be warned, that whatever you do to any good well-known cipher will
most probably weaken it. Neither am I an expert but this is what I can
tell you for sure.
Moreover, AES is hardly going to be the weakest point of the system,
even when a new breakthrough attack should come out tommorow.
If you want something better than look for another thoroughly
analyzed cipher. Maybe a stream cipher (e.g., Salsa20) would do? For
more security some people recommends using cascading different
ciphers, but (afaik all) experts advice against it.
Ohm
> analyzed cipher. Maybe a stream cipher (e.g., Salsa20) would do? For
> more security some people recommends using cascading different
> ciphers, but (afaik all) experts advice against it.
I am not sure what experts you are referring to, but Truecrypt manual
advices to use a cascade cipher for extra security, saying that it will
be harder to break if a vulnerability is found on one of them.
Tom St Denis
> * Though again it might not: Random 8-by-8 s-boxes on average have
> good LPMax and DPMax properties, but it is possible that a certain
> percentage of keys could produce poor quality s-boxes, and that this
> could lead to viable attacks.
Attacks that are successful on reduced round AES so far take advantage
of the structure of the cipher, not the sbox values themselves. While
being "algebraic" is bad, nobody has seemed to exploit it yet. The
branch of AES is ridiculously high though, so even an sbox with weak
LP or DP maxima would still be secure against LC and DC.
Tom
Joseph Ashwood
"Globemaker" <alanfo...@cabanova.com> wrote in message
news:484fb9d6-724a-4cdf...@h14g2000pri.googlegroups.com...
> No. There are higher level concerns than the algorithm. For example,
> why would people with secrets want the efficiency of AES rather than
> the security of a "LONG KEY CRYPTOSYSTEM"?
Because it is trivially provable that the universe has computation limits,
it is further trivially provable that any adversary would have a miniscule
percentage of the maximum computation resources of the universe.
> Rijndael was chosen as the
> best of class, where the class was a collection of 12 efficient
> algorithms.
That is correct, although the best of class can be debated, that was the
goal of the process.
> All candidates were prohibited from creating a standard
> algorithm using key lengths that reflect the state of the art of
> semiconductor hardware.
This is where you go from being off your rocker, to falling off the floor
too. The state of the art of semiconductor hardware was used, in fact the
state of the art of semiconductor hardware has resulted in improving the
efficiency of AES.
> We can call that "key schedule weakness" by
> using the most liberal interpretation of your first question.
Well no, but we can call everything you said a moronic statement.
>>I'm no expert, but would replacing rijndaels key
>> schedule & s-box with something like blowfishes method help?
>
> Yes, it would help, in some dimension.
See the other replies, they have addressed this fairly well.
> This incremental "help" is not
> as practical as the vast benefits from using a long key algorithm like
> scott19u.zip
So to summarize, you believe a known idiot's word, that has never been
analyzed by anyone except the same known idiot, and every previous cipher
the known idiot created fell immediately the moment someone other than said
known idiot looked, and somehow this known idiot will magically create a
secure cipher. You believe this in contrast to the many thousands of hours
of analysis by known geniuses, and many hundreds of hours of creation time
by known geniuses. My money is that the known geniuses would be far better
at everything except creating interesting drool patterns.
As for the weaknesses in AES, they do exist, but for functional purposes
they are mostly irrelevant.
Joe
Maaartin
Many times I saw arguments like
"How could cascade cipher help against unknown attacks when you don't
know how they work?"
written by people I'd assume to be real experts.
IMHO they're wrong, but my opinion doesn't count much (not even for
me).
My arguments are:
- I suppose that one cipher gets broken faster then the other even
when the attack is very general.
- Using two ciphers in cascade means using more rounds.
- Combining different ciphers makes the analysis much harder.
However, cascading is an overkill.
Tom St Denis
The problem with this logic is it suffers from that which it tries to
protect against.
Claim: Unknown attacks will break one [or a non-complete subset] of
algorithms {X, Y, Z}, therefore X o Y o Z is stronger than any
incomplete subset composition.
Assumption: Attack will not apply to complete subset AND complete
composition does not introduce vulnerabilities to attack.
Flaw in the assumption: Unknown attacks are unknown, people assume
they won't apply to any/all combinations of ciphers.
The reality has been for a while that modern ciphers can stand quite a
bit of scrutiny. Even ciphers we think of as broken aren't in reality
100% useless. Chances are there will be other weak links in the
security (bad passwords, compromised machine, torture, etc...).
People should design protocols to be accommodating for new algorithms
(e.g., not hardcoded to use AES) but not invent new ciphers. AES-CTR
keyed and IV'ed properly is fine for most [if not all] privacy needs
(where AES will fit in gates/code size). Suggesting the fix is to mix-
and-match ciphers is dangerous because it makes people focus on the
wrong areas of security. They forget that they need secure passwords,
or to physically secure things because they're distracted by the shiny
that is their AES-Serpent-RC6-MARS-Twofish-IDEA-ICE-LOKI97 combo
cipher...
Tom
Spinner
>On Dec 27, 10:22�pm, Ohm <O...@no.no> wrote:
>> > If you want something better than look for another �thoroughly
>> > analyzed cipher. Maybe a stream cipher (e.g., Salsa20) would do? For
>> > more security some people recommends using cascading different
>> > ciphers, but (afaik all) experts advice against it.
>><SNIP>
>
>The reality has been for a while that modern ciphers can stand quite a
>bit of scrutiny. Even ciphers we think of as broken aren't in reality
>100% useless. Chances are there will be other weak links in the
>security (bad passwords, compromised machine, torture, etc...).
>
>People should design protocols to be accommodating for new algorithms
>(e.g., not hardcoded to use AES) but not invent new ciphers. AES-CTR
>keyed and IV'ed properly is fine for most [if not all] privacy needs
>(where AES will fit in gates/code size). Suggesting the fix is to mix-
>and-match ciphers is dangerous because it makes people focus on the
>wrong areas of security. They forget that they need secure passwords,
>or to physically secure things because they're distracted by the shiny
>that is their AES-Serpent-RC6-MARS-Twofish-IDEA-ICE-LOKI97 combo
>cipher...
>
>Tom
As stated ad nauseam in this group, any reputable cipher is known to
attack resistant at some level (or it wouldn't be reputable) and the
professional peer review process keeps the quality up. A question
remains:
Has anyone done any sort of probablity analysis on the front-to-back
real world uses of encryption vs the algorithm? i.e. user password
selection, scattered copies of original text accessible by trojan or
virus, the far end decryption and what B does with the pieces, etc.
From many many years in the biz, I strongly suspect that is extremely
expensive (work factor) to completely secure the data at all points
from creation, storage, encryption, and decryption.
Which takes us to the trivial point that if I need 500,000 worth of
hardware and a week to break your encryption, for a lot less I'm
pretty sure there are cheaper ways to gain access.
Hence the question, how infeasible for all but the most exotic setups
is it to create a data path that is AS secure as any competent
algorithm. Granted, all the variables aren't knowable, but that's
part of the point .. if you don't know that the algorithm is the
weakest point, then why worry about it?
.
--
2+2!=5 even for extremely large values of 2