Re: lopsided Feistel (was: cryptographic ergodic sequence generators)
At 08:28 PM 9/6/2003, John S. Denker wrote:
On 09/06/2003 02:33 PM, Tim Dierks wrote:
> I'm sure that it would be possible to design a Feistel-based block
> cipher with variable block size, supporting some range of even values
> of n.
There's no need to exclude odd n.
Of course, I'd forgotten about unbalanced Feistel networks.
Here's an updated script:
use Crypt::DES;
$n = shift @ARGV;
if (!defined($n) || $n < 2 || $n > 32 || $#ARGV > 0) {
die "Usage: $0 n\n2 <= n <= 32\n";
}
$key = pack("A8", rand());
$cipher = new Crypt::DES $key;
$tb = int(($n+1)/2);
$sb = $n - $tb;
$tmask = (1 << ($tb)) - 1;
$smask = (1 << ($sb)) - 1;
sub f($$) {
my ($round, $v) = @_;
my $pt = pack("LL", $round, $v);
my $ct = $cipher->encrypt($pt);
my ($high, $low) = unpack("LL", $ct);
return $low & $tmask;
}
sub E($) {
my ($p) = @_;
my $L, $R, $Ln, $Rn, $round;
for $round (1..2) {
$L = $p >> $sb;
$R = $p & $smask;
$Ln = $R;
$Rn = $L ^ f($r, $R);
$p = ($Ln << $tb) | $Rn;
}
return $p;
}
foreach $v (0..(1<<$n)-1) {
$o = E($v);
print "$v => $o\n";
if ($o >= 1<<$n) {
die "Too big";
}
if ($retvals{$o}++) {
die "Duplicate";
}
}
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cryptographic ergodic sequence generators?
You might also look at RC5-16. RC5 is defined on 64, 32, 16 and 8 bit words with respectively 128, 64, 32 and 16 bit block sizes. Using counter-mode as suggested by someone earlier in the thread would be the obvious way to get a sequence with a period of 2^n. The Yarrow RNG uses counter-mode as a PRNG. However in the paper they describe some effects you may want to avoid by re-keying depending on your application as the stream becomes distinguishable from random output. Adam On Sat, Sep 06, 2003 at 07:08:46PM -0400, Perry E. Metzger wrote: > Greg Rose <[EMAIL PROTECTED]> writes: > I was unaware there *were* any good 32 bit block ciphers out there, > thus the question. Certainly that would do better than most > possibilities for this, yes. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cryptographic ergodic sequence generators?
At 06:54 PM 9/6/2003, Perry E. Metzger wrote:
Tim Dierks <[EMAIL PROTECTED]> writes:
> I'm sure that it would be possible to design a Feistel-based block
> cipher with variable block size, supporting some range of even values
> of n.
Perhaps -- I don't know of a good one.
I'm not a cryptographer, so I can only make a tentative proposal, but I
believe you could make use of any secure keyed one-way function as the
function f() in a 2-round Feistel cipher and end up with a secure
construction. For example, let's use DES.
Let's say we wanted a 16-bit block cipher. Then f() must take a round # and
a 8-bit input and translate it into an 8-bit output. It doesn't have to be
a unique or reversible mapping.
Using DES, we could lay out the plaintext block as:
round # | input
with the round # in the first 32 bits and the input in the last 32 bits
(padded with zero bits), then encrypt and take the low byte of the output
as the output of f().
Thus, to encrypt a 16-bit block:
- Divide it into 2 halves, L0 & R0
- L1 = R0
- R1 = L0 ^ DES(1 | R0)
- L2 = R1
- R2 = L1 ^ DES(1 | R1)
Output = R2 | L2
This will take two DES operations per iteration, so it's not super-speedy,
but it's pretty fast for most operations. It's reversible, so you know it
will generate all values. And the construction works for any even-length
value of n. If you want, you can probably use a faster function for f(),
depending on your security requirements.
Here's a simple Perl script I wrote just to make sure I had it right:
use Crypt::DES;
$n = shift @ARGV;
if (!defined($n) || $n < 2 || $n % 2 != 0 || $n > 32 || $#ARGV > 0) {
die "Usage: $0 n\n2 <= n <= 32 && n even\n";
}
$key = pack("A8", rand());
$cipher = new Crypt::DES $key;
$hn = $n/2;
$fmask = (1 << ($n/2)) - 1;
sub f($$) {
my ($round, $v) = @_;
my $pt = pack("LL", $round, $v);
my $ct = $cipher->encrypt($pt);
my ($high, $low) = unpack("LL", $ct);
return $low & $fmask;
}
sub E($) {
my ($p) = @_;
my $L = $p >> $hn;
my $R = $p & $fmask;
my $round;
for $round (1..2) {
$Ln = $R;
$Rn = $L ^ f($r, $R);
$L = $Ln;
$R = $Rn;
}
return ($R << $hn) | $L;
}
foreach $v (0..(1<<$n)-1) {
$o = E($v);
print "$v => $o\n";
if ($o >= 1<<$n) {
die "Too big";
}
if ($retvals{$o}++) {
die "Duplicate";
}
}
This takes the length of the sequence in bits as a parameter.
This will take a while to run for any value of n much larger than 10 or so,
but I've tested it for up to n = 16 and it works fine: generates a random
ordering of the values 0..2^n-1.
- Tim
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
lopsided Feistel (was: cryptographic ergodic sequence generators)
On 09/06/2003 02:33 PM, Tim Dierks wrote: > I'm sure that it would be possible to design a Feistel-based block > cipher with variable block size, supporting some range of even values > of n. There's no need to exclude odd n. I know the typical superficial textbook describes the Feistel trick in terms of splitting each block exactly in half, but if you understand the trick you see that it works just fine for other splits. It doesn't need to be anywhere near half. It doesn't even need to be a two-way split. You could process a 21-bit word as: -- three groups of seven, or -- seven groups of three, or -- one group of twelve and one group of nine, or -- whatever. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cryptographic ergodic sequence generators?
Greg Rose <[EMAIL PROTECTED]> writes: > The characteristic you ask for is exactly that of an n-bit block > cipher in Counter Mode. For example, that's exactly why we developed > Skip32, which is on our web page; we needed an unpredictable but > non-repeating 32 bit nonce. I was unaware there *were* any good 32 bit block ciphers out there, thus the question. Certainly that would do better than most possibilities for this, yes. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cryptographic ergodic sequence generators?
[EMAIL PROTECTED] writes: > Why does it need to be strictly non repeating? For applications like block numbers in protocols, it is highly desirable to avoid overlap for as long as possible. I've noted to others on this before that for an application like the IP fragmentation id, it might be even better if no repeats occurred in any block of 2^31 (n being 32) but the sequence did not repeat itself (or at least could be harmlessly reseeded at very very long intervals). However, doing that might be even harder than producing a more standard ergodic sequence... > Is 2^n always large enough that sequences of length > 2^n are > uninteresting? I don't understand the question. > If sequences longer than 2^n are practical and *every* subsequence > of 2^n elements is free of duplicates the entire thing is periodic, > this may or may not be a problem... Re-keying is of course an option, but I'll admit that produces problems of its own. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cryptographic ergodic sequence generators?
"John S. Denker" <[EMAIL PROTECTED]> writes: > On 09/06/2003 02:09 PM, Perry E. Metzger wrote: > > For making things like IP fragmentation ids and other similar > > protocol elements unpredictable, it would be useful to have what I'll > > call a cryptographic ergodic sequence generator -- that is, a > > generator that will produce a sequence of n bit numbers such that > > there are no repeats until you pass the 2^nth number in the sequence > > (that is, the sequence is a permutation of all 2^n bit numbers) and > > such that it is very difficult to predict what the next number in the > > sequence might be beyond the fact that it will not be one of the > > numbers seen earlier in the sequence. It is also rather important > > that the generator be computationally inexpensive. > > > > Anyone know how to produce such a thing? > > Encrypted counter. I'd thought of that, but encrypting with a stream cipher would not work for this application -- it would not produce an ergodic sequence -- and encrypting with a block cipher would require that the block cipher use unusually small block sizes for many such applications. Perry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cryptographic ergodic sequence generators?
Tim Dierks <[EMAIL PROTECTED]> writes: > At 02:09 PM 9/6/2003, Perry E. Metzger wrote: > >For making things like IP fragmentation ids and other similar protocol > >elements unpredictable, it would be useful to have what I'll call a > >cryptographic ergodic sequence generator -- that is, a generator that > >will produce a sequence of n bit numbers such that there are no > >repeats until you pass the 2^nth number in the sequence. > > > >Anyone know how to produce such a thing? > > It seems to me that this could be constructed with a block cipher with > a block size n bits long by encrypting the values 0..2^n sequentially > with a random key. I've thought that. Unfortunately, I don't know that there are good block ciphers out there with 32 bit block sizes, and some uses (for example, IP fragment ids) are 32 bits. > I'm sure that it would be possible to design a Feistel-based block > cipher with variable block size, supporting some range of even values > of n. Perhaps -- I don't know of a good one. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cryptographic ergodic sequence generators?
At 02:09 PM 9/6/2003 -0400, Perry E. Metzger wrote: For making things like IP fragmentation ids and other similar protocol elements unpredictable, it would be useful to have what I'll call a cryptographic ergodic sequence generator -- that is, a generator that will produce a sequence of n bit numbers such that there are no repeats until you pass the 2^nth number in the sequence (that is, the sequence is a permutation of all 2^n bit numbers) and such that it is very difficult to predict what the next number in the sequence might be beyond the fact that it will not be one of the numbers seen earlier in the sequence. It is also rather important that the generator be computationally inexpensive. The characteristic you ask for is exactly that of an n-bit block cipher in Counter Mode. For example, that's exactly why we developed Skip32, which is on our web page; we needed an unpredictable but non-repeating 32 bit nonce. If you aren't prepared to accept the cost of a (scaled down) block cipher, then you'll have to restate your requirements. Greg. Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road,http://people.qualcomm.com/ggr/ Gladesville NSW 2111232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cryptographic ergodic sequence generators?
On Sat, 6 Sep 2003, Perry E. Metzger wrote: > > For making things like IP fragmentation ids and other similar protocol > elements unpredictable, it would be useful to have what I'll call a > cryptographic ergodic sequence generator -- that is, a generator that > will produce a sequence of n bit numbers such that there are no > repeats until you pass the 2^nth number in the sequence (that is, the > sequence is a permutation of all 2^n bit numbers) and such that it is > very difficult to predict what the next number in the sequence might > be beyond the fact that it will not be one of the numbers seen earlier > in the sequence. It is also rather important that the generator be > computationally inexpensive. > Why does it need to be strictly non repeating? Is 2^n always large enough that sequences of length > 2^n are uninteresting? If sequences longer than 2^n are practical and *every* subsequence of 2^n elements is free of duplicates the entire thing is periodic, this may or may not be a problem... -- Viktor. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: OpenSSL *source* to get FIPS 140-2 Level 1 certification
On Sat, Sep 06, 2003 at 07:33:55PM +0100, Ben Laurie wrote: > Prepare to be very surprised, then. Do you have *written* guidance from NIST/CSE that your approach is ok? (Not the testing lab, what they say don't really count in the end, and neither does what NIST/CSE say verbally.) If so can you please post that written guidance? > This is all good fun, coz I'm mandating static libraries for OpenSSL, so > that the evidential chain can be maintained (its hard to find a DSO in a > cross-platform manner so you can checksum it). If NIST/CSE is really allowing OpenSSL source code and static libraries to be validated, I should go back to them and demand the same treatment for Crypto++. Who have you been working with on the government's side? - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cryptographic ergodic sequence generators?
Perry E. Metzger wrote: For making things like IP fragmentation ids and other similar protocol elements unpredictable, it would be useful to have what I'll call a cryptographic ergodic sequence generator -- that is, a generator that will produce a sequence of n bit numbers such that there are no repeats until you pass the 2^nth number in the sequence (that is, the sequence is a permutation of all 2^n bit numbers) and such that it is very difficult to predict what the next number in the sequence might be beyond the fact that it will not be one of the numbers seen earlier in the sequence. It is also rather important that the generator be computationally inexpensive. Anyone know how to produce such a thing? How about Hasty Pudding Cipher on an n-bit block encrypting an n-bit counter? See http://www.cs.arizona.edu/~rcs/hpc/ . If 'n' is too small, I suppose you'd run into attacks like the blackjack 10-count, where you can get a little leverage if the previous picks have been randomly overconcentrated. For reasonable n that shouldn't be a problem. -- Jim Gillogly Highday, 9 Halimath S.R. 2003, 00:00 12.19.10.9.17, 7 Caban 5 Mol, Eighth Lord of Night - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: SSL's threat model
Ian Grigg <[EMAIL PROTECTED]> writes: > Does anyone have any pointers to the SSL threat model? > > I have Eric Rescorla's book and slides talking about the > Internet threat model. > > The TLS RFC (http://www.faqs.org/rfcs/rfc2246.html) says > nothing about threat models that I found. Yeah. You can kind of infer it from the security analysis at the end, but I agree it's not optimal. It's important to remember that the guy who originally designed SSL (Kipp Hickman) wasn't a security guy and doesn't seem to really have had a threat model in mind. When I write about it, generally try to summarize what I think the implicit threat model is based on my memory of the zeitgeist at the time and the characteristics of SSL. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: OpenSSL *source* to get FIPS 140-2 Level 1 certification
Wei Dai wrote: > On Fri, Sep 05, 2003 at 04:15:22PM -0400, Anton Stiglic wrote: > >>You are correct, I just saw Crypto++ in the list of FIPS 140 validated >>modules: >>http://csrc.nist.gov/cryptval/140-1/140val-all.htm >>It is the latest entry, added today. >>Congratulations to Wei Dai! > > > Thanks! Also thanks to Groove Networks (the company I work for) for > spending the money to do the validation. > > >>OpenSSL`s *source code* being evaluated remains exiting. > > > If OpenSSL source code gets validated, I'm going to be very surprised. Prepare to be very surprised, then. > NIST told us in no uncertain terms that only compiled executable code > could be validated. In fact they wouldn't even validate Crypto++ as a > static library despite an earlier verbal agreement that a static > library was ok. It had to be turned into a DLL at the last moment (i.e. > during the review phase). This is all good fun, coz I'm mandating static libraries for OpenSSL, so that the evidential chain can be maintained (its hard to find a DSO in a cross-platform manner so you can checksum it). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: OpenSSL *source* to get FIPS 140-2 Level 1 certification
Joshua Hill wrote: > On Fri, Sep 05, 2003 at 06:02:10PM -0400, Wei Dai wrote: > >>In fact they wouldn't even validate Crypto++ as a >>static library despite an earlier verbal agreement that a static >>library was ok. It had to be turned into a DLL at the last moment (i.e. >>during the review phase). > > > That's unfortunate. The answer as to the static vs dynamic library issue > seems to vary according to who at NIST reviews the report. I've never > understood NIST's general objection to static libraries. > > >>(We wanted to avoid making a DLL from Crypto++ since it has so many >>algorithms. With a static library the linker would only bring in the >>algorithms you use, but a DLL has to contain a pre-selected set of >>algorithms. I ended up putting only FIPS Approved algorithms in the >>DLL, and made a second static library that contains only >>non-Approved algorithms, so that both could be used together.) > > > So, having said that, I can say that pulling out bits of the evaluated > module won't fly. All of it would have to go in, or none of it. Further, > the module needs to have some way of checking its authenticity (for the > operating environment area requirements) and its integrity on "power up". > As such, you'll either need to be able to "locate" the module within > the resulting executable, or verify the entire resulting executable. I disagree. OpenSSL has a check of authenticity that works with static libraries and linking only some of the module. I'll shout to this list when I've written down exactly how the process works (or you can look at CVS, coz I checked it in this afternoon [err, I think, I had some weird problems with CVS later, so perhaps waiting a little might be advised]). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cryptographic ergodic sequence generators?
At 02:09 PM 9/6/2003, Perry E. Metzger wrote: For making things like IP fragmentation ids and other similar protocol elements unpredictable, it would be useful to have what I'll call a cryptographic ergodic sequence generator -- that is, a generator that will produce a sequence of n bit numbers such that there are no repeats until you pass the 2^nth number in the sequence. Anyone know how to produce such a thing? It seems to me that this could be constructed with a block cipher with a block size n bits long by encrypting the values 0..2^n sequentially with a random key. I'm sure that it would be possible to design a Feistel-based block cipher with variable block size, supporting some range of even values of n. - Tim - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cryptographic ergodic sequence generators?
On 09/06/2003 02:09 PM, Perry E. Metzger wrote: > For making things like IP fragmentation ids and other similar > protocol elements unpredictable, it would be useful to have what I'll > call a cryptographic ergodic sequence generator -- that is, a > generator that will produce a sequence of n bit numbers such that > there are no repeats until you pass the 2^nth number in the sequence > (that is, the sequence is a permutation of all 2^n bit numbers) and > such that it is very difficult to predict what the next number in the > sequence might be beyond the fact that it will not be one of the > numbers seen earlier in the sequence. It is also rather important > that the generator be computationally inexpensive. > > Anyone know how to produce such a thing? Encrypted counter. The counter provably has a cycle of 2^n. The encryption is provably 1-to-1. Choose the encryption key randomly and keep it secret. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
cryptographic ergodic sequence generators?
For making things like IP fragmentation ids and other similar protocol elements unpredictable, it would be useful to have what I'll call a cryptographic ergodic sequence generator -- that is, a generator that will produce a sequence of n bit numbers such that there are no repeats until you pass the 2^nth number in the sequence (that is, the sequence is a permutation of all 2^n bit numbers) and such that it is very difficult to predict what the next number in the sequence might be beyond the fact that it will not be one of the numbers seen earlier in the sequence. It is also rather important that the generator be computationally inexpensive. Anyone know how to produce such a thing? Perry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
USENIX Security '04 Call for Papers
USENIX SECURITY '04 - AUGUST 9-13, 2004 - SAN DIEGO, CA CALL FOR PAPERS The USENIX Security Symposium brings together researchers, practitioners, system administrators, system programmers, and others interested in the latest advances in security of computer systems. The 13th USENIX Security Symposium will be held August 9-13, 2003 in San Diego, CA. If you are working on any practical aspects of security or applications of cryptography, the program committee encourages you to submit a paper. Submissions are due at 23h59 (Pacific time) January 25, 2004. The symposium will span five days: Two days of tutorials will be followed by a two and one half day technical program, which will include refereed papers, invited talks, Work-in-Progress reports, panel discussions, and Birds-of-a-Feather sessions. IMPORTANT DATES Submissions Due: 25 January 2004 Notification to Authors: 31 March 2004 Camera-Ready Papers Due: 18 May 2004 ORGANIZERS Program Chair: Matt Blaze, AT&T / University of Pennsylvania Program Committee: Bill Aiello, AT&T Labs - Research Tina Bird, Stanford University Drew Dean, SRI International Carl Ellison, Microsoft Eu-Jin Goh, Stanford University Sotiris Ioannidis, University of Pennsylvania Angelos Keromytis, Columbia University Patrick McDaniel, AT&T Labs - Research Adrian Perrig, Carnegie-Mellon University Niels Provos, Google Greg Rose, Qualcomm Sean Smith, Dartmouth College Leendert van Doorn, IBM Research Paul van Oorschot, Carleton University Dave Wagner, University of California, Berkeley Rebecca Wright, Stevens Institute of Technology Invited Talks Co-Chairs: Vern Paxson, ICSI Avi Rubin, Johns Hopkins University SYMPOSIUM TOPICS Refereed paper submissions are solicited in all areas relating to systems and network security, including: * Adaptive security and system management * Analysis of malicious code * Analysis of network and security protocols * Applications of cryptographic techniques * Attacks against networks and machines * Authentication and authorization of users, systems, and applications * Automated tools for source code analysis * Denial-of-service attacks and countermeasures * File and filesystem security * Firewall technologies * Intrusion detection * Privacy preserving (and compromising) systems * Public key infrastructure * Rights management and copyright protection * Security in heterogeneous and large-scale environments * Security of agents and mobile code * Security of Internet voting systems * Techniques for developing secure systems * World Wide Web security Note that USENIX Security is primarily a systems security conference. Papers whose contributions are primarily in the area of new cryptographic algorithms or protocols, cryptanalysis, electronic commerce primitives, etc, may not be appropriate for this conference. REFEREED PAPERS & AWARDS Papers that have been formally reviewed and accepted will be presented during the symposium and published in the symposium proceedings. The proceedings will be distributed to attendees and, following the conference, will be available online to USENIX members and for purchase. One author per accepted paper is offered a $200 discount against the registration fee; USENIX will waive the fee for presenters for whom the fee would present a hardship. Awards may be given at the conference for the best overall paper and for the best paper that is primarily the work of a student. TUTORIALS, INVITED TALKS, PANELS, WIPS, AND BOFS In addition to the refereed papers and the keynote presentation, the technical program will include tutorials, invited talks, panel discussions, a Work-in-Progress session (WiPs), and Birds-of-a-Feather Sessions. You are invited to make suggestions regarding topics or speakers in any of these sessions via email to the contacts listed below or to the program chair at [EMAIL PROTECTED] Tutorials Tutorials for both technical staff and managers will provide immediately useful, practical information on topics such as local and network security precautions, what cryptography can and cannot do, security mechanisms and policies, firewalls, and monitoring systems. If you are interested in proposing a tutorial or suggesting a topic, contact the USENIX Tutorial Coordinator, Dan Klein, by email to [EMAIL PROTECTED] Invited Talks There will be several outstanding invited talks in parallel with the refereed papers. Please submit topic suggestions and talk proposals via email to [EMAIL PROTECTED] Panel Discussions The technical sessions may include topical panel discussions. Please send topic suggestions and proposals to [EMAIL PROTECTED] Work-in-Progress Reports (WiPs) The last session of the symposium will be a Works-in-Progress session. This session will consist of short presentations about work-in-progress
Re: OpenSSL *source* to get FIPS 140-2 Level 1 certification
> On Fri, Sep 05, 2003 at 04:05:07PM -0400, Rich Salz wrote: > > It is the first *source code* certification. > > The ability to do this runs counter to my understanding of FIPS 140-2. Sure, that's why it's *the first.* They have never done this before, and it is very different to how they (or their Ft Meade experts) have done things before. I suppose one could argue that they're doing this for Level 1 to increase the industry demand for Level 2, but I'm not that paranoid. I think they finally "get it." Also, while I don't know anything beyond what's in the public email, but based on the initial refeference platform I'll jump to some conclusions about who's involved, and they're folks with a great deal of credibility, experience, and influence in export and govt crypto issues. Anyhow, if you are interested in details, read the articles (3 at last check) in the thread from the original URL I posted. You did read before posting, right? :) /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
SSL's threat model
Does anyone have any pointers to the SSL threat model? I have Eric Rescorla's book and slides talking about the Internet threat model. The TLS RFC (http://www.faqs.org/rfcs/rfc2246.html) says nothing about threat models that I found. iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: OpenSSL *source* to get FIPS 140-2 Level 1 certification
On Fri, Sep 05, 2003 at 06:02:10PM -0400, Wei Dai wrote: > In fact they wouldn't even validate Crypto++ as a > static library despite an earlier verbal agreement that a static > library was ok. It had to be turned into a DLL at the last moment (i.e. > during the review phase). That's unfortunate. The answer as to the static vs dynamic library issue seems to vary according to who at NIST reviews the report. I've never understood NIST's general objection to static libraries. > (We wanted to avoid making a DLL from Crypto++ since it has so many > algorithms. With a static library the linker would only bring in the > algorithms you use, but a DLL has to contain a pre-selected set of > algorithms. I ended up putting only FIPS Approved algorithms in the > DLL, and made a second static library that contains only > non-Approved algorithms, so that both could be used together.) So, having said that, I can say that pulling out bits of the evaluated module won't fly. All of it would have to go in, or none of it. Further, the module needs to have some way of checking its authenticity (for the operating environment area requirements) and its integrity on "power up". As such, you'll either need to be able to "locate" the module within the resulting executable, or verify the entire resulting executable. Josh - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: OpenSSL *source* to get FIPS 140-2 Level 1 certification
Joshua Hill wrote: On Fri, Sep 05, 2003 at 04:05:07PM -0400, Rich Salz wrote: It is the first *source code* certification. The ability to do this runs counter to my understanding of FIPS 140-2. . and to experiences with the previous FIPS 140-1 certifications I was involved in, including a fairly recent communication from NIST that defines a "crypto module": it is not a statically linked library, and that it ought to be an executable or a shared library (so,dll). Second, it is unclear to me what would be tested during operational testing. The source code can't itself be a module, because the source code doesn't do anything until it is compiled and run. FIPS 140-2 currently only allows for fully functional units to be modules; you'll note, for instance, that FIPS certs for "software" modules are listed as a "multi-chip standalone" embodiment, for instance. NIST was talking about producing documents that would support a true "software only" embodiment, but that initiative seems to have stalled with the change of directors of the CMVP (the NIST group that issues FIPS 140-2 certs). Can you say that the C/asm source code is the "code" that constitutes a "module", and define compiler/linker/OS/CPU as your execution environment for FIPS 140 purposes? Think Java, for instance. I realize this is stretching too thin. and can think of lots of reasons why it can't be. But... Third, nominally, the FIPS certificate only applies to the particular operating system (and OS version) that the operational testing was done on. For level 1 modules, NIST has historically allowed OSes in the same "family" to also be covered, and they have been very liberal in their definition of "family". I have seen evidences that this restriction has become exceptionally loose, and that the "family" can be as broad as "UNIX-like" systems... - Tolga - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: OpenSSL *source* to get FIPS 140-2 Level 1 certification
On Fri, Sep 05, 2003 at 04:15:22PM -0400, Anton Stiglic wrote: > You are correct, I just saw Crypto++ in the list of FIPS 140 validated > modules: > http://csrc.nist.gov/cryptval/140-1/140val-all.htm > It is the latest entry, added today. > Congratulations to Wei Dai! Thanks! Also thanks to Groove Networks (the company I work for) for spending the money to do the validation. > OpenSSL`s *source code* being evaluated remains exiting. If OpenSSL source code gets validated, I'm going to be very surprised. NIST told us in no uncertain terms that only compiled executable code could be validated. In fact they wouldn't even validate Crypto++ as a static library despite an earlier verbal agreement that a static library was ok. It had to be turned into a DLL at the last moment (i.e. during the review phase). (We wanted to avoid making a DLL from Crypto++ since it has so many algorithms. With a static library the linker would only bring in the algorithms you use, but a DLL has to contain a pre-selected set of algorithms. I ended up putting only FIPS Approved algorithms in the DLL, and made a second static library that contains only non-Approved algorithms, so that both could be used together.) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
