-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/01/15 07:03, realcr wrote:
I think the naive solution I proposed in my first message is more
efficient than using Bitcoin, because it does not involve proof of
work or flooding stuff.
Shortly: Whenever a person is added to the band, all
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/01/15 13:21, realcr wrote:
Now the original members b,c,d create an alternative history:
I assume that the original band has a majority of correct members.
Therefore at least two out of {b,c,d} are correct, and they will
not create
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Dan,
I always enjoy your writing and the broad scope of thought it reveals,
but I think there's more to privacy than a dichotomy between keeping
things to ourselves and revealing them to the world.
I like David Feldman's conception of privacy,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/07/14 11:27, James A. Donald wrote:
On 2014-07-11 07:45, Kevin wrote:
On 7/10/2014 4:39 PM, John Young wrote:
https://blog.silentcircle.com/why-are-we-competing-with-phone-makers-skype-and-telecom-carriers-all-in-the-same-week/
With
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 22/06/14 09:46, coderman wrote:
On Fri, Sep 13, 2013 at 2:49 AM, Eugen Leitl eu...@leitl.org
wrote:
... http://people.umass.edu/gbecker/BeckerChes13.pdf
Stealthy Dopant-Level Hardware Trojans ?
Georg T. Becker1
this paper has
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/06/14 19:30, grarpamp wrote:
It would be nice to check some numbers on this for the list. Is
there a wiki or paper repository that discusses plausibly reachable
DHT sizes, time needed for DHT ops to resolve, and management
schemes for such
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/06/14 20:54, pira...@gmail.com wrote:
There is no way to hide metadata because you need a destination
for your messages to arrive ... has to find its destinations to
deliver its contents.
Yes of course... the minimum necessary for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 28/05/14 10:54, Mansour Moufid wrote:
On Fri, 2014-04-25 at 09:28 -0700, Tony Arcieri wrote:
There's an entire class of memory safety bugs which are possible
in C but not possible in Rust. These also happen to be the class
of bugs that lead
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/04/14 23:51, ianG wrote:
2. Score another 1 up for interpreted languages that handle array
allocation cleanly. This is more or less a buffer overflow, in a
wider sense.
Not just interpreted languages - a modern compiled language such as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 31/03/14 18:36, ianG wrote:
END of snippets, mostly to try and figure out what this protocol
is before casting judgement. Anyone got an idea?
http://tools.ietf.org/html/draft-rescorla-tls-extended-random-02
The United States Department of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/01/14 14:26, Krisztián Pintér wrote:
Ondrej Mikle (at Saturday, January 11, 2014, 11:19:30 PM):
a) Ladders Does this mean that an implementation of secp256k1 is
likely to have timing side-channel attacks?
likely might be a strong word.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/10/13 09:29, Guido Witmond wrote:
It looks like you've worked around the UX issues by inserting an
EC-aware proxy between the client and server. Who would be
responsible for deploying such proxies?
That proxy lives in the end user's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/10/13 10:56, Guido Witmond wrote:
You might want to take a look at my experiments. It's a user agent
that does all the key management for you.
It even does it with never asking anything more difficult than
what username you want to have at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 30/09/13 23:40, Trevor Perrin wrote:
It'd be nice if Alice and Carol could use some additional,
out-of-band channel to authenticate the ephemeral DH exchange.
To fill in some background: the use case for this feature is
introducing two people
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/10/13 15:14, Adam Back wrote:
Well I think there are two issues:
1. if the public key is derived from a password (like a bitcoin
brainwallet), or as in EC based PAKE systems) then if the point
derived from your password isnt on the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/10/13 16:45, Trevor Perrin wrote:
Suppose you are a good guy with a static curve25519 key, and a bad
guy is sending you 32-byte strings, claiming them to be ephemeral
curve25519 public keys for use in an ephemeral-static
Diffie-Hellman.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24/09/13 07:52, Trevor Perrin wrote:
On Mon, Sep 23, 2013 at 4:51 AM, Michael Rogers
The key agreement starts with a hash commitment, followed by an
exchange of ephemeral ECDH public keys. Two short authentication
strings (again, six decimal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 28/09/13 12:36, ianG wrote:
On Thu, Sep 19, 2013 at 09:20:04PM +0100, Michael Rogers wrote:
The key reuse issue isn't related to the choice between
time-based and message-based updates. It's caused by keys and
IVs in the current design being
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sorry for making so much noise on the list today. I have a quick
question about public keys.
The Curve25519 paper says that every 32-byte string is accepted as a
Curve25519 public key. Yet Elligator doesn't use Curve25519. So I
guess there must be a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 26/09/13 17:36, Sandy Harris wrote:
John Young j...@pipeline.com wrote:
Tiltman vaunts the One Time Pad but cautions there have been
effective decrypts exploiting enthusiastic sloppy thinking that
OTP is unbreakable. Most appears to involve
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24/09/13 00:18, Adam Back wrote:
On Mon, Sep 23, 2013 at 01:39:35PM +0100, Michael Rogers wrote:
Apple came within a whisker of solving the problem in iOS by
creating an 'effaceable storage' area within the flash storage,
which bypasses block
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks Trevor and Adam for your comments on this - I take your point
about the importance of forward secrecy for metadata, so I'll abandon
the idea of using ephemeral-static ECDH to protect the metadata.
On 20/09/13 01:55, Trevor Perrin wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23/09/13 05:12, Dev Random wrote:
I've been thinking about this for a while now and I don't see a way
to do this with today's mobile devices without some external help.
The issue is that it's pretty much impossible to delete data
securely
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 20/09/13 13:11, shawn wilson wrote:
Does anyone have a list of processes people have come up with to create
images for hashes? The only one that I'm aware of is the randomart
that is generated when creating a keypair for ssh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19/09/13 08:04, Trevor Perrin wrote:
I'd have to see a writeup to have real comments. But to address
the issue of fragility:
It seems you're worried about per-message key updates because in
the (infrequent?) case that a sender's write to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 18/09/13 00:14, Trevor Perrin wrote:
Why not have separate symmetric keys for each direction of
communication (Alice - Bob, Bob-Alice).
We derive separate keys for each direction from the shared secret.
Then whenever a party encrypts or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 18/09/13 08:12, Adam Back wrote:
Or better the actual key used could be derived to fix that. eg
k_{i+1}=H(k_i) delete k_i; but also sk_i=H(1||k_i) then use sk_i
values. In that way you can keep keys for a gap with no security
implication
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 18/09/13 08:23, ianG wrote:
If I compromise your first shared secret, does that mean every
shared secret thereafter is compromised?
Yes. (Improvements are possible here, by sending and acking fresh key
material inside the encrypted envelopes,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 18/09/13 17:27, Trevor Perrin wrote:
Hmm, I would've thought clocks are *less* reliable than storage on
most devices.
That may be true, but this isn't a choice between relying on the clock
or relying on storage. It's a choice between relying on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 18/09/13 18:56, Trevor Perrin wrote:
Sorry, mis-send... I meant:
A quick glance at Briar makes it looks like it already uses local
storage:
Neither endpoint can send more than 2^32 connections to the
other during a given rotation period.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Fabio,
It seems to me that there are two fundamental problems to solve if you
want to disguise the correlation between a node's inputs (submissions,
comments and edits) and its outputs (notifications).
The first problem is disguising the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 20/08/13 07:08, ianG wrote:
On a related point, what name do we give to the design/pattern for
entropy sources == mix/pool == deterministic expansion function
? I was asked this seconds after tasking my intern to build one
:-/
Seems like
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I wonder if anyone on the list can help me to understand the purpose
and correct use of HKDF's salt parameter. RFC 5869 has this to say:
HKDF is defined to operate with and without random salt. This is
done to accommodate applications
calculate 'fred' with every possible salt and store it,
economically.
[0] these things were true a long time ago...
in more particular:
On 1/08/13 12:16 PM, Michael Rogers wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
Hi all,
I wonder if anyone on the list can help me
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Tony,
The following article talks about using secret sharing and threshold
signatures to make quorom decisions in a distributed system:
L. Zhou and Z.J. Haas, Securing ad hoc networks. IEEE Network
13(6):24?30, November 1999.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/07/13 13:34, danimoth wrote:
IMHO that's is unfair. There are many publications on Tor
vulnerabilities as well, and this is unavoidable. Are you sure that
in the next two months Tor will not be the main actor of a similar
publication?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/07/13 17:15, danimoth wrote:
Uhm, I don't consider it a matter of centralization vs
decentralization. I think the point is how I2P select peers to
communicate with; attacker DoS'd previous high-performance peers,
then replace them with nodes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/07/13 22:07, James A. Donald wrote:
106 bits is still far too small. Seems to me that they only
increased it as needed to defeat DecryptoCat, not as needed to
defeat an NSA farm running dedicated special purpose hardware.
Why not use an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/07/13 13:26, danimoth wrote:
Not directly related to remailer, but what about dc nets [1] ?
[1] The Dining Cryptographers Problem:
Unconditional Sender and Recipient Untraceability (David Chaum)
DC nets have two major drawbacks: they
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Wasabee,
I'm no expert either but I'll try to answer to the best of my
understanding. I'm CCing Henry Corrigan-Gibbs, one of the Dissent
designers, who will hopefully correct my mistakes. :-)
On 03/07/13 17:11, Wasabee wrote:
is it really
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 30/06/13 20:32, Jacob Appelbaum wrote:
Michael Rogers:
I'd love to see a revitalisation of remailer research, focussing
on unlinkability (which we know many people would benefit from)
rather than sender anonymity (which fewer people need
So who's out there developing any useful protocols for anonymization today?
*Anybody*? Could we try to start a new project (if needed) to create one?
I'd love to see a revitalisation of remailer research, focussing on
unlinkability (which we know many people would benefit from) rather than
I don't think most non-programmers would differentiate between a string of hex
digits and an arbitrary alphanumeric string, so you might as well use base 32.
But do you really need to encode more bits? With a ZRTPish hash commitment /
key exchange / confirmation code structure you can detect a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 20/02/13 02:49, Jonathan Warren wrote:
Suppose when Alice firsts sends a message to Bob she also includes
a short term public key. Bob takes the short term public key and
encrypts symmetric_key_1 (SK1) and also encrypts a message with
SK1 and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 20/02/13 02:49, Jonathan Warren wrote:
Suppose when Alice firsts sends a message to Bob she also includes
a short term public key. Bob takes the short term public key and
encrypts symmetric_key_1 (SK1) and also encrypts a message with
SK1 and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Jonathan,
This looks like it could be a useful system, but I'm not sure I fully
understand it.
Each node is assumed to have a slowly changing set of addresses, is
that right? A node migrates between streams by choosing whether to
create new
46 matches
Mail list logo
