From: "Stephen D. Williams" <sdw@lig.net>
To: tabris <tabris@tabris.net>
Cc: "Hunt, Adam" <ahunt@solvone.com>, linux-kernel@vger.kernel.org
Subject: Re: High Quality Random sources, was: Re: SecuriKey
Date: Sun, 11 Jan 2004 23:10:47 -0500 [thread overview]
Message-ID: <40021E47.1070406@lig.net> (raw)
In-Reply-To: <200401112247.59418.tabris@tabris.net>
I was only commenting on the random source, not the rest of the
discussion about what a particular keyfob does. Most useful crypto is
public-key, i.e. asymmetric encryption, but one-time-pad is a useful
fallback since it really is unbreakable if you have a truly random source.
OTP absolutely requires that you share the OTP out of band, i.e. you
twin a capture of random data. Any transfer makes it as vulnerable as
the transfer method.
sdw
tabris wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Sunday 11 January 2004 10:38 pm, tabris wrote:
>
>
>>On Sunday 11 January 2004 7:39 pm, Stephen D. Williams wrote:
>>
>>
>>>Impossible? I think not. Some "mechanical" devices do exhibit true
>>>random capability, especially when enhanced by algorithmic means.
>>>To wit: http://www.lavarand.org/
>>>
>>>Let me know if you can prove their methods don't provide a true "high
>>>quality" random source.
>>>
>>>I'd like to see their code as a module with an automatic test to make
>>>sure that the random source is high quality. In this case, that
>>>would mean making sure that the cap was not off the camera.
>>>
>>>
Or, at least if it was that it was pointing at a Lava Lamp!
>>>sdw
>>>
>>>
>> just because it passes tests of entropy and probability doesn't make
>>it random. it just gets really really close. [hence pseudo-random]
>>Everybody knows that /dev/random isn't truly random (it's still a state
>>machine, dependent on a hash algorithm [chosen b/c they can take a
>>non-random source and make it 'LOOK' random], and you feed it with data
>>that is not totally predictable. BUT, there are still enough ways to
>>exploit it if you can control/influence the input). it just can pass
>>enough tests so that it can be used.
>>
>>
>tere are devices such as this that I admit to not knowing of until now...
>
>
>> and that still doesn't answer the question of how one would use [such
>>a device] to 'generate a one time pad'. a one time pad must be
>>possessed by both parties that are communicating. and if you have a
>>secure channel to transmit an OTP, then you have one that can carry a
>>message as well (most commonly, an OTP is used with a time delay. there
>>is a single time when a secure channel is available. one [or both] of
>>the parties brings it with him/her when he/she travels.
>>
>> so i'd believe that mebbe this Securikey could hold one... but, any
>>USB key-fob type device can.
>>
>>
>Perhaps I should make an amendment. you could perhaps put a geiger counter
>and cobalt or other radioactive source into a key fob... but i don't
>think it would ever be considered 'safe' to carry.
>
>other sources may be available as well (i admit to not getting the time to
>read the website until just now). doesn't look like it fits in a USB
>key-fob yet tho.
>
>
>> I'm sure that someone else can be more knowledgeable on this than I,
>>but the general theory holds fast.
>>
>>
>
>- --
>If it's worth doing, it's worth doing for money.
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.3 (GNU/Linux)
>
>iD8DBQFAAhju1U5ZaPMbKQcRAtDvAJoD1Jm/u3PlJ4EnUQXrPeUjLq14pQCfct9j
>1zyYmroBRfkW37/ErNREEx8=
>=UrEJ
>-----END PGP SIGNATURE-----
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
next prev parent reply other threads:[~2004-01-12 4:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-11 15:44 SecuriKey Hunt, Adam
2004-01-11 19:46 ` SecuriKey tabris
2004-01-12 0:39 ` High Quality Random sources, was: SecuriKey Stephen D. Williams
2004-01-12 3:38 ` tabris
2004-01-12 3:47 ` tabris
2004-01-12 4:10 ` Stephen D. Williams [this message]
2004-01-12 5:57 ` Valdis.Kletnieks
2004-01-12 6:19 ` Stephen D. Williams
2004-01-12 4:16 ` Mark Borgerding
2004-01-12 20:37 ` SecuriKey David Schwartz
2004-01-12 21:27 ` SecuriKey Richard B. Johnson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40021E47.1070406@lig.net \
--to=sdw@lig.net \
--cc=ahunt@solvone.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tabris@tabris.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox