Cryptography-Digest Digest #818, Volume #11 Fri, 19 May 00 08:13:01 EDT
Contents:
Re: About AES contest (Runu Knips)
Re: Open source cryptography library: BeeCrypt (Runu Knips)
Re: Matching substrings in a signature (Anders Thulin)
Re: Open source cryptography library: BeeCrypt (Bob Deblier)
Re: Q: Recording on magnetic cards (Francois Grieu)
Re: AES final comment deadline is May 15 (David Blackman)
Research assistant / PhD position Information Security available (Jaap-Henk Hoepman)
----------------------------------------------------------------------------
Date: Fri, 19 May 2000 12:27:58 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: About AES contest
Karim A wrote:
> I've read a lot of paper about AES contest and the 5 famous algorithms.
> I wonder myself, which is the best algorithm ?
> And which algo will be selected ?
> I'd like to have your opinion about it ?
Many people have discussed this in this NG, and I think we agreed more
or less that Rijndael, Serpent and Twofish are the good ones, while
Mars and RC6 should be dropped.
> Sure, you've already implemented one of them on your machine, and according
> to you, which algo is the best in terms of security, fast encryption, and
> easy software and hardware implementations.
Each of these three has some strengths over the others.
------------------------------
Date: Fri, 19 May 2000 12:34:15 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Open source cryptography library: BeeCrypt
Paul Rubin wrote:
> What does this library do that the OpenSSL library doesn't?
It is quite common now to have multiple Opensource Libraries for one
and the same purpose. So why not ? It can't make things worse, can
it ?
------------------------------
From: Anders Thulin <[EMAIL PROTECTED]>
Subject: Re: Matching substrings in a signature
Date: Fri, 19 May 2000 10:29:05 GMT
Mok-Kong Shen wrote:
>
> Anders Thulin wrote:
>
> > Wasn't that one a Bloom filter?
>
> Could you please give a pointer?
To a definition?
Perhaps http://hissa.nist.gov/dads/HTML/bloomfilt.html
To a description?
The work already cited (Jon Bentley: Programming Pearls) is probably the
best. The book itself is definitely a classic, and should be required reading
for anyone involved with programming. (I'm glad to see it's back in print again,
and in a second edition to boot).
The original article is: Bentley, J. Programming Pearls: A Spelling Checker.
Comm. of the ACM, 28, 5 (1985), 456 - 462.
I would be surprised if it is not described in Knuth, vol. 3:
Sorting and Searching.
--
Anders Thulin [EMAIL PROTECTED] 040-10 50 63
Telia Prosoft AB, Hjälmaregatan 3B, 212 19 Malmö, Sweden
------------------------------
From: Bob Deblier <[EMAIL PROTECTED]>
Subject: Re: Open source cryptography library: BeeCrypt
Date: Fri, 19 May 2000 13:25:00 +0200
Paul Rubin wrote:
> What does this library do that the OpenSSL library doesn't? And if
> you don't release source to your application that uses the library,
> how can users check whether the application has its own security bugs?
>
> Thanks.
Dear Paul,
First of all, BeeCrypt is not an SSL solution. My company wanted to have a
toolkit in which every aspect of cryptography is accessible, usable and
fast. When work started on this library, nothing was available which could
be used commercially. Commercial libraries were (and still are) very
expensive, work on few platforms, and in general are slow as molasses. So
I started writing a cryptography library for my company - using lots of
reference material on the web and in text books. The results are what you
find in the library - and more is waiting to be added in.
As to why the source of the application is not released, there are a couple
of reasons:
- time constraints: we have a small team of developers, working hard to
deliver a product which is currently in beta test; publishing the code and
documenting it for general release would take too much time.
- intellectual property: we have quite a number of inventions tucked away
inside the application source code - and sorry, we're not going to give
those away for free. It's what's makes up our paychecks at the end of the
month ;)
What we aren't saying is: trust us, we know what we're doing. What we are
saying is: judge us by what we have published, and by our actions and
intents.
What we are doing and are going to do, to try and establish a base of trust:
- publish the cryptography routines in this library, so that everybody can
examine if they're flawed.
- document the protocols (which use well-known methods like DHAES and
SRP) used by our software, and publish them on our website.
- publish more of the source by expanding the beecrypt library with more of
the routines which still reside in the application, but can safely be
transferred to the library
- make sure we don't have any buffer overflows in the communication layers!
- have an independent agency do a security auditing of the software.
Any recommendations you may have as to how we can make further steps towards
reaching that level of trust we aim to establish are more than welcome.
Sincerely
Bob Deblier
System Engineer
Virtual Unlimited
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Q: Recording on magnetic cards
Date: Fri, 19 May 2000 13:30:44 +0200
<[EMAIL PROTECTED]> wrote:
> How is it possible that the update action (presumably with a
> relatively strong magnetic field) on the paying card has no
> interference on the neighbouring credit cards
First, the write field used for magnetic cards is very concentrated,
and decreases quicly with the distance, something like F(d) = (d0/d)^2
with d0 say like 0.1 mm
Second, many systems only read a serial number on the card, and store
the balance of the card's account in a database external to
the card, with the benefits that
- the account can be reloaded without using the card
- if the card is lost, is can be blacklisted and replaced without
loosing the balance
Francois Grieu
------------------------------
From: David Blackman <[EMAIL PROTECTED]>
Subject: Re: AES final comment deadline is May 15
Date: Fri, 19 May 2000 21:46:18 +1000
Scott Contini wrote:
> RC6 can run on smart cards having as little as 128 bytes of RAM.
> Keating showed this at the 2nd AES conference. Certainly it doesn't
> perform great on such smart cards, but for many applications it is
> good enough.
>
> Scott
Serpent, Rijndael, and Twofish all run in under 64 bytes of RAM.
Considering that the application might want a few bytes for other
purposes, and that the cheapest MCUs have 128 bytes of RAM or less, i
think that gives them a significant advantage for low end embedded
applications. (Whether low end embedded crypto is a good idea is another
question. But it was specifically mentioned in the AES rules, so it will
certainly be considered in the judging.)
Serpent, Twofish, and perhaps Rijndael, are looking best by other
criterion as well. Lets look at it:
Performance on high end custom hardware:
1. Rijndael
2. Serpent
3. Twofish
Key agility (on Pentium 2? I'd like to know for custom hardware where
it's more important):
1. Rijndael
2. RC6
"Security margin" (a dubious idea, but about all we have to go on for
security)
1. Serpent
2. Twofish
Speed on Pentium 2 and similar:
1. RC6, Rijndael, Twofish about the same
4. Mars
5. Serpent
Speed on anything else:
Different to the above. Serpent often gets much better, RC6 and Mars
usually get worse.
Looking at the cryptanalysis attempts so far, it's clear that Rijndael
and RC6 are very close to having theoretical breaks. Perhaps Mars as
well, depending what you thing of the importance of the various
different rounds. It's hard to imagine those breaks having much
practical significance, since even if they are extended the extra few
rounds required, they need ridiculous quantities of chosen or known
plaintext. But in something you are going to commit to for decades, it
would make you just a bit nervous.
With Rijndael or RC6 adding a few rounds is easy and should help
security. Maybe AES will do that if they like other aspects of those
cyphers. (This is also true for Serpent and Twofish, but it isn't clear
that they need more rounds.)
It's not immediately obvious how to add rounds to Mars, and you'd
probably want to put it through lots of analysis afterwards if you did,
so i hope they don't try that.
Mars has another minor security worry. They changed the key schedule
after AES round 1 (to make smartcard implementations easier). This means
that Mars in its current form has had less time for detailed scrutiny
than the other 4.
Quite a few experts have criticised various aspects of the Twofish
design, but they've had remarkably little success turning these
"weaknesses" into actual breaks, even theoretical ones. Even reduced
round variants of 7 rounds have survived so far. (Twofish has 16
rounds.)
There seem to be no serious security doubts about Serpent.
------------------------------
From: Jaap-Henk Hoepman <[EMAIL PROTECTED]>
Crossposted-To: comp.theory,nl.comp.crypt,comp.security.misc
Subject: Research assistant / PhD position Information Security available
Date: 19 May 2000 13:54:40 +0200
The University of Twente, Faculty of Computer Science, the Centre for
Telematics and Computer Science (CTIT) is looking for a
RESEARCH ASSISTANT ON INFORMATION SECURITY
to participate in the SUMMER project.
In SUMMER, one of the CTIT projects, the CTIT cooperates with Dutch Telecom
(KPN), Centre for Mathematics and Computer Science (CWI), V2 Labs (Dutch Media
Institute), and the Ministry of Transport. Goal of SUMMER is to develop a
Secure Multimedia Retrieval system, in particular to give access to the large
set of multimedia archives of the Dutch Photography Institute and the Dutch
Movie Museum, and to perform traffic video data analysis for the Dutch Ministry
of Transport.
The security component of the SUMMER project focusses on the following three
topics:
- the long term availability and security of a multi-media database,
- the use of commercial-of-the-shelf (COTS) components in the construction of
secure systems, and
- tools and techniques to do copyright/content protection (e.g. watermarking,
protected media-players, etc).
Requirements
We are looking for a computer scientist with an interest in security and/or
cryptology, who likes to do research and has good programming skills.
Offer
We offer a position as a research assistant for a period of 2 years, to work on
this project as the main person responsible for the security research
contributed by the faculty. We will consider an extension of the position to
allow the candidate to obtain a PhD, depending on the skills of the candidate
and the project results.
Information
For more information about this position, please contact dr. Jaap-Henk Hoepman,
University of Twente, phone: +31 53 489 3795 (e-mail: [EMAIL PROTECTED]),
or prof.dr.ir. T. Krol, University of Twente, phone: +31 53 4894173 (e-mail:
[EMAIL PROTECTED]). Vacancynumber 00/103.
For more information, consult the official announcement at
http://www.utwente.nl/vacatures/1/3/1/015.shtml
--
Jaap-Henk Hoepman | Sure! We've eaten off the silver
Dept. of Computer Science | (when even food was against us)
University of Twente | - Nick Cave
Email: [EMAIL PROTECTED] === WWW: www.cs.utwente.nl/~hoepman
PGP ID: 0xFEA287FF Fingerprint: 7D4C 8486 A744 E8DF DA15 93D2 33DD 0F09
------------------------------
** 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
******************************
