This morning the First AES Conference started with a presentation
    of NIST's Miles Smid and Jim Foti. Here are the main points:

    The 15 candidate algorithms were officially announced. The mystery
    one is MAGENTA submitted by Deutsche Telecom. Only 5 are from the
    U.S. the other 10 are international including some from Canada,
    France, Belgium, Germany, Japan, Israel, Corea and Costa Rica
    (me).

    The analysis period of the 15 algorithm starts August 20, 1998 and
    ends February 1, 1999. Approximately five finalists will be chosen
    by NIST and late March 1999 the Second AES Conference will take
    place. After another nine months or so of public review the AES
    will be selected and the Third AES Conference will take place. We
    are now in the year 2,000. After that the formal FIPS process will
    start. The NIST people made very clear the they would be the ones
    doing all the selecting.

    The public review process NIST has designed is very interesting:
    it has one informal free-format thread implemented through
    newsgroups that NIST will create for each individual candidate
    (see you at FROG's). Formal comments will be sent to NIST and are
    supposed to discuss the algorithms themselves, the evaluation
    criteria, objective comparisons, etc.

    NIST has already designed a new web site (www.nist.gov/aes) with
    all these goodies. There you can find forms for ordering two CDs:
    CD-1 has the complete package of the 15 submissions minus source
    code and Test Vectors (but these will be available on NIST's site
    anyway). CD-2 has the source code and will be available by next
    September.

    After that came the coffee break. Leaving the hall there was a
    table with piles of papers and everybody seemed to want a copy.
    One of these was Schneier's cryptanalysis of FROG. I didn't get
    one because I already had it. So, for better or worse, FROG will
    be noticed at the Conference.

    Before lunch two algorithms were presented. The format is 30-35
    minutes of presentation followed by 10 more of questions. Carlile
    Adams from Canada presented CAST256 a "classical" cipher that
    passed several evolutionary stages and is well polished and
    analysed. Then DFC from France, presented by Serge Vaudenav. What
    is interesting about this cipher is that it is based on proofs
    about its strength against differential and linear attacks - but
    not on higher order attacks.

    At lunch I sat at the same table as two guys from IBM. I spoke
    quite a bit with one of them about MARS. I asked how much effort
    went into the cipher - they mentioned (if I understood correctly)
    an estimate of 1,000 meetings - which is a lot. He told me that a
    disadvantage of the AES process is that design teams from
    different competitors could not consult freely with each other
    because they were afraid that the other team might steal a good
    idea.

    It turned out that the IBMer I talked with at lunch was Sahi
    Halevi who presented MARS immediately after that. The most
    interesting aspect of MARS is that it wraps a diffusion layer
    around a cryptographic core. He mentioned that this variability of
    logic is a possible defense against *unknown* attacks, a theme
    that is normally tabu in a field where almost all work in design
    is concentrated in defending against known attacks. He said that
    they specifically excluded from MARS anything that they could not
    cryptanalyze, for example multiplication between data. Overall he
    gave a very clear, lucid presentation. Everybody knows the story
    of DES so he got questions like: does the MARS design include any
    not published criteria? (answer: No), did anybody from the outside
    help them design it? (answer: No), how can he show that there are
    no trap-doors present (answer: most design follows clear criteria
    but there is always  a necessary element of trust too.)

    After that came MAGENTA presented by a young PhD student who was
    not very experienced. MAGENTA is a strange cipher in many ways: it
    is quite complex, does not use S-boxes, and has only two rounds of
    Feistel (if I understood correctly). The algorithm appeared to be
    one order of magnitude slower than everybody else - he mentioned a
    hardware card capable of encryption 1Mbit per second. After he
    finished he got so many hard questions - you wouldn't believe. I
    mean they really tore into him, sometimes putting up traps for him
    to fall into. It got so bad that a few of the participants started
    doing real time cryptanalysis and suggesting attacks that would
    break the algorithm right there and then. I marvelled that the
    German guy managed to keep his composure. The whole spectacle was
    rather shameful - after all NIST had just announced eight months
    for the analysis period and surely everybody will have enough time
    to criticise to one's heart's content.

    Then came the unpronounceable Rijndael presented by a very
    unflappable Joan Daemen. The algorithm based on Square is not of
    the Feistel kind - quite elegant and fast. It also uses only XORs
    and byte substitutions exactly like FROG.

    Other points of interest: There are almost 200 participants (I
    have the list) including about 20 from NSA. NSA, by the way, is
    never pronounced by name, it's always "they". Actually it is weird
    to think about what they may be thinking - maybe they consider the
    ciphers presented little more than toys. Who knows?

    By the way, this is one informally dressed crowd: many were in
    Tshirts, some in jeans, slippers, etc.

    Of course, I didn't recognize anybody. Almost. Yesterday evening
    while checking in at the hotel I saw the famous Bruce Schneier (I
    recognized him from a picture in his web-site) but was too shy to
    present myself. He is small, blond, has a pony-tail and dresses
    very informally. He gives the impression of unbounded energy and
    enthusiasm - usually he is surrounded by people. I did recognize
    some famous names in the list of participants including Biham,
    Zimmerman, Rivest, Shamir - unfortunately I could not find
    familiar names from this newsgroup.

    Tomorrow will be a long day with seven presentations including
    myself at number six: LOKI97, DEAL, RC6, E2, SERPENT, FROG, and
    FROG and Hasty Pudding were put back-to-back most probably by
    chance. I am apprehensive about my presentation: I knew I had an
    unconventional cipher but I wasn't aware of how unconventional - I
    hadn't really looked into the other algorithms before coming here
    and I found the ones presented today very close to the beaten
    path.

--
http://www.tecapro.com
email: diane...@tecapro.com

--
http://www.tecapro.com
email: diane...@tecapro.com

However, I have my own suspicions. They may well consider a 128-bit
keysize to be something worthy of a "toy" cipher...

but they may also consider that the complexity of at least some of the
designs, MARS for example, as being far beyond any realistic threat of
cryptanalysis. (As I've noted, I wouldn't be at all surprised if
'they' find FROG to be closer to the sort of thing they use than are
many of the other candidates.)

    This was a long day.

    It started with the announcement of the Second AES Conference.
    After building some expectation Miles Spid announced it will be
    held in Rome, Italy, March 22-23 1999, at the Hotel Quirinale,
    near the Coliseum - according to Miles an apt metaphor for the fact
    that there 10 out of the 15 candidates will be eaten alive.

    After that came the presentation of LOKI97 presented by Jennifer
    Seberry of Australia. This is another Feistel cipher based on the
    original LOKI(89) design. An attack has been found on this cipher
    which Jennifer plainly explained as well as the fact that it is
    easily correctable.

    Then came DEAL presented by Richard Outerbridge. This is a curious
    candidate in the sense that the principal submitter is not the
    cipher's author (Lars Knudsen). DEAL is particular in the sense
    that it uses DES as a primitive - it uses between 6 and 8 DES
    encryptions for each DEAL encryption. Apparently an attack against
    DEAL has been found also - this brings the number of hit
    candidates to 4: LOKI97, MAGENTA, DEAL and (for weak keys) FROG.

    Then came the very even and fast spoken presentation of Ron
    Rivest's RC6 - based of course on RC5. This is a smooth cipher -
    conceptually simple and extremely fast to implement in software:
    as fast as 2 CPU cycles per bit encrypted. Uses 32 bit
    multiplication as does Mars. On the whole everybody felt this is a
    very strong contender.

    After lunch came E2, the Japanese Candidate, presented by a very
    young looking Shiho Moriai. This one is a Feistel too. To me it
    looks as a very carefully prepared candidate. She started pointing
    out a whole series of known attacks for which their algorithm was
    strong (differential, higher order differential, linear,
    interpolation and partitioning). A high point came when she
    presented the design of a 127 k gates die able to do 0.5 Gbps.

    Then Eli Biham's Serpent. It is a very conservative design where
    security is based on DES design philosophy and speed (this is an
    interesting twist) is based on bit-slicing, the most efficient way
    to implement DES in software. Here though, bit-slicing is not an
    afterthought but rather an integral part of the design. After he
    finished he was asked why he chose 32 rounds when his own analysis
    showed that 16 rounds would have been sufficient. His answer
    impressed me a lot: he simply wanted the added security - 16
    rounds beyond what appears to be sufficient! I wished I had
    thought in the same way while designing FROG.

    After that came I. I was painful aware that my cipher was quite
    off off off the beaten path - that it was not based on any
    previous cryptographic experience - that I had done no
    cryptanalysis of FROG - that it did not even pretend to be based
    on math - in other words, that I was breaking about every rule
    there is. Even so I found the crowd receptive, even laughing at my
    jokes (prepared beforehand). Midpoint through my presentation I
    did get defensive with Schneier's attack (I really think an attack
    should work against more than a small fraction of the keys), but
    this was not well received and it was a tactical mistake on my
    part. I also felt that the crowd did not like my more unorthodox
    ideas, such as that speed is not really important (by the way FROG
    as submitted is going to be one of the faster candidates when I
    optimize it for Pentium in assembler), or that a cipher should be
    user-modifiable, and that a cipher should resist known attacks
    without actually trying. As usual, I spoke too much and at the end
    there was time only for very few questions. These were informal;
    about why the name FROG and such. At the very least my ideas are
    out in the open - most important cryptographers were present there
    and if there is merit in any of my staff it should catch fire in
    their minds.

    By the way, before starting my presentation Schneier came to shake
    my hand - this was quite decent. I returned the compliment
    mentioning in public that everything I knew about cryptography
    came from Schneier's book and then making clear that any errors in
    FROG are therefore indirectly attributable to him.

    Lastly came Tasty Pudding, presented by an older statesman type of
    guy: Rich Schroeppel. I really don't know what to make of this
    cipher. At least, like FROG, he didn't try to emulate anybody. But
    it is complicated and openly in-elegant. He based his presentation
    more on tricks the cipher can do than on anything else. The most
    amazing part was the claim that it can encrypt fractional bits.
    Here is the example he gave: Say you want to encrypt a digit
    (0..9) which you cannot represent a whole number of bits; you put
    it in 4 bits and encrypt them; if the result is not in 0..9 then
    you encrypt it again; and so on until you get a digit result.
    Let's see an example: you want to encrypt 5 -> 13 (this is not
    good so let re-encrypt) -> 3. To decrypt 3 -> 13 (this cannot be
    so let's re-decrypt) -> 5. Using this mechanism you can now
    encrypt any data type into the same data-type: say dates into
    dates, printable characters into printable characters, etc. Tasty
    Pudding also uses "spice" a not indispensable secondary key that
    does not require setup and can be changed on the fly. - On the
    whole it is a weird beast and I wish my fellow dark horse the best
    of luck. I also like the name.

    After the conclusion of the day's work, interesting things
    happened. First a guy from Switzerland approached me and actually
    debated with me about FROG; I met a fellow Greek, Yiannis
    Tsiounis; also a frequent poster in this newsgroup, Bryan Olson,
    came to greet me. In general, I felt people were sympathetic or
    even admired my courage for participating in the competition - but I
    would rather have them admire my algorithm.

    Finally, IBM's Shai Halevi came who, as luck would have it, knew
    Yiannis, and the three of us went out for dinner. We talked a lot
    about cryptography and I was delighted to bounce my crazy ideas
    and preoccupation’s on these good people. There were some surprising
    or merely interesting results and I intend to write about this in
    another occasion.

Don't forget MY t-shirt. The Intellectual Property of Certicom was pretty
insulted because of that.

:     Of course, I didn't recognize anybody. Almost. Yesterday evening
:     while checking in at the hotel I saw the famous Bruce Schneier (I
:     recognized him from a picture in his web-site) but was too shy to
:     present myself. He is small, blond, has a pony-tail and dresses
:     very informally. He gives the impression of unbounded energy and
:     enthusiasm - usually he is surrounded by people.

Bruce is _very_ blond is does hopping around the room.

:     I did recognize
:     some famous names in the list of participants including Biham,
:     Zimmerman, Rivest, Shamir - unfortunately I could not find
:     familiar names from this newsgroup.

By some reasons, Shamir doesn't post here. Not sure why, but may be this
place is not interesting for him.

    Today was the last day of the conference - it ended at noon. Today
    it was revealed that the participants in the conference came from
    26 countries - so this is a very international process.

    First, Chae Hoon Lim from Korea presented Crypton. It is an
    evolution of SQUARE and has 12 rounds. It was cryptanalyzed
    against several attacks including truncated/higher-order
    differential, multiple linear approximations, algebraic attacks
    such as interpolation attacks. He explained that all S-boxes can
    take, at maximum, values for differential and linear approximation
    probabilities of 2^(-5) and 2^(-4) respectively and therefore the
    8 round characteristic probability of Crypton is at most 2^(-160)
    and that the best linear approximation probability is 2^(-128).
    More about this later. He mentioned several times that this is a
    work in progress, that he intended to improve this, he didn't much
    like that, etc.

    Then came Bruce Schneier with Twofish. His presentation was
    excellent and you could see that he is used to write books and
    explain things to people. Twofish is a 16 round Feistel based on
    Blowfish. It creates four key-depended S-boxes by modifying two
    fixed S-boxes. This is done very carefully and in the case of 128
    bit keys all created S-boxes (4 x 2^(32)) were exhaustively
    checked for quality - for larger key sides extensive Monte Carlo
    tests were applied. Bruce plainly stated that he stole ideas from
    Square (I believe this was the 4x4 matrix multiply over GF(256))
    and from SAFER (the pseudo-Hadamard Transform used for diffusion).
    In the same vain he mentioned that Twofish is amenable to operate
    "in non-interoperable variants using a family key" mentioning that
    this is something that FROG also does. This I liked very much.
    Later on he mentioned that a very efficien versions of Twofish
    "compiles" code - using the same words I used when describing what
    generalized Frog does. So, ideas present in FROG are starting to
    find their way into the mainstream of cryptography (I don't
    necessary claim that they were introduced with FROG because I am
    not sure it is true.)

    Back to Bruce's presentation which was full of interesting and
    educational points: He mentioned that very often in the design
    process of Twofish they had to make choices between more complex
    rounds against a larger number of rounds. For example, by taking
    out the rotations included in Twofish they could add one more
    round to the cipher with no loss of efficiency. What is very
    interesting is that, in general, they found that more rounds of a
    simpler structure are stronger than a few complex rounds. Another
    interesting point he mentioned is that the internal cipher design
    and the key-schedule are interdependent - you cannot design the
    two independently and then stick them together. Yet another
    interesting point is that "in cipher design it pays to put many
    eggs in few baskets" (he was explaining the fact that his key
    setup re-uses cryptographic primitives already there), because you
    make sure that each of these few baskets is strong enough.

    Twofish is fast, practically as fast as RC6 in the NIST standard
    platform, achieving about 2.2 CPU cycles per bit. It uses (or can
    use) only byte wide, "RISC-like" instructions as do several other
    candidates and is therefore efficient on 8-bit processors too.
    What he pushed is the idea that Twofish offers the best balance
    between security, speed *and* implementation flexibility. He
    showed that there are many trade-offs possible when you implement
    Twofish depending on the memory available and speed needed. For
    example there are several implementation models starting with
    almost complete "on the fly" key schedule computation with minimum
    memory and ending with the fastest versions that do a lot of
    pre-computation. This flexibility can be used not only depending
    on available memory but also depending on whether you are going to
    encrypt many or few blocks with the same key. On the whole it is a
    convincing argument, and I thought it will be an important point
    because the AES *is* going to be used in operation environments
    that are desperately different.

    The last cipher presented was SAFER+ of James Massey, one of the
    original authors of IDEA. It is based on the older SAFER designs
    with improved key schedule. A unique feature of SAFER+ is that its
    number of rounds depends on the length of user key - this was done
    for reasons related to the key setup procedure, but also, if you
    think about it, makes sense in general. This clearly is a good
    design, but on the whole one got the impression that no as much
    effort was invested in this candidate as in some of the others.
    For example much was left vague about the cipher's speed. SAFER+,
    by the way is Cylink's candidate.

    After all presentations were over, a quite substantial general
    discussion started where several points were touched:

    The AES will be available world-wide and royalty-free. Not so the
    AES candidates. One point touched was related to good AES
    candidates an application developer might want to integrate in a
    product *before* the AES is declared. He specifically mentioned as
    an example RC6 and the fact that RSA in the past have pushed their
    patents very aggressively. Ron Rivest sat through the whole
    discussion, quiet and unperturbed as a Buddha, and didn't take the
    bait. NIST of course cannot do anything in this matter - what all
    candidates had to agree beforehand is not to claim any rights on
    their cipher *if* it is declared the winner. By the way several
    candidates are already in the public domain, including Twofish,
    SAFER+ and, yes, FROG. Mars and RC6 are definitely not, at least
    not for commercial use.

    Another sticky point is the matter of patent claims on parts of
    the candidate algorithms. Somebody proposed that NIST insist that
    at least the AES candidates renounce any patent rights they may
    have on parts of other candidates' algorithms. The suggestion was
    made that NIST could actually demand this. Miles Smid was not
    enthusiastic about the idea, clearly feeling that rules should not
    be introduced on the fly. My personal opinion is that the
    technical problem of choosing the AES is already difficult enough
    and that, de facto, NIST can and should impose anything that will
    serve to bring the whole thing into a desirable end. Nobody wishes
    to have a technical competition being entangled with legal
    squabbling. (Imagine some candidate thinking: if the other guy
    wins then I shall take them to court.)

    A suggestion was made to try to device a method for comparing
    candidate ciphers in a more meaningful way. The point is that
    there is a fundamental trade-off between security and speed.
    Several candidates included a few additional "unnecessary" rounds
    in their ciphers for security's sake - Serpent went as far as to
    double them. So the suggestion was made to compare ciphers'
    security using the same number of rounds. I think this is a very
    thoughtful suggestion because otherwise we will not be comparing
    apples with apples. This was not really discussed but I think
    it will be an important point in the evaluation process.
    Maybe a better idea is not to fix the number of rounds (different
    ciphers use rounds of different complexity) but rather fix the
    speed on the standard platform. The fastest speed right now is
    about 2 CPU cycles per bit. Let's ask candidates to produce their
    fastest possible code in assembler and compare the security of
    their ciphers when they are cut down (or extended up) to 1 cycle
    per bit, 1.5 cycles, 2.0 cycles, 3.0 cycles, 5.0 cycles, 10.0
    cycles, etc. This is somehow messy - a candidate may claim that,
    Mozart-like, you cannot take anything out of his design. Also
    cipher "security" is not really something that can be measured -
    but then procedures for measuring "security" can be defined - in
    fact, roughly, most cryptographers do agree on how this should be
    done.

    An extremely interesting point came when it was announced that at
    the Crypto conference (to be held a few days later) a paper will
    be presented that shows that the method that is traditionally used
    to estimate a cipher's strength against differential attacks is
    not always appropriate. I understood this was a critique against
    some of the estimates included in the AES submissions. Amazingly,
    they claimed that they had found a differential attack against 31
    (out of the 32) rounds of Skipjack that is more efficient than
    exhaustive search. (By the way and possibly with no relation to
    the previous point, a recurrent theme throughout the conference
    was that there are many ways to define "difference".)

    On the whole everybody seemed to be quite content about the AES
    competition, its openness and levelness, and about the balance
    that NIST had reached with the requirements and with the
    organization. Significantly, the suggestion was made that NIST
    open a new competition for a standard hash function. Miles
    responded that this is a possibility and informed that there is,
    in fact, a process between NIST and IBM for defining both a PRNG
    as well as a true RNG - and that in principle people could make
    suggestions. The AES process is a competition and maybe this will
    serve as a better model for defining other wide ranging standards
    in the future - instead of the traditional way which is either by
    bureaucratic committees or imposed by the winner of the market
    game, which is not always level.

However, I have my own suspicions. They may well consider a 128-bit
keysize to be something worthy of a "toy" cipher...

but they may also consider that the complexity of at least some of the
designs, MARS for example, as being far beyond any realistic threat of
cryptanalysis. (As I've noted, I wouldn't be at all surprised if
'they' find FROG to be closer to the sort of thing they use than are
many of the other candidates.)

    This is my last report about the First AES Conference. Here I
    describe various ideas that came out of informal discussions with
    other participants. What follows is my personal understanding of
    what I heard - also I may be mixing my own ideas in the brew -
    therefore I will not mention any names.

 1. On the relative security of public key cryptography against
    symmetric key cryptography. Three very knowledgeable people, two
    of which mainly work with public key cryptography, clearly stated
    that they would be less surprised to see a cryptanalytic
    breakthrough against public key than against symmetric ciphers.
    This goes against the more prevalent view that public key
    cryptography is slower but more secure "because it is based on
    pure mathematics".

 2. On the security of symmetric ciphers. Here I got mixed
    impressions. On the one hand there is a great deal of confidence
    that the better symmetric ciphers are very strong indeed and that
    the probability that a even remotely workable attack (not a
    theoretical attack) against them will be found is almost nil. On
    the other hand the body language of the AES candidates presenters
    did (I think) reveal worry in this sense. Most added "unnecessary"
    rounds to their ciphers up to the extreme of Serpent that doubled
    them - and this in a competition where speed seems to be of great
    importance. Then again, maybe, they are only afraid of theoretical
    attacks (certificational weaknesses) that may derail their chances
    in the AES process.

 3. On the matter of the unknown attacks. This factor is coming out
    the closet - a memorable phrase was that designing a cipher is
    "like fighting against ghosts". Several presenters (AES candidates
    MARS, E2, TWOFISH) specifically discussed why their cipher may
    resist unknown attacks, SERPENT implicitly tries to defend against
    them, and, of course, FROG makes unknown attacks a central issue
    in design methodology.

 4. On the cryptanalysis of ciphers. I got the impression that modern
    cryptanalysis tries to show the strength of a cipher testing
    specific points (narrowly defined attacks) and generalizes from
    that. Even so, heuristics are often used to move the process
    forward and everybody is careful to state what an *estimate* of
    the cipher's security against this or that type of attack is.
    Differential attacks, for example, work by analyzing how
    differences in plaintexts propagate throughout the cipher - but it
    is not quite clear what the optimal definition of "difference" is
    and this can vary between different ciphers: with RC6 the
    difference with more penetrating capacity is not the traditional
    XOR but rather subtraction. E2 presents a proof of its strength
    against differential attacks but not against higher order
    differentials. The situation can become complex because one can
    imagine the existence of other complex functions (very different
    from xor or subtraction) that remain relatively invariant within
    the cipher operation and can therefore be used in a "differential"
    chosen text attack.

 5. On exotic computers that may exist in the future. It seems that
    quantum computers as far as it is understood today can at most
    optimize a linear search up to the square root of the size of the
    space to be searched. In other words, if we use a 256 bit key
    then, even theoretically, a quantum computer would need
    sqrt(2^256) = 2^128 operations to implement a search. When and if
    quantum computers become realizable a new set of mathematics will
    be developed as a framework for their computational abilities.
    Exactly as happened with classical computing, this new math will
    probably be used in cipher design too. Nor should molecular
    computers be a big worry: at most they will subtract 64 bits of
    security from a cipher. After all 2^64 molecules require a lot of
    space. So, it is algorithmic breakthroughs rather than exotic
    hardware technologies we should worry about.

 6. On the importance of speed. This I kept asking everybody about and
    I am still not very convinced. Against the "old" idea that DES is
    slow in software, in fact bit-slicing implementations are quite
    fast. 3DES achieves today speeds of approximately 120 CPU cycles
    per byte on a 32 bit computer, or 3 Mbytes per second of 400 MHz
    Pentium. (This kind of DES speed, by the way, is the standard
    against which the AES candidates will be measured). This kind of
    speed is sufficient for most personal computer applications up to
    compressed real-time video. With Moore's law still looking strong,
    in a few years time we should have the capacity of over 10 Mbytes
    per second of 3DES on a medium size PC. In the other extreme of
    the spectrum, smart cards need only encrypt a few bytes at a time
    - speed here is no big concern. So why the hurry? One response I
    got is that throughputs will also increase; if you have a channel
    of several Gbps (Gigabits per second) and you want to encrypt it
    what do you do? This seems to me a very uncommon application - for
    datastreams to arrive at this throughput it means they got
    concentrated from several sources and they should have been
    encrypted at the source; if the arrive un-encrypted at the
    concentrator then if is already too late for security. There may
    be applications where speed is really necessary - I am thinking
    about pay-per-view cable TV where one may want to encrypt each
    channel with a different password before sending it out - but
    again these are very specific and isolated cases. In fact I
    believe throughputs will *not* increase indefinitely in the
    future: even crystalline phone (or video-phone) conversation does
    not require that much throughput and the number of people and the
    number of hours per day is limited too. What I am saying is that
    speed based on advances of hardware technology probably will grow
    faster then broad-band requirements.

 7. On FROG. When I asked why should I worry about attacks that
    require 2^50 plaintexts and only rarely work I got the plain
    answer that when used with a 256 bit key this meant that FROG
    sometimes would lose some 200 bits of security. Cryptography
    abhors a flaw. Another argument I got about the long range
    prospects of FROG was that even though the idea is interesting it
    is too new and that ciphers based on older principles and designs
    represented a more conservative choice for a new standard. By the
    way, FROG is relatively fast and, my arguments against the
    importance of speed notwithstanding, speed does represent a
    relative advantage for my cipher.

 8. On the importance of memory. It is important that the AES use
    little memory in order to work well in smart cards, where RAM is
    sometimes limited to 256 bytes. Here Moore's law does not apply
    very well for the following reason: most smart card readers
    operate at relatively high voltages (3V - 5 V). A more densely
    populated chip must work at lower voltages and to decrease the
    voltage in the card becomes difficult after some point because of
    heat dissipation problems.

 9. On who the favourites are. Of course it is far to early to discuss
    this but it is being discussed nonetheless. The two "standard"
    favourites are IBM's MARS and RSA's RC6. I heard TWOFISH mentioned
    often. Personally I was impressed with E2 also, but this is a new
    cipher.

10. On whether the civilization would come to an end if somebody
    managed to break the AES in the year 2030. All thought definitely
    not - I am still worried. At the very least such a scenario would
    make the cost of fixing the Y2K bug look cheap.

    That's all. Hope to see you in NIST's FROG newsgroup. If not, see
    you in Rome next year.

--
http://www.tecapro.com
email: diane...@tecapro.com

How can you change "From address"? What are the advantages of it?
If you use ROT13 only, how can you avoid getting unwanted emails!?
Do we need a special kind of mail program or we can make it in for example
"pine"?

For example, no reasonable person could be confident that there are no
bugs in Windows 98. So one does not worry too much about it.

On the other hand, a reasonable person will (hopefully) be able to be
reasonably confident that the AES winner has no significant
cryptographic weakness. Therefore it is the subject of much 'worry'.

In other words, it is the things which we feel most confident about
that we appear *not* to be confident about at all.

This can be unfortunate, in that a non-expert (say a journalist) may
get the wrong impression if he doesn't take this effect into account.

On Wed, 26 Aug 1998 02:34:10 GMT, in
<35e36f7f.2822...@news.dial.pipex.com>, in sci.crypt

One can only be confident of cipher "strength" with respect to
specific *known* attacks.  If *unknown* attacks exist, there is no
reason to be confident at all.  Can we really say that no such attacks
can possibly exist?  

There is, of course, no absolute security, and any security system can
only be guaranteed to defend against *known* attacks.  But the contest
between offense and defense in cryptography is far worse than in
physical conflict:  At least in a military action one knows when a
base has been defeated, and also probably why.  This means one can
take action to solve that problem.  

But in cryptography, if our methods are penetrated, we probably will
not know.  This means that we have no reason to change things, and
also gain no information about what to avoid in the next design.  

This is not a problem of a "wrong impression," it is instead a real
problem which underlies all of cryptographic design, and, as far as I
can see, AES has not improved it much at all.  

The vagueness of definition for "difference" is fundamental:  There is,
I would guess, always *some* notion of "difference" under which a given
system is "weak".  To find it, construct a characteristic by subdividing
the outputs in some useful way, then find pairs of inputs that produce
the appropriate subdivisions.  Such pairs probably always exist - but
they can be completely arbitrary.  Finding them is almost certainly at
least as hard - in general - as brute-forcing the cipher.

On Thu, 27 Aug 1998 10:46:54 -0400, in
<35E5715D.ABF48...@sprynet.com>, in sci.crypt William Hugh Murray

One approach is to find some difference between two blocks which will
imply a particular key bit value with some probability.  Then, over
the course of many tests (often assuming defined plaintext), that key
bit value can be detected statistically from under the masking noise
of the random transformation.  This is essentially the detection of a
slight imbalance in the effect of a keying bit by comparing large
numbers of blocks which have a particular useful difference.  

But I suspect that *any* way one could use the comparison between two
related plaintexts (or even ciphertexts) would *also* be a form of
Differential Cryptanalysis.  

I'd go further myself, and say that the objective of a cryptanalyst is
to do anything that a given cryptosystem shouldn't let him do, whether
that be reading messages, impersonating someone, or determining that
Alice is older than Bob.

On the other hand, showing that someone could retrieve a key in some system with
2**56 chosen plaintext attacks is substantially less than finding real messages
or keys. It might be open to debate if there is any practical use for this kind
of analysis. I think there is: It will be likely to influence the result of the
AES competition.

Cryptography has expanded beyond its traditional definition as "the art
of making messages inaccessible to someone lacking the right key".
Thus, authentication, signatures, cryptographically-secure checksums,
and so on, have all come to be considered part of cryptography.

If cryptanalysis is defined as some kind of inverse to cryptography -
the art of doing what the cryptographer is trying to render impossible -
than it has naturally expanded its domain to match.

Attacks on cryptographically-secure checksums come under the modern
rubric of cryptanalysis.  Since no key at all is involved, your
definition obviously can't apply!

and he did quote me