ationals present?
Not if you didn't go around talking about it.
-Bram
many queries to the oracle to encrypt but
exponentially many queries to the oracle to crack, the encrypter wins.
No, I don't have any clue how an algorithm like that might work.
-Bram
On Fri, 5 Feb 1999, bram wrote:
> I have a theory that no matter what computing machine is available, as
> long as the same machine is available to both the encrypter and the
> cracker, the cracker wins (barring non-turing complete machinery, of
> course.)
Jim Gillogly pointe
long as all the goofing around was done beneath a single top-level
domain which noone was ever going to use, it might be possible to win that
battle.
-Bram
ually.
Does anybody know if/how it's possible to get domain names in the now
defunct .su ? Do you have to be grandfathered in? Is there a chance that
just unilaterally grabbing one might work?
-Bram
(Thinking he should get a domain in .to - that WIPO DNS paper looked kinda
scary)
/pubs/fip140-1.htm
-Bram
(altavista is your friend)
80
bits of entropy for *any* amount of random numbers if you use a
crypographically strong pseudo random number generator.
-Bram
27;s generally obvious that I mean it in a
cryptographic sense, rather than a physics sense.
-Bram
cally large.
I'm not sure if anybody's yarrowified /dev/random yet - I think someone
from coderpunks was working on it.
-Bram
have come up with are
based on using secure hashes.
-Bram
On Sat, 17 Jul 1999, Eugene Leitl wrote:
> bram writes:
>
> > Most of the fancy reseedable PRNG schemes people have come up with are
> > based on using secure hashes.
>
> They are sure validated, but are they the best we can do? MD5, the
> nonplusultra, really?
at model pretty well -
http://www.counterpane.com/yarrow.html
> so if you need the high quality randomness, you need hardware randomizers.
Those are helpful as well, but should still never be used in the raw -
their entropy output should be estimated conservatively and fed into a
reseedable PRNG.
-Bram
hich doesn't deplete entropy and the problem
will go away. And yes, it is possible to do that in a secure manner.
-Bram
asure, and pool it to be
introduced in large enough chunks to prevent continuation attacks, but the
short answer is yes.
-Bram
whichever comes *LAST*, and where N and Z are chosen to ensure a good
> leverage ratio.
a) and b) don't help much - the true answer is c).
As for getting entropy when the machine is first started up, it will have
to block a bit until enough is collected, but after that is done once it
can purr right along.
-Bram
e last keystroke. (which
means, interestingly enough, that you can get faster entropy harvesting by
having a more precise clock.)
-Bram
s
the state of the pool at some point and manages to control all attempted
reseedings.
-Bram
there is a failure, and an attacker does
find out what the internal state of the pool is, it won't be useful for
long.
-Bram
also like to
> capitalize on the properties of hash functions for prepping the entropy.
You basically have to do that to prevent chosen entropy attacks, and it's
a good idea to pool the entropy anyway to prevent continuation attacks.
-Bram
and SHA-1 for internal mixing.
I think the 160 bit safety involved in both SHA-1 and RIPEMD-160 will
continue to be excessive for many years to come, so there's no reason to
worry about it being 'too small'.
-Bram
h are necessary to snoop
> the RNG state will also allow for more malicious actions that completely
> compromise security.
The way to diddle with RNG state is to mess with it's sources, not by
directly looking inside the state. Attacks of that form, even if they
aren't 'practical' now, could easily become practical in the future.
-Bram
py and threat
models and all that yadda yadda yadda which most developers will
rightfully recoil from getting into when all they want is a few random
bytes.
-Bram
heir RNG, I
just think it's likely that the raw output displays some subtle bias, and
they either knew about it or decided to just play it safe, and put the
whitening in.
-Bram
t I don't fear it being enforced.
"I can't say that because it would violate national security" was an
oft-repeated refrain in the Iran-Contra affair. Like it or not, the
'national security' excuse has quite a bit of history to it and it's very
naive to think it will just go away.
-Bram
formation offered by the prover, and using the bits of
the secure hash of that as the challenges by the provee.
-Bram
ce new bills almost always have them with sequential
serial numbers. There have been many cases of a huge heist getting pulled
off successfully and then the robbers were unable to dispose of the cash
they got because it was too easy to trace.
-Bram
hich rely on quantum
computation for efficient encryption which are strong against quantum
decryption techniques, although I'll bet you could get the right people to
speculate about it.
-Bram
natures doesn't change that at all.
-Bram
k optimizing its implementation.
That doesn't make the algorithm any more useful.
-Bram
it generates (two
a day if my memory servers) are just too small to say much about
individuals.
Besides, violating individual rights is the FBI's job.
-Bram
terests are
> contrary to the interests of the IETF and the Internet as a whole. It
> is a male. And he is regularly reporting IETF member activities for
> secret investigation. Beware.
Or maybe it's just someone who reads published IETF literature. It's not
like the IETF keeps it's activities all that secret.
-Bram
ings patented
these days are going to be rediscovered sooner or later (generally sooner,
often prior,) so you might as well patent the good idea just to keep
anyone else from using it.
-Bram
Maybe I'm just dense, but what's with the emphasis on phone
conversations? Voice processing is flaky at best, and computationally
expensive regardless. Faxes, on the other hand, can be OCR'ed easily, and
email is in plaintext to begin with.
-Bram
a daily basis. Use a factory design pattern
to produce new instances, and a naming service if you absolutely must be
able to swap in new implementations at link or runtime, but whatever you
do, don't give in to your emotional attachment to the old way. It really
does suck.
-Bram
ction. Similarly to a trade secret that has been leaked by a
> person under NDA.
This may be a legally naive idea, but I've always assumed that if
something is no longer a secret, it's no longer a trade secret. Is that
not the case?
-Bram
ant without violating the original author's copyright? Does that mean
that, say, Bsafe will have the rug yanked out from under it by allowing
alternate non-infringing implementations?
(Doesn't the RSA patent expire in October as well? That's a mighty funny
coincidence ... for anyone other than RSA, anyhow.)
-Bram
a definite weakness of current public key
systems. It may seem boring and tedious to work out detailed legal
meanings of what all the public key technical artifacts mean, but unless
those artifacts refer to specific meanings themselves, a court will make
them up later, and will probably make them up in a way which the original
authors (meaning you) aren't happy with.
-Bram
On Tue, 4 Jan 2000, Ray Hirschfeld wrote:
> > Date: Mon, 3 Jan 2000 18:43:52 -0800 (PST)
> > From: bram <[EMAIL PROTECTED]>
>
> > I'm a little confused. Are you saying that as of October it will be legal
> > to do any amount of reverse-engineering, publis
topping active attacks, but right now almost
everything on the internet is subject to passive attacks. Fix the first
problem first, only then will it become clear how to solve the second
problem.
-Bram
ry distributing a few xeroxed $100 bills, and
> time how long it takes until the feds knock on your door).
Do you have a reference for that?
[There have been SO many articles on this recently, including a long
thread on RISKS: the summary being that it is absolutely
true. --Perry]
-Bram
had some paperwork
problems on it though - a while after I had deposited my check they mailed
me asking if I'd ever gotten one.
-Bram
actly constitutes 'causing customer
confusion' with regards to using the term RC4. If I publish something
clearly labelled 'Bram's crypto library' and list RC4 as one of the
ciphers supported, there's no implication of anything coming from RSA, it
comes from Bram. The
er repeats.
The work on the studying the output of Intel's RNG has only had accessed
to the post-processed output, plus I believe a file directly from Intel
which was claimed to be unprocessed output. Yeah ... right.
If Intel wants people to trust them, they should quit acting like they're
coving for bad engineering.
-Bram
7;s no satisfying some people.
Ad hominen attacks and claims of unfalsifiability being reasonable aside,
there is something which would make me happy.
Chip manufacturers reverse-engineer each other's stuff all the time. I'd
like one of Intel's competitors to publically state 'We took apart a
Pentium III and it's RNG really works the way Intel says.'
-Bram
Does anybody know of a field in which a + b and a * b can be computed
quickly but (and this is important) it's computationally intractable to
compute the additive inverse of a?
I need it for a technique I'm working on.
-Bram
[Bram: All fields of n elements are isomorphic to all other
On Thu, 9 Mar 2000, bram wrote:
> Does anybody know of a field in which a + b and a * b can be computed
> quickly but (and this is important) it's computationally intractable to
> compute the additive inverse of a?
>
> [Bram: All fields of n elements are isomorphic to all
ou can tunnel PPP over SSH ...
-Bram Cohen
tem is so unreliable. Senior commanders be-lieve
> that the reliability of mobile phones outweighs the increased risk of
> conversations being intercepted.
Wouldn't it be ironic if they resort to buying a bunch of stariums ...
-Bram Cohen
[That would require that Stariums actually app
rribly worrisome. The existence
of a very impractical attack against 7 rounds hardly changes things much,
especially in light of Rijndael being very simple and hence relatively
easy to analyze.
-Bram Cohen
feeding it through an appropriate PRNG, further
seeding prevents attacks which are merely theoretical.
-Bram Cohen
already
be that way - if so, never mind.)
-Bram Cohen
message again'. The only real
gotcha is that the first message is unencrypted, and that's not a big
deal, especially when you know about it and always send a 'checking to
make sure I got your address right' message to start things off.
-Bram Cohen
On Wed, 29 Nov 2000, Ian BROWN wrote:
> Bram Cohen wrote:
> >What we really need is a system which just stops passive attacks. The best
> >idea I've come up with so far is for all outgoing messages to have a
> >public key attached, and if you have the public key of
On Sun, 3 Dec 2000, Ben Laurie wrote:
> Bram Cohen wrote:
> >
> > Come to think of it, there are some tricky issues with regards to crypto
> > on mailing lists, it might make sense to have a
> > X-crypto-originator [EMAIL PROTECTED] line in the headers to specify that
gnore the mail headers and use the userID(s)
> in the public key certificate included in the message.
To clarify - I think doing things based on PGP userIDs is unworkable, and
would like to do everything based on email addresses.
-Bram Cohen
surprised AOL isn't offering this "security feature" as well ...
> I feel safer already :~)
To be fair, Yahoo handles so much mail that the CPU power necessary to
start SSL sessions for all of them gets pretty expensive. They'll probably
start doing end-to-end encryption w
problem with it? --Perry]
We already have too many common denominators. I'm waiting for something to
stop looking like an experiment to actually start advocating use of a
particular crypto application.
-Bram Cohen
On Mon, 4 Dec 2000, Bram Cohen wrote:
>
> [SHA-2 looks pretty good. What's your problem with it? --Perry]
It's slow. It's fast enough for most applications, but then again so is
3DES - either you care about speed or you don't, and if you do, SHA2 just
doesn't rank
On Tue, 5 Dec 2000, David Honig wrote:
> Is there a reason not to use AES block cipher in a hashing mode
> if you need a secure digest of some data?
Hashing modes of block ciphers require a re-key for every block, and hence
are really, really slow.
-Bram Cohen
and not at all for things which require
a lot.
-Bram Cohen
[Parallelism is NOT a trivial property. The maximum data rate you can
sustain depends a lot on whether or not an algorithm can be
implemented in parallel in hardware. Some algorithms, like various
keyed hashes, have bad properties in this re
e from patenting it and release it into the public
domain.
2) to keep anyone from using it
If you're not doing 1, you're doing 2.
-Bram Cohen
out the total lack of technical detail in the press
release specifically. Thanks for the pointer.
-Bram Cohen
prove
all that useful.
It really does, as advertized, offer MAC for almost no overhead, and
parallelization for free. It would be a shame for these modes to not get
used because of stupid patent bullshit.
-Bram Cohen
(who thinks doing the xors as a gray code instead of binary countup was a
nice touch.)
tes.
>
> What did I tell ya?
The US military is switching over to biometrics, including fingerprints
and cornea scans. One of the reasons they decided to do the switch is that
newer technologies ensure that the item in front of the scanner is in fact
alive :)
-Bram Cohen
mprovement in speed on a single CPU system.
There's an improved version of the IBM mode at
http://csrc.nist.gov/encryption/aes/modes/ in the 'OCB mode' paper.
Clearly, it's a good idea to wait for new developments to stop happening
to use the new modes.
-Bram Cohen
"M
On Wed, 27 Dec 2000, Theodore Y. Ts'o wrote:
> From: Bram Cohen <[EMAIL PROTECTED]>
>
>The problem is that if someone performs MITM on you, you get a warning
>saying 'I don't know who this is warning warning warning blah blah blah,
>would yo
I've set up a home page for Envelope Mail, and included feedback which I
got from my last post (thanks everybody!) It's at -
http://gawth.com/bram/envelope_mail/
Any and all additional feedback and offers to help would be much
appreciated. In particular, it could use a logo :-)
-
h.com/bram/envelope_mail/
-Bram Cohen
"Markets can remain irrational longer than you can remain solvent"
-- John Maynard Keynes
ch of
credit card numbers anonymously.
-Bram Cohen
"Markets can remain irrational longer than you can remain solvent"
-- John Maynard Keynes
I've done a bunch more work on Envelope Mail, as always, the latest info
is at -
http://gawth.com/bram/envelope_mail/
New is actual code, complete with test code. Plans are next to write a
patch for BoboMail implementing the dummy version of the crypto API.
I could use immediate help o
This isn't obviously crypto-related, but I'll explain if there's a simple
solution.
Given that f(x+1) = f(x) * f(x) + c, does anybody know how to express f(x)
in closed form?
-Bram Cohen
f(w) quickly using the formula
f(n) = s^(2^n) + s^(-(2^n)) (mod p)
Which can be easily proven by induction.
Not only does this technique prevent paralellization, but it sets the
amount of work Bob has to do very precisely.
A surprisingly simple result.
-Bram Cohen
On Sat, 25 Mar 2000, Bram Cohen wrote:
> Alice is capable of computing f(w) quickly using the formula
>
> f(n) = s^(2^n) + s^(-(2^n)) (mod p)
I neglected to point out that she does this by first computing
e = 2^n (mod p-1)
and then computing
s^e (mod p)
Which is equal to s^(2
ere is
clearly an underlying theory we have yet to discover.
-Bram Cohen
s way of factoring n using the oracle though.
Other than that, they look about the same - there wouldn't be any
noticeable difference in performance between the two algorithms.
Mostly I just find the mess which the expansion of f(x)^2 - 2 becomes
after a few iterations very comforting.
-Bram Cohen
larger proof of work than the
constant-sized one the previous technique does.
Well, that's all I could come up with. Any thoughts/criticisms are
welcome.
-Bram Cohen
the reach of complexity theory these
days.)
Just thought I'd throw that out. Had to vent. Not being able to find one
is getting on my nerves.
-Bram Cohen
date and a scrambled version of the login id. Then, if
someone wants to demonstrate their login history they send you the dates
and their id and you can verify it, but analyzing the database as a whole
requires a lot of work.
Well, so that's not a particularly strong motivation, but hopefully it
clarifies.
-Bram Cohen
78 matches
Mail list logo
