Re: DCSB: Risk Management is Where the Money Is; Trust in Digital Comm

> The full cost of revocation testing is proportional to the square of > the depth of the issuance hierarchy. In other words, this exceeds the > intellectual capacity of most certificate recipients. This means that > most recipients cannot themselves rely on the security technology to > establish

re: my two cents

From: "Perry E. Metzger" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: my two cents > The new Wassenar abomination has to be the end of this, one way or > another. Easy to say, but arrangments for the obliteration of cryptography controls might be harder to manage. :) I suspect more an

Text of Wassenaar regulations, with comments

> Web version: > http://www.fitug.de/news/wa/ > > Word- or RTF-version: > http://www.wassenaar.org/List/ Here are the contents of Category 5, Part 2, of the Wassenaar list, which controls information security. It has been converted to text, somewhat clumsily, so pay attention to the use of nu

Re: CRYPTO-GRAM, December 15, 1998

> Okay, I finally got the story right about Network Associates Inc. and the > Key Recovery Alliance. (Last month I pointed to a Wired News story that > they quietly rejoined.) The story is wrong. They never left the KRA. > Since its inception, Trusted Information Systems was a big mover and sha

IDEA exportable? was Re: triple DES

At 01:11 PM 12/31/98 +1100, Greg Rose wrote: >It was Phil Karn, I've seen the form. He was trying to export a VPN box >of some kind to the QUALCOMM office in Singapore. They did allow IDEA, >eventually. Phil thinks that allowing a 128-bit algorithm but not 112-bit >3des was some sort of mind g

Matrix based variant on RSA

> William Whyte at Baltimore Technologies in Dublin -- > where Sarah Flannery worked recently and got a > boost from the cryptographers there -- gave a brief > rundown on her invention on mail list UKCrypto. > There's a copy of his remarks at: > >http://jya.com/flannery.htm There we find

Re: Mailinglist programs with PGP-encryption?

> Jukka E Isosaari <[EMAIL PROTECTED]> writes: > Are there any mailinglist programs that would let the > subscribers to give a public PGP-key for encrypting all the list > e-mails when subscribing, and that would also handle them > automatically? Of course there is. We use John Perr

Re: A different take on Intel's RSA announcements

Tom Weinstein wrote: > Rob Lemos wrote: > > > http://www.zdnet.com/zdnn/stories/news/0,4586,2189721,00.html > > This just seems like FUD to me. ID numbers should help detect theft > and fraud. They aren't going to compromise privacy. I expect it's > going to behave just like the debugging re

Re: FC: More on Network Associates and its crypto-politics

Declan McCullagh writes: >TIS supports export controls on encryption products. My article: > http://www.well.com/user/declan/pubs/cwd.shadow.cryptocrats.0298.txt Two problems here. First, you are using the present tense in saying that TIS "supports" export controls, but your article is from nin

Re: Strengthening the Passphrase Model

Arnold G. Reinhold writes: > 1. PGP should suggest a passpharse to the user when a new key pair is > generated. PGP already has a trusted source of randomness. Why not offer a > passphrase? There could be a choice of formats --Diceware words, random > syllables, random letters -- and strengths (

Re: Using crypto to solve a part of the DNS/TM mess

Michael Froomkin writes: > Suppose we move to a system of Domain Name registrations in which people > can be anonymous, or pseudonymous, but at the same time wish to have some > way of identifying the people engaged in large-scale domain name > speculation. Are these ends compatible?

Re: Crypto for some of the DNS/TM mess

Ben Laurie wrote: > Anna Lysyanskaya wrote: > [...] > > Or we may insist that the CA gives out only one > > credential of validity per user, and then anyone can determine which set > > of domains belong to the same user. > > Surely this is where it all falls apart? You can insist all you like, >

Re: Crypto for some of the DNS/TM mess

> > The setting in the physical world: > > - > > 1. There is a trusted center that is able to verify the physical identity > > of whoever approaches it. The first time an individual approaches the > > system, the cost of this might be high (however I don't see how t

Re: Crypto for some of the DNS/TM mess

> The basic problem is that chaumian credentials are transferable. > People who have no use for them will be able to sell them for a few > £s, and domain name speculators will be happy to buy them. Someone > who is willing to speculate $70 each on hundreds of domains can easily > afford to buy a

Re: Crypto for some of the DNS/TM mess

ents about colluding with others to register in multiple names apply equally to the current system. No system can prevent this. Hence this point is irrelevant in considering whether the current DNS registry should be replaced by a pseudonymous one. The original concern about anonymous/pseudonymous

Police Want Keys to Decode Private E-Mail

Electronic Telegraph, Issue 1380, Saturday 6 March 1999 Police Want Keys to Decode Private E-Mail By Robert Uhlig, Technology Correspondent The Government was accused yesterday of rushing through legislation that could allow it unprecedented powers to access and decrypt any person's private e-ma

Re: new bill getting through congress?

> Unfortunately the bill doesn't go far > enough, in that individuals are left out in the cold: it's essentially > for the Microsofts and Netscapes of the industry to be exportable. Everyone always says this, but no one ever says why. Let's keep in mind that we're talking about software. The qu

Re: Intel & Symantec v. ZKS?

William H. Geiger III writes: > One has to wonder if this is the actions of a company that is trustworthy > enough to supply RNG's to the community. IMHO it is not and I sincerely > hope support for the PIII is *not* included in /dev/random and/or IPSEC. I > will not be adding any support code in

How to donate a clue to a lawyer?

At 10:37 AM 5/7/99 -0500, Elyn Wollensky wrote: >Here's Lance Rose's take on the Bernstein decision: >Sorry to say, but the 9th Circuit took the dumb approach I mentioned in my >earlier post. >    Their whole approach to "source code as speech" is misguided - >unless we are talking about >pe

Re: 1,000 Free Crypto Sites

Bill Sommerfeld <[EMAIL PROTECTED]> wrote: > A posting by Cindy Cohn, one of Bernstein's legal team, to cyberia-l, > archived at > > http://www.ljx.com/mailinglists/cyberia-l/20266.html > > suggests that it would be premature to create such sites. > > She writes: > > First, the decision

No Subject

[This just arrived in the list inbox. I'm not exactly sure that it is particularly interesting, accurate or informative, but unfortunately because it arrived anonymously I'm not really in a position to ask for an improved version. Anyway, I decided to forward it. --Perry] -- Forwarded mes

No Subject

-- Forwarded message -- >Subject: Crypto Equipment Guide -- Part Three of Three >Date: Mon, 17 May 1999 16:10:30 -0500 SECURE TERMINAL EQUIPMENT Secure Terminal Equipmet (

Re: ICSA certifies weak crypto as secure

In message , "Arnold G. Reinhold" writes : > > It is also desirable to be able to increase the memory footprint of your > key stretcher as well its iteration count. That's far from clear. More or less any reasonable factor is dwarfed by the rapid expansio

Re: Why plaintext cryptographic status messages must be out of band

> What MS Outlook appears to do is display status information about > signature checking on messages in the mail message frame itself, > indistinguishable from ordinary text. The obvious attack is to send > a user unsigned mail (it could be encrypted, to add additional > legitimacy to the att

Re: personal encryption? (fwd)

>-- Forwarded message -- >Date: Wed Jun 09 17:27:24 EDT 1999 >From: [EMAIL PROTECTED] >To: [EMAIL PROTECTED] >Subject: personal encryption? > > >http://news.bbc.co.uk/hi/english/sci/tech/newsid_365000/365183.stm > >Wednesday, June 9, 1999 Published at 19:04 GMT 20:04 UK > >Sci/Tech

MPI & Modular Arithmetic

Hi Folks, I would like to know if anyone of you know where I could find a free (commercial and non-commercial) implementation of a Multiprecision Integer and modular arithmetic ? Regards, Hans... N.B: Documents and other info are also welcome!

SWEDEN: USA industrial espinoage against the wall

(sorry but I haven't a scanner, OCR software, and translation software available, so I will post a very short translation by myself. If possible I could possibly scan the article later) - In the paper Datateknik (www.datateknik.se) issue 10 1999 there is a repotage about Swedish goverments & auth

Password theft insurance...

At 2:00 AM -0400 on 6/14/99, [EMAIL PROTECTED] wrote: > Title: Daitokyo Fire & Marine Insures EC Shopping Malls... > Resource Type: News Article > Date: June 11, 1999 > Source: AsiaBizTech > Author: Nikkei Multimedia > Keywords: E-COMMERCE ,INSURANCE ,FRAUD/THEFT ,BUSINESS PRACT >

Re: MPI & Modular Arithmetic

At 08:32 AM 6/14/99 -0400, Hans Viens wrote: >I would like to know if anyone of you know where I could find a free >(commercial and non-commercial) implementation of a Multiprecision Integer >and modular arithmetic ? There's a GNU Multi-Precision Integer package; look for the usual GNU archive

NDSS 2000 SUBMISSION DEADLINE EXTENDED TO JUNE 23RD

The Internet Society's Year 2000 Network and Distributed System Security Symposium (NDSS 2000) deadline for submissions of technical paper and panel proposals has been EXTENDED TO JUNE 23RD due to the large number of requests for an extension and the desire to accomodate people. The complete Cal

hushmail security

Hushmail seems like a good idea, but there is (at least) one area where its security could be improved. (For a description of the system see http://www.hushmail.com/tech_description.htm.) The problem is that users are not given sufficient protect against a trojan horse client applet, one that for

freedrive

you know, this is either a very convenient dead drop or it has that characteristic that makes "agencies" put up anonymous re-mailers -- both are vehicles likely to concentrate interesting material... --dan --- Forwarded Message Date: Thu, 10 Jun 1999 15:23:23 -050

Re: hushmail security

Wei Dai, <[EMAIL PROTECTED]>, writes: > Hushmail seems like a good idea, but there is (at least) one area where its > security could be improved. (For a description of the system see > http://www.hushmail.com/tech_description.htm.) The problem is that users > are not given sufficient protect again

RE: freedrive

Sent: Monday, June 14, 1999 10:11 PM To: [EMAIL PROTECTED] Subject: freedrive you know, this is either a very convenient dead drop or it has that characteristic that makes "agencies" put up anonymous re-mailers -- both are vehicles likely to concentrate interesting material... --dan --

Interoperable Micropayment Order

Jim and all: I'm happy to inform you that following your (Jim's) prompting, in the last face to face meeting of the W3C Micro Payments working group held today, the group accepted my proposal to proceed directly to define an Interoperable Micropayment Order. We seem to have reached already subst

RE: freedrive - how to make a really secure one

Tom says, >... They even say that your information is "safe": > "Your personal life is safe with us. Many advanced security >... > Although these services are free, I believe that the phrase "Trust no one" > applies in these cases. actually, one of the services we hope to see happen usi

Kryptos Sculpture

John Markoff wrote up my break of the cipher on the Kryptos sculpture that's been puzzling people at the CIA for most of the decade. It's in today's New York Times Technology section on-line. There are still 97 characters left to break -- I hope somebody will finish the job so we can move on to

Jim Gillogly's break of the Kryptos sculpture cryptogram...

The Times article about Jim's break of the Kryptos sculpture cryptogram is at: http://www.nytimes.com/library/tech/yr/mo/biztech/articles/16code.html Perry

Re: hushmail security

At Wed, 16 Jun 1999 08:57:25 -0400, "Arnold G. Reinhold" <[EMAIL PROTECTED]> wrote: >The applet source is available from the HushMail site. I am not aware of >any additional restrictions on a local applet or any way for HushMail to >tell the difference. On the contrary, you could convert their so

Re: hushmail security

Bill Frantz <[EMAIL PROTECTED]> wrote: > There are several possibilities here: > > (1) If the Applet runs without it's surrounding web page, you can run it in > the applet runner. The applet runner allows you to set the security > parameters to allow web access. This much I've got working. How

Re: hushmail security

At 2:52 PM + 5/31/16, [EMAIL PROTECTED] wrote: ... > >Given that your passphrase is the only thing that keeps the server >from knowing your private key, the system is relying very heavily on >users choosing good passphrases. While salt does help against >dictionary attacks, it is really impor

Re: hushmail security

At Thu, 17 Jun 1999 11:35:42 -0700 (PDT), Sameer Parekh <[EMAIL PROTECTED]> wrote: >> this. SSL is a bitch (which is presumably why the applet doesn't use >> it). > SSL is a bitch for good reason. OK, but it is possible that some of those reasons wouldn't apply to hushmail, where both end

SAFE makes it out of committee, but not unscarred...

SAFE makes it out of committee, but not unscarred... http://www.computerworld.com/home/news.nsf/CWFlash/9906174crypto

permutations

Consider a cipher in which the key size and block size are equal, such as AES-128. The key specifies a pseudo-random permutation of the plaintexts, producing a ciphertext. We know it's a permutation, because ciphertexts and plaintexts are one-to-one, given a key. It's not necessarily true, howe

Re: permutations

if keys > 1, then you have in essence just whacked bits off the key size. Unless you asked your question oddly and missed your intent, I can't see any value in keys>1. > >What are the pros/cons of having only one key take a given plaintext to >a given ciphertext? >-- >Mike Stay >Cryptographer

Re: permutations

Sure, that's a pro to having one key per plaintext/ciphertext pair. A con might be that you only need one known plaintext block (with unlimited computing power :) to determine the key. Are there any others I'm missing? gw-terisa wrote: >if keys > 1, then you have in essence just whacked bits o

Re: permutations

In article <[EMAIL PROTECTED]>, Mike Stay <[EMAIL PROTECTED]> wrote: > Consider a cipher in which the key size and block size are equal, such > as AES-128. The key specifies a pseudo-random permutation of the > plaintexts, producing a ciphertext. [...] It's not > necessarily true, however, that

Re: Could Open Source Software Help Prevent Sabotage? (fwd)

Zombie Cow <[EMAIL PROTECTED]> writes: >http://linuxtoday.com/stories/6876.html > >Could Open Source Software Help Prevent Sabotage? >Jun 18th, 11:07:50 > >Imagine a Chinese agent working at Microsoft. How difficult do you think it >would be to insert a little "backdoor" into a Windows .dll file

RE: Could Open Source Software Help Prevent Sabotage? (fwd)

> -Original Message- > From: David Jablon [mailto:[EMAIL PROTECTED]] > Subject: Re: Could Open Source Software Help Prevent Sabotage? (fwd) > > Access to "the source code" may also give a false sense of security. > "The source" might not be the full, complete, and exact code > used t

Re: Could Open Source Software Help Prevent Sabotage? (fwd)

Will Rodger writes: > Zombie Cow quoted an interesting letter to the editor which posited the > following: > > >Imagine a Chinese agent working at Microsoft. How difficult do you think > it would be to insert a little "backdoor" into a Windows .dll >file or > somewhere else? With the Govern

Re: Could Open Source Software Help Prevent Sabotage? (fwd)

David Jablon writes: > Access to "the source code" may also give a false sense of security. > "The source" might not be the full, complete, and exact code > used to produce the commonly available object, and thus might not > reveal the threating features. People in the OpenSource movement te

RE: Could Open Source Software Help Prevent Sabotage? (fwd)

-- At 03:01 PM 6/21/99 -0400, Michael Cervantes wrote: > Most open source software is distributed in a tar file with > just makefiles, docs, and source. You compile the object > directly from the source code that is provided. However, > binary packages are becoming more common as package

CHES Accepted Papers

We are pleased to announce the following papers will appear at the Workshop on Cryptographic Hardware and Embedded Systems. Information about the conference is found at http://ece.wpi.edu/Research/crypt/ches. A. Shamir Factoring large numbers with the TWINKLE device J. H. Silverman. Fast multi

Re: personal encryption? (fwd)

-- At 04:39 PM 6/22/99 -0400, Dan Geer wrote: > >Do you imply having a machine with PCR's for some unique >string in the authenticator's DNA? I see two problems. >First, twins. Second, it's possible to grow DNA from >fingernail clippings, hair, etc. It would be like >

Bridge

The following is a message I originally posted to coderpunks. The article it refers to can be found at http://www.iacr.org/newsletter/curr/bridge.html The last IACR newsletter mentions that bridge tournaments are having trouble generating random deck shuffles, and suggests that the cryptographic

Re: Bridge

> > There are 52! bridge hands, so a random hand has > > log2(56!) = 226 bits of entropy or 68 decimal digits worth. Are they > > generating that much entropy per hand now? If so, how? > > Generating that much entropy would be pointless. All that's needed is > enough entropy to be unguessable in

DSA sign only

Hi, I'm working with Elgamal public Key algorithm for encryption only. Now, I need to generate a signature with DSA (signature only). Do I have to calculate all the parameters (p, q, g, y, x ...) or is it possible to use parameters already calculate in Elgamal algorithm ? Best regards, Hans

ElGamal without exponent reduction?

Hi, suppose we use an ElGamal-variant where we do not need to compute inverses modulo the group order. Such variants exists and they are explained in the Handbook of Cryptography, for instance, let G: generator a: secret value A: public value G^a and for the signature

Re: Bridge

With all due respect, I think many posters are missing the point. From a cryptographic perspective, the problem is *easy*. The hard part is the verifiable procedures, hardware, and software. That's why gross physical randomness is so attractive to lotteries -- anyone can see (to a first approxi

RE: Bridge

> -- > From: Arnold G. Reinhold[SMTP:[EMAIL PROTECTED]] > > I am still not clear as to what the hard issues are. > > Nor am I. In fact, I can't help but wonder if this is a case where computers (which are effectively black boxes which users are asked to trust) are the wrong a

Re: Bridge

> > There are 52! bridge hands, so a random hand has > > log2(56!) = 226 bits of entropy or 68 decimal digits worth. Are they > > generating that much entropy per hand now? If so, how? > > Generating that much entropy would be pointless. All that's needed is > enough entropy to be unguessable in

RE: Bridge

One has to remember that people come to bridge matches to play bridge, not crypto games. Computers are a pretty good solution. The hands have to be recorded and published in any case, so the added work in making up hands that match the printout is balanced by not needing to key in the delt hands.

Stego patent

>From EE Times: http://www.eet.com/story/OEG19990622S0026 Algorithm hides data inside unaltered images By R. Colin Johnson EE Times (06/22/99, 4:29 p.m. EDT) ORONO, Maine Information can be hidden inside images without altering their appearance, according to University of Maine professor Ric

so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)

> Title : DES Applicability Statement for Historic Status > Author(s) : S. Bradner, W. Simpson > Filename: draft-simpson-des-as-01.txt > Pages : 8 > Date: 22-Jun-99 > > 'The PPP DES Encryption Protocol' [RFC-2419], 'The

elliptic curves -- libraries / patent issues

Are there any elliptic curve systems and parameter sets which it is possible to use on a world wide basis? IEEE P1363 curves and parameters? Are there libraries licensable worldwide which implement any of these? Are there freeware or other licensed libraries? I am aware of Wei Dei's crypto++ v

Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)

Jeff Schiller writes: > Actually for the TLS crowd, going to DES is a step up. It is a step up -- right now, of sorts. But in 10 years time it will look like a step up from ROT-13 to ROT-n (where you have to guess n). Lucky is right on the money, as usual: > DES or RC4-40 have no business be

Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)

In <[EMAIL PROTECTED]>, on 06/25/99 at 10:29 AM, "Jeffrey I. Schiller" <[EMAIL PROTECTED]> said: >Ben Laurie wrote: >> OpenSSL has them disabled by default. But I am torn on this question: >> these new ciphersuites give greater strength than existing ones when >> interopping with export stuf

Word needed for Entropy

I've been guilty of sloppy use of English, occasionally, and one such sloppiness that I run into occasionally is with the word "entropy" for cryptographic purposes. What we need is a word or very short phrase to capture the full phrase: "the conditional entropy of a measurement given all the inf

Lots of thoughts on bridge

way of doing that is to treat the stream generated by the original seed as a series of seeds for individual hands, that way it takes about the same amount of time to generate any hand number, no matter how late it is. Some anonymous person posted code for generating shuffles based on RC4. Unfor

Re: Word needed for Entropy

Carl Ellison wrote: > I've been guilty of sloppy use of English, occasionally, and one such > sloppiness that I run into occasionally is with the word "entropy" > for cryptographic purposes. > > What we need is a word or very short phrase to capture the full > phrase: > > "the conditional entro

Re: Lots of thoughts on bridge

At 12:52 PM -0700 6/26/99, bram wrote: >I suggested earlier >that five bits can be encoded in a single character by using letters and >digits without 0,O,6 and G. We found the risk of confusing 1 and l greater that the risk of confusing 6 and G. I agree about 0 and O. YMMV ---

RE: Padlock Size was Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)

> -- > From: Steve Mynott[SMTP:[EMAIL PROTECTED]] > On Sat, Jun 26, 1999 at 01:09:36PM -0400, Nelson Minar wrote: > > > The point is that in Netscape, it is very hard to tell if a given link > > is 40 bit or 128 bit. Sure, with enough poking around looking at page > > info you

[Dave Farber ] IP: here's a switch! -- Hong Kong Police Calls For Stronger Encryption To Fight Hackers

>From Dave Farber's list. The formatting is a bit mangled, but it seemed interesting. Date: Mon, 28 Jun 1999 13:38:05 -0400 To: [EMAIL PROTECTED] (David Farber) From: "Richard J. Solomon" <[EMAIL PROTECTED]> Hong Kong Police Calls For Stronger Encryption To Fight Hackers HONG KONG, CHIN

Re: Eason/Kawaguchi stego

Bill Frantz writes: > It seems to me you could use an existing public key infrastructure, e.g. > PGP, but build a different message format with the stego requirements in > mind. Off the top of my head (using PGP 2.6): > > (size, data) > (256, key) - RSA encrypted key padded with pseudo-random pa

Re: stealth, stego & pgp

Adam Back writes: > The other kind of stego key is where the stego algorithm has a key to > guide the dispersal of data in the target data. (Eg select which n of > m possible bits in the LSBs of an image file to replace with the > message). This is very different. First, this is not an "other k

No Subject

At 08:09 PM 7/7/99 -0500, William H. Geiger III wrote: >Well it's only DES which we all know can easily be broken. Doing weak >crypto really fast is not all that impressive to me. That's because you're trying to write, not read. Get it? Les Fedz

Re: stealth, stego & pgp

Bodo Moeller writes: > Adam Back <[EMAIL PROTECTED]>: > > > On how to stego pgp messages. First you have to ensure that the data > > you are stegoing has a rectangular distribution [...] > [...] > > It might be nice to update stealth-2 for openPGP / pgp5. There you > > have the additional task

Re: linux-ipsec: Re: TRNG, PRNG

John Denker writes: > 1b') When the pool is depleted, /dev/urandom acts like a PRNG but reseeds > itself in dribs and drabs as TRNG entropy becomes available. This leaves > it vulnerable to an iterated guessing attack. The question is whether this is a realistic attack. > 2a) Suppose some p

Re: linux-ipsec: Re: TRNG, PRNG

John Denker writes: > That is: > 1a') When there is entropy in the pool, it gobbles it all up before > acting like a PRNG. Leverage factor=1. This causes other applications to > stall if they need to read /dev/random. This does not seem to be a big problem, and in fact is arguably the right b

No Subject

On Sun, 25 Jul 1999, John Kelsey wrote: > Has anyone looked at this from a cryptanalytic point of > view? I think there are chosen-input attacks available if > you do this in the straightforward way. That is, if I get > control over some of your inputs, I may be able to alternate > looking at y

Re: Summary re: /dev/random

Sandy Harris writes: > Conclusions I've reached that I hope there's agreement on: > > More analysis is needed, especially in the area of how > to estimate input entropy. > > (Yarrow does this quite differently than /dev/random. > I'm not convinced either is right, but I've nothing > else to propo

Re: linux-ipsec: /dev/random

John> The point is that there are a lot of customers out there who John> aren't ready to run out and acquire the well-designed hardware John> TRNG that you alluded to. So we need to think carefully about John> the gray area between the strong-but-really-expensive solution John> and the cheap

Linux /dev/random entropy estimates

Entropy estimation in /dev/random (and /dev/urandom) Linux /dev/random adds randomness from the environment and estimates the entropy it gains by doing so. Entropy is a measure of the uncertainty which an outside observer would have over the internal RNG state (called the "random pool" in /dev/r

linux-ipsec: Re: Summary re: /dev/random

Ted Ts'o writes: >Date: Tue, 10 Aug 1999 11:05:44 -0400 >From: "Arnold G. Reinhold" <[EMAIL PROTECTED]> > >A hardware RNG can also be added at the board level. This takes >careful engineering, but is not that expensive. The review of the >Pentium III RNG on www.cryptography.

Re: linux-ipsec: Re: Summary re: /dev/random

Paul Koning writes: > The most straightforward way to do what's proposed seems to be like > this: > > 1. Make two pools, one for /dev/random, one for /dev/urandom. The > former needs an entropy counter, the latter doesn't need it. > > 2. Create a third pool, which doesn't ned to be big. That's

RE: linux-ipsec: Re: Summary re: /dev/random

> > > Except that if you are paranoid enough to be worried about some > > > unknown entity flooding your machine with network packets to > > > manipulate the output of /dev/urandom, you are likely to not > > > trust Intel to do RNG in such a way that it can't be fooled with. > > > > And if you're

Re: NSA key in MSFT Crypto API

Wired.com: > "The key is a Microsoft key -- it is not shared with any party including > the NSA," said Windows NT security product manager Scott Culp. "We don't > leave backdoors in any products." > > "The only thing that this key is used for is to ensure that only those > products that meet US e

Re: Paul Brown on Solitiare randomness flaw?

[I have my doubts about the reality of this description -- the entire stego description seems like fantasy, especially given the low bandwidths available into many countries, and the obviousness of the whole thing. However, I'm forwarding it in spite of my bogometer beeping... Caveat Lector... --P

Re: Paul Brown on Solitiare randomness flaw?

> Perry writes: > I have my doubts about the reality of this description -- the > entire stego description seems like fantasy, especially given the > low bandwidths available into many countries, and the obviousness > of the whole thing... I think that you misunderstand the purpose o

Re: Intel RNG

Bram writes: > Paul Kocher has said the design looks sound, which I believe, but > unforotunately the raw output of Intel's RNG just plain can't be accessed > without it going through whitening first. Unsurprisingly, all the output > passes all statistical tests. Well, duh, it's been sent through

No Subject

Washington Post, Friday, 17 September 1999, Page A1 Curbs on Export of Secrecy Codes Ending By Peter S. Goodman and John Schwartz Washington Post Staff Writers The Clinton administration yesterday handed the nation's technology industry the long-sought right to freely export software that cloaks

Constitution Week announced along with crypto re-controls.

... thought there was a certain irony in this appearing on the same link as mentioned below: "NOW, THEREFORE, I, WILLIAM J. CLINTON, President of the United States of America, do hereby proclaim September 17, 1999, as Citizenship Day and September 17 through September 23, 1999, as Constitution We

Ecash without a mint

is revealed which is common to the two. During withdrawal only f(r,x) is revealed, and during deposit only x is revealed. This makes the system completely anonymous, giving the effect of blind signatures without blinding or signatures! The issued coin list is maintained as a hash tree and

Re: Ecash without a mint

n a chosen string) you can also > submit a new coin of the corresponding denomination. Appropriate > values for n could be chosen using the mechanisms Wei suggests in > b-money. Yeah, neat idea! With b-money, newly minted value goes directly into someone's account, but if it was used inste

Cracking the Code

[Excerpt from CATO Update, 20 Sept. 1999:] The Cato Institute released a new Cato Briefing Paper, "Strong Cryptography: The Global Tide of Change," as the Clinton administration was announcing a relaxation in controls on the export of encryption technology. In the paper, Arnold G. Reinhold writes

crypto product recommendations

At 12:41 PM 9/20/99 -0700, Rob Lemos wrote: > > > >Can anyone recommend a good product for encrypting information on the fly, >meaning encrypt the file when you close it and decrypt it when you open it. >It would also be nice if it would ask you whether you wanted the file you >are just closing to

Re: Ecash without a mint

On Mon, 20 Sep 1999 at 01:52:43PM -0700, Wei Dai wrote: > On Mon, Sep 20, 1999 at 09:02:17PM +0200, Anonymous wrote: > > Yeah, neat idea! With b-money, newly minted value goes directly into > > someone's account, but if it was used instead to create an anonymous > &

Re: Ecash without a mint, or - making anonymous payments practical

Amir Herzberg says, > Anonymous says, > > > It is still worth considering how to create anonymous payment systems > > which could be more compatible with other elements of present day society. > > I think we can do this, indeed, we can achieve an even stronger goal: &g

Re: snake-oil voting?

>Did any of you see this >http://www.votehere.net/content/Products.asp#InternetVotingSystems > >that proposes to authenticate the voter by asking for his/her/its SSN#? It looked like the idea for this part was to prevent double voting, plus make sure that only authorized people could vote. It w

Re: snake-oil voting?

John R. Levine writes, quoting others: > > >Did any of you see this > > >http://www.votehere.net/content/Products.asp#InternetVotingSystems > > > > > >that proposes to authenticate the voter by asking for his/her/its SSN#? > > > > It looked like the idea for this part was to prevent double votin

  1   2   >