On Thu, Apr 7, 2011 at 6:26 PM, Gisle Vanem wrote:
> Another patch for this:
Looks good, except that tmp is a non-const variable and the string is
going to be const. Does the tweaked version I attached work for you?
--
Nick
From 70e02914682eb1959d8b385f76b5acf7486158cc Mon Sep 17 00:00:00 2001
"Nick Mathewson" wrote:
Sounds fine to me. Alternatively, I believe we could just call
GetTempPath(): that's what it's there for.
Agreed. I first thought of using GetTempPath() but that involves another
buffer and checking the ret-val. It's safes though. From:
http://msdn.microsoft.com/en-
On Thu, Apr 07, 2011 at 11:20:00PM +0100, Steven J. Murdoch wrote:
> On Thu, Apr 07, 2011 at 06:13:45PM -0400, Nick Mathewson wrote:
> > Oh! Also, for a bit of redundancy, I'm thinking that the symmetric
> > crypto parts of the improved onion handshakes ought to be with a less
> > malleable mode o
On Thu, Apr 07, 2011 at 06:13:45PM -0400, Nick Mathewson wrote:
> Oh! Also, for a bit of redundancy, I'm thinking that the symmetric
> crypto parts of the improved onion handshakes ought to be with a less
> malleable mode of operation than the counter-mode stuff we do now.
Yes. Absolute necessit
On Thu, Apr 07, 2011 at 06:13:45PM -0400, Nick Mathewson wrote:
> Oh! Also, for a bit of redundancy, I'm thinking that the symmetric
> crypto parts of the improved onion handshakes ought to be with a less
> malleable mode of operation than the counter-mode stuff we do now.
> Perhaps we could make
On Thu, Apr 7, 2011 at 5:18 PM, Nick Mathewson wrote:
[...]
> Here's a first cut of what I think might go in a hypothetical
> diffie-hellman based handshake
I'm deliberately *not* using MQV, HMQV, FHMQV, etc etc here. They're
faster than the "Just do DH twice" thing I wrote up, but the patent
s
On Thu, Apr 7, 2011 at 6:04 PM, Ian Goldberg wrote:
[...]
> The phrase that jumps to mind is, "Danger Will Robinson!". ;-) If
> we're redesigning the AKE (authenticated key agreement) bits, we
> probably shouldn't just make up our own stuff.
Indeed! I am hoping that by threatening to do so, I
On Thu, Apr 07, 2011 at 05:18:12PM -0400, Nick Mathewson wrote:
> 8) This is totally back-of-the-envelope stuff, but it might be a good
> starting point for crypto discussion.
>
> Here's a first cut of what I think might go in an improved RSA handshake:
>
> * First 8 bytes of the SHA256 hash of
On Thu, Apr 7, 2011 at 5:17 PM, Steven J. Murdoch
wrote:
> On Thu, Apr 07, 2011 at 05:10:05PM -0400, Nick Mathewson wrote:
>> On Thu, Apr 7, 2011 at 3:48 PM, Gisle Vanem wrote:
>> > - "c:\\windows\\temp\\tor_test_%d", (int)getpid());
>> > + "%s\\tor_test_%d", getenv("T
On Thu, Apr 07, 2011 at 05:10:05PM -0400, Nick Mathewson wrote:
> On Thu, Apr 7, 2011 at 3:48 PM, Gisle Vanem wrote:
> > - "c:\\windows\\temp\\tor_test_%d", (int)getpid());
> > + "%s\\tor_test_%d", getenv("TEMP"), (int)getpid());
>
> What guarantees that TEMP will alwa
On Thu, Mar 31, 2011 at 5:52 AM, Robert Ransom wrote:
Hi! I'm going to wait on a full review of your create/extend proposal
till it's done, but I though I could potentially answer some questions
and offer some comments:
1) I think CREATE cells need to get a field asking for a specific way
of ha
On Thu, Apr 7, 2011 at 3:48 PM, Gisle Vanem wrote:
> I don't think it's a good idea to use hard-coded paths. Even in a
> test source-file. Easy patch:
>
> --- Git-latest\src\test\test.c Wed Mar 30 11:58:28 2011
> +++ src\test\test.c Thu Mar 31 14:06:14 2011
> @@ -86,7 +86,7 @@
> #ifdef MS_W
Howdy,
> There is a libtor, but it's just an internal library that contains some
> of the functions shared between the various Tor tools as they're built.
> It isn't designed for outside apps to link to, and it doesn't actually
> offer the API that you'd want.
Thanks for clarifying that.
> But y
I don't think it's a good idea to use hard-coded paths. Even in a
test source-file. Easy patch:
--- Git-latest\src\test\test.c Wed Mar 30 11:58:28 2011
+++ src\test\test.c Thu Mar 31 14:06:14 2011
@@ -86,7 +86,7 @@
#ifdef MS_WINDOWS
//
tor_snprintf(temp_dir, sizeof(temp_dir),
-
14 matches
Mail list logo
