of "cover browsing" by the hub to random websites
doesn't add any significant protection if the goal is to provide
real-time access.
--
Kent Crispin "Be good, and you will be
[EMAIL PROTECTED],[EMAIL PROTECTED] lonesome."
ch connection and acted as initiator for both,
Presuming that Bob and Alice have previously exchanged correct public
keys, how does he do that?
--
Kent Crispin "Be good, and you will be
[EMAIL PROTECTED],[EMAIL PROTECTED] lonesome."
p:
aphy software
is pretty damn well founded.
--
Kent Crispin "Be good, and you will be
[EMAIL PROTECTED],[EMAIL PROTECTED] lonesome."
p: +1 310 823 9358 f: +1 310 823 8649 -- Mark Twain
e memory of the
computer, and disassemble it with a verified disassembler.
(eg, what shows as bss 0 in the assembler listing is really code; what shows
as one set of instructions in the listing is in reality different.)
Kent
--
Kent Crispin "Be good, and you will be
compromise ...
> not an assembler compromise.
The process you describe is a rather daunting task, especially given
that all that is really necessary is a very small bit of code to load
more code from a different file.
Kent
--
Kent Crispin "Be good, and you
On Thu, Apr 05, 2007 at 04:49:33PM -0700, Paul Hoffman wrote:
> At 7:26 PM -0400 4/5/07, Thor Lancelot Simon wrote:
> >On Thu, Apr 05, 2007 at 07:32:09AM -0700, Paul Hoffman wrote:
> >>
> >> Control: The root signing key only controls the contents of the root,
> >> not any level below the root.
> >
place in the docs)? I've used openvpn to set up dedicated
tunnels, but it isn't immediately obvious to me how it would be configured to
do opportunistic encryption.
--
Kent Crispin
[EMAIL PROTECTED]p: +1 310 823 9358 f: +1 310 823 8649
[EMAIL PROTECTED] SIP:
On 09/14/2013 03:29 PM, John Denker wrote:
Things like clock skew are usually nothing but squish ... not reliably
predictable, but also not reliably unpredictable. I'm not interested
in squish, and I'm not interested in speculation about things that
"might" be random.
I see "theoretical" the
On 09/15/2013 10:19 AM, John Kelsey wrote:
But those are pretty critical things, especially (a). You need to know
whether it is yet safe to generate your high-value keypair. For that,
you don't need super precise entropy estimates, but you do need at
least a good first cut entropy estimate--doe
John Kelsey wrote:
> I think the big problem with (b) is in quantifying the entropy you get.
Maybe don't.
When Bruce Schneier last put his hand to designing an RNG he concluded that
estimating entropy is doomed. I don't think he would object to some coarse
order-of-magnitude confirmation that t
Broken RNG-time again: In looking 2.2 million certificates, researchers
found reused primes in 103 of them.
News story:
http://arstechnica.com/security/2013/09/fatal-crypto-flaw-in-some-government-certified-smartcards-makes-forgery-a-snap/
Original paper: http://smartfacts.cr.yp.to/smartfact
On 09/18/2013 01:31 PM, Walter van Holst wrote:
What makes me a tad bitter is that we apparantly live in a world with
two classes: US citizens and the subhuman rest of it. NSA-style
blanket surveillance violates the fundamental right to privacy and
ultimately also the fundamental right to freed
On 10/01/2013 10:28 AM, Greg wrote:
This falls somewhere in the land of beyond-the-absurd.
I noticed the password would be mailed in the clear when I signed up,
but even if I had not, I would not have been bothered to later discover
it. What is the harm? The sensitivity of this password is
ting it using an actual
> TPM to send and receive email with it, which given the hit-and-miss
Done. :-) Last time I tested this it worked fine... Circa 2006...
Kent
> functionality and implementation quality of TPMs is more or less a required
> second step). I've implemented PGP
On Thu, Mar 5, 2009 at 12:13 PM, Kent Yoder wrote:
> Hi Peter,
>
>>>Apart from the obvious fact that if the TPM is good for DRM then it is also
>>>good for protecting servers and the data on them,
>>
>> In which way, and for what sorts of "protection&q
> I'd love to know how they plan to validate my Linux boxes.
OpenPTS [1] + TrouSerS [2] + Grub-IMA [3] + IMA [4] ;-)
Kent
[1] http://openpts.sourceforge.jp/
[2] http://trousers.sourceforge.net/
[3] http://sourceforge.jp/projects/openpts/wiki/GRUB-IMA
[4] http://linux-ima.sourcef
On 09/08/2013 06:16 PM, John Kelsey wrote:
I don't think you can do anything useful in crypto without some good
source of random bits.
I don't see the big worry about how hard it is to generate random
numbers unless:
a) You need them super fast (because you are Google, trying to secure
you
On 09/08/2013 09:15 PM, Perry E. Metzger wrote:
Perhaps you don't see the big worry, but real world experience says it
is something everyone else should worry about anyway.
I overstated it.
Good random numbers are crucial, and like any cryptography, exact
details matter. Programmers are cons
On 09/08/2013 11:56 PM, Jerry Leichter wrote:
Which brings into the light the question: Just *why* have so many random
number generators proved to be so weak.
Your three cases left off an important one: Not bothering to seed the
PRNG at all. I think the Java/Android cryptographic (!) librar
On 09/11/2013 07:18 PM, Perry E. Metzger wrote:
the world's routers, servers, etc. do not have good sources,
especially at first boot time, and for customer NAT boxes and the like
the price points are vicious.
I agree that things like consumer NAT boxes have a tricky problem, and
anything th
On 09/12/2013 10:41 AM, Kent Borg wrote:
routers and servers are not as bad off as people say.
Not that more sources is bad. A new trustworthy HW entropy source would
be good. Even a suspect rdrand is worth XORing in (as Linux does on the
machine I am using right now).
But if you thirst
On 09/13/2013 11:59 AM, Marcus Leech wrote:
Any physical-world sensor driver, where the sensor inherently has a
bit of noise, I think has a "moral obligation" to contribute bits to
the kernel entopy pool.
Within limits. Mixing the entropy pool on Linux takes work and battery
power.
Looking
22 matches
Mail list logo
