On 2013-10-15 10:35, d...@deadhat.com wrote:
http://eprint.iacr.org/2013/338.pdf
No kidding.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
On 2013-10-11 15:48, ianG wrote:
Right now we've got a TCP startup, and a TLS startup. It's pretty
messy. Adding another startup inside isn't likely to gain popularity.
The problem is that layering creates round trips, and as cpus get ever
faster, and pipes ever fatter, round trips become a
On 2013-10-08 03:14, Phillip Hallam-Baker wrote:
Are you planning to publish your signing key or your decryption key?
Use of a key for one makes the other incompatible.�
Incorrect. One's public key is always an elliptic point, one's private
key is always a number.
Thus there is no reason
On 2013-10-08 02:03, John Kelsey wrote:
Alongside Phillip's comments, I'll just point out that assassination of key
people is a tactic that the US and Israel probably don't have any particular
advantages in. It isn't in our interests to encourage a worldwide tacit
acceptance of that stuff.
On 2013-10-07 01:18, Phillip Hallam-Baker wrote:
We are not at war with Iran.
We are not exactly at peace with Iran either, but that is irrelevant,
for presumably it was a Jew that did it, and Iran is at war with Jews.
(And they are none too keen on Christians, Bahais, or Zoroastrians
On 2013-10-04 23:57, Phillip Hallam-Baker wrote:
Oh and it seems that someone has murdered the head of the IRG cyber
effort. I condemn it without qualification.
I endorse it without qualification. The IRG are bad guys and need
killing - all of them, every single one.
War is an honorable
On 2013-10-05 16:40, james hughes wrote:
Instead of pontificating at length based on conjecture and conspiracy
theories and smearing reputations based on nothing other than hot air
But there really is a conspiracy, which requires us to consider
conjectures as serious risks, and people
On 2013-10-04 09:33, Phillip Hallam-Baker wrote:
The design of WSDL and SOAP is entirely due to the need to impedance
match COM to HTTP.
That is fairly horrifying, as COM was designed for a single threaded
environment, and becomes and incomprehensible and extraordinarily
inefficient security
On 2013-10-03 00:46, John Kelsey wrote:
a. Most attacks come from protocol or mode failures, not so much crypto
primitive failures. That is, there's a reaction attack on the way CBC
encryption and message padding play with your application, and it doesn't
matter whether you're using AES or
On 2013-10-02 23:09, Phillip Hallam-Baker wrote:
No, the reason for baring multiple inheritance is not that it is too
clever, it is that studies have shown that code using multiple
inheritance is much harder for other people to understand than code
using single inheritance.�
That is
On 2013-10-02 13:18, Tony Arcieri wrote:
LANGSEC calls this: full recognition before processing
http://www.cs.dartmouth.edu/~sergey/langsec/occupy/
http://www.cs.dartmouth.edu/%7Esergey/langsec/occupy/
I disagree slightly with langsec.
At compile time you want an extremely powerful language
On 2013-10-01 08:51, Watson Ladd wrote:
On Mon, Sep 30, 2013 at 2:21 PM, James A. Donald jam...@echeque.com
mailto:jam...@echeque.com wrote:
Weaker in ways that the NSA has examined, and the people that
chose the winning design have not.
This isn't true: Keccak's designers proposed
On 2013-10-01 10:17, John Kelsey wrote:
Yeah, that plot to weaken sha3 is so secretive, we've been discussing it in
public slide presentations and on public mailing lists for six months.
All big conspiracies get exposed - I would make a list, but that would
derail the conversation.
It does
On 2013-10-01 10:24, John Kelsey wrote:
If you want to understand what's going on wrt SHA3, you might want to look at
the nist website
If you want to understand what is going on with SHA3, and you believe
that NIST is frank, open, honest, and has no ulterior motives, you might
want to look
On 2013-10-01 18:06, Ben Laurie wrote:
On 1 October 2013 01:10, James A. Donald jam...@echeque.com
mailto:jam...@echeque.com wrote:
Further, google is unhappy that too-clever-code gives too-clever
programmers too much power, and has prohibited its employees from
ever doing
On 2013-10-01 22:08, Salz, Rich wrote:
Further, google is unhappy that too-clever-code gives too-clever programmers
too much power, and has prohibited its employees from ever doing something like
protobufs again.
Got any documentation for this assertion?
The google style guide prohibits
On 2013-10-02 05:18, Jerry Leichter wrote:
To be blunt, you have no idea what you're talking about. I worked at
Google until a short time ago; Ben Laurie still does. Both of us have
written, submitted, and reviewed substantial amounts of code in the
Google code base. Do you really want to
On 2013-10-01 14:36, Bill Stewart wrote:
It's the data representations that map them into binary strings that
are a
wretched hive of scum and villainy, particularly because you can't
depend on a
bit string being able to map back into any well-defined ASN.1 object
or even any limited size of
On 2013-10-01 14:36, Bill Stewart wrote:
It's the data representations that map them into binary strings that
are a
wretched hive of scum and villainy, particularly because you can't
depend on a
bit string being able to map back into any well-defined ASN.1 object
or even any limited size of
On 2013-09-30 14:34, Viktor Dukhovni wrote:
On Mon, Sep 30, 2013 at 05:12:06AM +0200, Christoph Anton Mitterer wrote:
Not sure whether this has been pointed out / discussed here already (but
I guess Perry will reject my mail in case it has):
On 2013-10-01 00:44, Viktor Dukhovni wrote:
Should one also accuse ESTREAM of maliciously weakening SALSA? Or
might one admit the possibility that winning designs in contests
are at times quite conservative and that one can reasonably
standardize less conservative parameters that are more
On 2013-09-30 18:02, Adam Back wrote:
If we're going to do that I vote no ASN.1, and no X.509. Just BNF format
like the base SSL protocol;
Granted that ASN.1 is incomprehensible and horrid, but, since there is
an ASN.1 compiler that generates C code we should not need to comprehend it.
On 2013-10-01 08:24, John Kelsey wrote:
Maybe you should check your code first? A couple nist people verified that the
curves were generated by the described process when the questions about the
curves first came out.
And a non NIST person verified that the curves were /not/ generated by
On 2013-10-01 08:35, John Kelsey wrote:
Having read the mail you linked to, it doesn't say the curves weren't generated
according to the claimed procedure. Instead, it repeats Dan Bernstein's
comment that the seed looks random, and that this would have allowed NSA to
generate lots of curves
On 2013-10-01 04:22, Salz, Rich wrote:
designate some big player to do it, and follow suit?
Okay that data encoding scheme from Google protobufs or Facebook thrift. Done.
We have a complie to generate C code from ASN.1 code
Google has a compiler to generate C code from protobufs source
The
On 2013-09-27 09:54, Phillip Hallam-Baker wrote:
Quite, who on earth thought DER encoding was necessary or anything
other than incredible stupidity?
I have yet to see an example of code in the wild that takes a binary
data structure, strips it apart and then attempts to reassemble it to
On 2013-09-30 03:14, Lodewijk andré de la porte wrote:
2013/9/29 James A. Donald jam...@echeque.com
mailto:jam...@echeque.com
(..) fact, they are not provably random, selected (...)
fixed that for you
It seems obvious that blatant lying about qualities of procedures must
have some
Gregory Maxwell on the Tor-talk list has found that NIST approved
curves, which is to say NSA approved curves, were not generated by the
claimed procedure, which is a very strong indication that if you use
NIST curves in your cryptography, NSA can read your encrypted data.
As computing power
On 2013-09-30 13:12, Christoph Anton Mitterer wrote:
https://www.cdt.org/blogs/joseph-lorenzo-hall/2409-nist-sha-3
This makes NIST seem somehow like liars
If one lie, all lies.
___
The cryptography mailing list
cryptography@metzdowd.com
On 2013-09-29 23:13, Jerry Leichter wrote:
BTW, the *idea* behind DER isn't inherently bad - but the way it ended up is
another story. For a comparison, look at the encodings Knuth came up with in
the TeX world. Both dvi and pk files are extremely compact binary
representations - but
On 2013-09-28 01:23, Phillip Hallam-Baker wrote:
Most cryptolibraries have a hard coded limit at 4096 bits and there
are diminishing returns to going above 2048. Going from 4096 to 8192
bits only increases the work factor by a very small amount and they
are really slow which means we end up
On 2013-09-10 4:30 PM, ianG wrote:
The question of whether one could simulate a raw physical source is
tantalising. I see diverse opinions as to whether it is plausible,
and thinking about it, I'm on the fence.
Let us consider that source of colored noise with which we are most
familiar:
On 08/09/2013 21:51, Perry E. Metzger wrote:
I wrote about this a couple of weeks ago, see:
http://www.metzdowd.com/pipermail/cryptography/2013-August/016872.html
In short, https to a server that you /do/ trust.
Problem is, joe average is not going to set up his own server. Making
setting
On 2013-09-10 3:12 AM, Peter Fairbrother wrote:
I like to look at it the other way round, retrieving the correct name
for a key.
You don't give someone your name, you give them an 80-bit key
fingerprint. It looks something like m-NN4H-JS7Y-OTRH-GIRN. The m- is
common to all, it just says
would you care to explain the very strange design decision
to whiten the numbers on chip, and not provide direct
access to the raw unwhitened output.
On 2013-09-09 2:40 PM, David Johnston wrote:
#1 So that that state remains secret from things trying to
discern that state for purposes of
On 2013-09-08 4:36 AM, Ray Dillinger wrote:
But are the standard ECC curves really secure? Schneier sounds like
he's got
some innovative math in his next paper if he thinks he can show that they
aren't.
Schneier cannot show that they are trapdoored, because he does not know
where the magic
On 2013-09-09 11:15 AM, Perry E. Metzger wrote:
Lenstra, Heninger and others have both shown mass breaks of keys based
on random number generator flaws in the field. Random number
generators have been the source of a huge number of breaks over time.
Perhaps you don't see the big worry, but real
On 2013-09-09 4:49 AM, Perry E. Metzger wrote:
Your magic key must then take any block of N bits and magically
produce the corresponding plaintext when any given ciphertext
might correspond to many, many different plaintexts depending
on the key. That's clearly not something you can do.
On 2013-09-09 6:08 AM, John Kelsey wrote:
a. Things that just barely work, like standards groups, must in general be
easier to sabotage in subtle ways than things that click along with great
efficiency. But they are also things that often fail with no help at all from
anyone, so it's hard
On 2013-09-06 12:31 PM, Jerry Leichter wrote:
Another interesting goal: Shape worldwide commercial cryptography marketplace to make it more tractable to advanced
cryptanalytic capabilities being developed by NSA/CSS. Elsewhere, enabling access and exploiting systems
of interest and inserting
On 2013-09-01 9:11 PM, Jerry Leichter wrote:
Meanwhile, on the authentication side, Stuxnet provided evidence that the
secret community *does* have capabilities (to conduct a collision attacks)
beyond those known to the public - capabilities sufficient to produce fake
Windows updates.
Do we
On 2013-09-01 4:02 AM, Ray Dillinger wrote:
On 08/30/2013 08:10 PM, Aaron Zauner wrote:
I read that WP report too. IMHO this can only be related to RSA
(factorization, side-channel attacks).
I have been hearing rumors lately that factoring may not in fact be as
hard
as we have heretofore
On 2013-09-01 11:16 AM, Jeremy Stanley wrote:
At free software conferences, where there is heavy community
penetration for OpenPGP already, it is common for many of us to bring
business cards (or even just slips of paper) with our name, E-mail
address and 160-bit key fingerprint. Useful not
On 2013-08-28 7:33 PM, ianG wrote:
On 28/08/13 02:44 AM, radi...@gmail.com wrote:
Zooko's triangle, pet names...we have cracked the THEORY of secure
naming, just not the big obstacle of key exchange.
Perhaps in a sense of that, I can confirm that we may have an elegant
theory but practice
Communicating public keys: A functional specification
A functional specification tells us how the user uses it, what he sees,
and what it does for him. It does not tell us how we manage to do it
for him.
The problem is that you want to tell someone over the phone, or on a
napkin, or face
On 2013-08-26 11:04 AM, Christian Huitema wrote:
Of course the data can be signed, encrypted, etc. But the rule of the game
is that the adversary can manufacture as many peers as they want --
something known as the Sybil attack. They can then perform various forms of
denial.
We need, and have
On 2013-08-21 3:38 AM, Perry E. Metzger wrote:
What is the current state of patents on elliptic curve cryptosystems?
(It would also be useful to know when the patents on such patents as
exist end.)
Perry
Such a question will be answered not with light but with darkness.
On 2010-10-01 3:23 PM, Chris Palmer wrote:
In my quantitative, non-hand-waving, repeated experience with many clients in
many business sectors using a wide array of web application technology
stacks, almost all web apps suffer a network and disk I/O bloat factor of 5,
10, 20, ...
Which does
On 2010-09-28 1:58 PM, Thai Duong wrote:
On Sat, Sep 18, 2010 at 8:43 PM, Peter Gutmann
pgut...@cs.auckland.ac.nz wrote:
I'm one of the authors of the attack. Actually if you look closer, you'll see
that they do it wrong in many ways.
The FormsAuth as well, not just the view state?
On 2010-09-16 6:12 AM, Andy Steingruebl wrote:
The malware could just as easily fake the whole UI. Is it really
PKI's fault that it doesn't defend against malware? Did even the
grandest supporters ever claim it could/did?
That is rather like having a fortress with one wall rather than four
On 2010-09-09 6:35 AM, Ben Laurie wrote:
What I do in Nigori for this is use DSA. Your private key, x, is the
hash of the login info. The server has g^x, from which it cannot
recover x,
Except, of course, by dictionary attack, hence g^x, being low
entropy, is treated as a shared secret.
and
On 2010-08-25 11:04 PM, Richard Salz wrote:
Also, note that HSTS is presently specific to HTTP. One could imagine
expressing a more generic STS policy for an entire site
A really knowledgeable net-head told me the other day that the problem
with SSL/TLS is that it has too many round-trips. In
On 2010-08-15 7:59 AM, Thor Lancelot Simon wrote:
Indeed. The way forward would seem to be ECC, but show me a load balancer
or even a dedicated SSL offload device which supports ECC.
For sufficiently strong security, ECC beats factoring, but how strong is
sufficiently strong? Do you have
On 2010-08-17 3:46 PM, Jonathan Katz wrote:
Many on the list may already know this, but I haven't seen it mentioned
on this thread. The following paper (that will be presented at Crypto
tomorrow!) is most relevant to this discussion:
Factorization of a 768-bit RSA modulus,
On 2010-08-05 11:30 AM, David-Sarah Hopwood wrote:
Signatures are largely a distraction from the real problem: that software
is (unnecessarily) run with the full privileges of the invoking user.
By all means authenticate software, but that's not going to prevent
malware.
A lot of devices
On 2010-07-29 12:18 AM, Peter Gutmann wrote:
This does away with the need for a CA,
because the link itself authenticates the cert that's used.
Then there are other variations, cryptographically generated addresses, ...
all sorts of things have been proposed.
The killer, again, is the refusal
On 2010-07-11 10:11 AM, Brandon Enright wrote:
On Fri, 9 Jul 2010 21:16:30 -0400 (EDT) Jonathan
Thornburgjth...@astro.indiana.edu wrote:
The following usenet posting from 1993 provides an
interesting bit (no pun itended) of history on RSA key
sizes. The key passage is the last paragraph,
On 2010-04-22 9:17 AM, Paul Hoffman wrote:
At 9:40 PM -0400 4/20/10, Victor Duchovni wrote:
EC definitely has practical merit. Unfortunately the patent issues around
protocols using EC public keys are murky.
This is starting to turn around. More vendors are questioning the murk.
On 2010-03-22 11:22 PM, Sergio Lerner wrote:
Commutativity is a beautiful and powerful property. See On the power
of Commutativity in Cryptography by Adi Shamir.
Semantic security is great and has given a new provable sense of
security, but commutative building blocks can be combined to build
On 2010-03-23 1:09 AM, Sergio Lerner wrote:
I've read some papers, not that much. But I don't mind reinventing the
wheel, as long as the new protocol is simpler to explain.
Reading the literature, I couldn't find a e-cash protocol which :
- Hides the destination / source of payments.
- Hides
Jerry Leichter wrote:
NFC?
Near Field Communications - the wireless equivalent of
whispering in someone's ear. Ideally, a NFC chip should
only be able to talk to something that is an inch or so
away, and it should be impossible to eavesdrop from more
than a foot or so away.
Lots of people
The Haber Stornetta scheme provides a timestamping
service that doesn't require terribly much trust,
since hard to forge widely witnessed events delimit
particular sets of timestamps. The only issue is
getting sufficient granularity.
I don't know if their scheme was patented in Germany.
Ivan Krsti wrote:
What you're proposing amounts to a great deal of complex and complicated
cryptography. If it were implemented tomorrow, it would take years for
the most serious of implementation errors to get weeded out, and some
years thereafter for proper interoperability in corner cases.
Steven Bellovin wrote:
Several other people made similar suggestions. They all boil down to
the same thing, IMO -- assume that the user will recognize something
distinctive or know to do something special for special sites like
banks.
Not if he only does it for special sites like banks,
Nicolas Williams wrote:
One possible problem: streaming [real-time] content.
Brian Warner wrote:
Yeah, that's a very different problem space. You need
the low-alacrity stuff from Tahoe, but also you don't
generally know the full contents in advance. So you're
talking about a mutable stream
Steven Bellovin wrote:
This returns us to the previously-unsolved UI problem: how -- with
today's users, and with something more or less like today's browsers
since that's what today's users know -- can a spoof-proof password
prompt be presented?
When the user clicks on a button generated by
Zooko Wilcox-O'Hearn wrote:
On Wednesday,2009-08-26, at 19:49 , Brian Warner wrote:
Attack B is where Alice uploads a file, Bob gets the filecap and
downloads it, Carol gets the same filecap and downloads it, and
Carol desires to see the same file that Bob saw. ... The attackers
(who may
Perry E. Metzger wrote:
Yet another reason why you always should make the crypto algorithms you
use pluggable in any system -- you *will* have to replace them some day.
Ben Laurie wrote:
In order to roll out a new crypto algorithm, you have to roll out new
software. So, why is anything
[*] Linus Torvalds got the idea of a Cryptographic Hash Function
Directed Acyclic Graph structure from an earlier distributed
revision control tool named Monotone.
OT trivia: The idea actually predates either monotone or git;
opencm (http://opencm.org/docs.html) was using a similiar
James A. Donald jam...@echeque.com writes:
[Incredibly complicated description of web scripting plumbing deleted]
Peter Gutmann wrote:
We seem to be talking about competely different things here. For a typical
application, say online banking, I connect to my bank at www.bank.com or
whatever
Thomas Hardjono wrote:
I'm not sure if the Chrome folks would be prepared to
ship their browser without any CA certs loaded,
Excessive distrust is inconvenient, excessive trust is
vulnerable. It is better to remedy flaws by expanding
functionality rather than restricting it.
On the one hand,
James A. Donald jam...@echeque.com writes:
[In order to implement strong password based
encryption and authentication] on the server side,
we need a request object in the script language that
tells the script that this request comes from an
entity that established a secure connection
--
James A. Donald jam...@echeque.com writes:
For password-authenticated key agreement such as
TLS-SRP or TLS-PSK to work, login has to be in the
chrome.
Peter Gutmann wrote:
Sure, but that's a relatively tractable UI problem
Indeed. You know how to solve it, and I know how to
solve
Thomas Hardjono wrote:
Having worked at a large CA for along time (trying to push for client-side
certs with little luck), here are some thoughts on what Chrome could provide:
There are use cases where a centralized authority is useful.
Client side is not one of them.
Typical usage is is
Ben Laurie wrote:
So, I've heard many complaints over the years about how the UI for
client certificates sucks. Now's your chance to fix that problem -
we're in the process of thinking about new client cert UI for Chrome,
and welcome any input you might have. Obviously fully-baked proposals
are
Joseph Ashwood wrote:
RC-4 is broken when used as intended.
...
If you take these into consideration, can it be used correctly?
James A. Donald:
Hence tricky
Joseph Ashwood wrote:
By the same argument a Viginere cipher is tricky to use securely, same
with monoalphabetic and even Ceasar
From: Nicolas Williams nicolas.willi...@sun.com
For example, many people use arcfour in SSHv2 over AES because arcfour
is faster than AES.
Joseph Ashwood wrote:
I would argue that they use it because they are stupid. ARCFOUR should
have been retired well over a decade ago, it is weak, it
Tanja Lange wrote:
So with about 1 000 000 USD and a full year you would get 122 bits
already now and agencies have a bit more budget than this! Furthermore,
the algorithm parallelizes extremely well and can handle a batch of 100
targets at only 10 times the cost.
No it cannot handle a bunch
Hi all,
We are pleased to announce that we have set a new record for the elliptic
curve discrete logarithm problem (ECDLP) by solving it over a 112-bit
finite field. The previous record was for a 109-bit prime field and
dates back from October 2002.
See for more details our announcement at
Jerry Leichter wrote:
Consider first just updates. Then you have exactly the same problem as
for disk encryption: You want to limit the changes needed in the
encrypted image to more or less the size of the change to the underlying
data. Generally, we assume that the size of the encrypted
John Levine jo...@iecc.com writes:
Clever though this scheme [kittens] is, man-in-the
middle attacks make it no better than a plain SSL
login screen.
Peter Gutmann wrote:
You don't even need a MITM, just replace the site
image on your phishing site with either a broken-
image picture or a
Ben Laurie wrote:
If I have data on my server that I would like to stay on my server and
not get leaked to some third party, then this is exactly the same
situation as DRMed content on an end user's machine, is it not?
No.
You want to keep control of the information on your server. DRM wants
Nicolas Williams wrote:
Providing a suitable e-mail security solution for the
masses strikes me as more important than providing
anonymity to the few people who want or need it. Not
that you can't have both, unless you want everyone to
use PGP or S/MIME as a way to hide anonymized traffic
Peter Gutmann wrote:
... to a statistically irrelevant bunch of geeks.
Watch Skype deploy a not- terribly-anonymous (to the
people running the Skype servers) communications
system.
Actually that is pretty anonymous. Although I am sure
that Skype would play ball with any bunch of goons that
Jack Lloyd wrote:
I think the situation is even worse outside of the
major projects (the OS kernels crypto implementations
and the main crypto libraries). I think outside of
those, nobody is even really looking. For instance -
This afternoon I took a look at a C++ library called
JUCE which
--
We discovered, however, that most people do not want
to manage their own secrets
StealthMonger wrote:
This may help to explain the poor uptake of encrypted
email.
There is very good uptake of skype and ssh, because
those impose no or very little additional cost on the
end
To implement Zooko's triangle, one has to detect names
that may look alike, for example e-gold and e-go1d
This is a lot of code. Has someone already written such
a collision detector that I could swipe?
The algorithm is to map all lookalike glyphs to
canonical glyphs - thus l and 1 are mapped
Ray Dillinger wrote:
Okay I'm going to summarize this protocol as I
understand it.
I'm filling in some operational details that aren't in
the paper by supplementing what you wrote with what my
own design sense tells me are critical missing bits
or obvious methodologies for use.
There
Nicolas Williams wrote:
How do identities help? It's supposed to be anonymous
cash, right?
Actually no. It is however supposed to be pseudonymous,
so dinging someone's reputation still does not help
much.
And say you identify a double spender after the fact,
then what? Perhaps you're
Satoshi Nakamoto wrote:
Fortunately, it's only necessary to keep a
pending-transaction pool for the current best branch.
This requires that we know, that is to say an honest
well behaved peer whose communications and data storage
is working well knows, what the current best branch is -
but of
Satoshi Nakamoto wrote:
When there are multiple double-spent versions of the
same transaction, one and only one will become valid.
That is not the question I am asking.
It is not trust that worries me, it is how it is
possible to have a a globally shared view even if
everyone is well
--
James A. Donald wrote:
OK, suppose one node incorporates a bunch of
transactions in its proof of work, all of them honest
legitimate single spends and another node
incorporates a different bunch of transactions in its
proof of work, all of them equally honest legitimate
single
--
Satoshi Nakamoto wrote:
The proof-of-work chain is the solution to the
synchronisation problem, and to knowing what the
globally shared view is without having to trust
anyone.
A transaction will quickly propagate throughout the
network, so if two versions of the same transaction
Is there a way of constructing a digital signature so
that the signature proves that at least m possessors of
secret keys corresponding to n public keys signed, for n
a dozen or less, without revealing how many more than m,
or which ones signed?
Satoshi Nakamoto wrote:
Increasing hardware speed is handled: To compensate
for increasing hardware speed and varying interest in
running nodes over time, the proof-of-work difficulty
is determined by a moving average targeting an average
number of blocks per hour. If they're generated too
Satoshi Nakamoto wrote:
The bandwidth might not be as prohibitive as you
think. A typical transaction would be about 400 bytes
(ECC is nicely compact). Each transaction has to be
broadcast twice, so lets say 1KB per transaction.
Visa processed 37 billion transactions in FY2008, or
an
James A. Donald:
To detect and reject a double spending event in a
timely manner, one must have most past transactions
of the coins in the transaction, which, naively
implemented, requires each peer to have most past
transactions, or most past transactions that
occurred recently
A sim card contains a shared symmetric secret that is known to the
network operator and to rather too many people on the operator's staff,
and which could be easily discovered by the phone holder - but which is
very secure against everyone else.
This means that cell phones provide
Satoshi Nakamoto wrote:
I've been working on a new electronic cash system that's fully
peer-to-peer, with no trusted third party.
The paper is available at:
http://www.bitcoin.org/bitcoin.pdf
We very, very much need such a system, but the way I understand your
proposal, it does not seem to
Suppose one has a system that automatically signs you on to anything if
your cell phone is within bluetooth range of your computer, and
automatically signs you off out of everything, and puts up a screen
saver that will not go away, when your cell phone is out of range of
your computer.
What
1 - 100 of 304 matches
Mail list logo
