Does anyone know anything about SecuriKey devices (http://www.securikey.com)? They are a little USB fob that looks kind of like a pen drive. I assume they are just some type of one-time-pad generator but don't have one to play with. This sounds like the perfect device to implement as a LSM.
--adam
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 11 January 2004 10:44 am, Hunt, Adam wrote:
> Does anyone know anything about SecuriKey devices (http://www.securikey.com)?
> They are a little USB fob that looks kind of like a pen drive. I
> assume they are just some type of one-time-pad generator but don't have
> one to play with. This sounds like the perfect device to implement as
> a LSM.
>
> --adam
> -
How do you generate a one-time-pad? a one time pad must be by definition
truly random, and be used only once. and if you can send the Securikey
via a secure channel at the same time as the message, then you don't need
the OTP.
I should also mention that the problem with 'generating' an OTP via any
mechanical or algorithmic means is impossible as at best an OTP will only
be pseudo-random, and therefore with identical inputs (assuming it is
possible, which we can assume here for the sake of theory and security),
the same OTP can be generated, thus breaking our assumption/necessity of
non-deterministic output.
I'd say more but I'm on my way to work.
- --
tabris
- -
I do not know whether I was then a man dreaming I was a butterfly, or
whether I am now a butterfly dreaming I am a man.
-- Chuang-tzu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFAAagR1U5ZaPMbKQcRAmo2AJ0Wc6xTLCd/swZYlEO6emktLhOtRgCfUUP5
OB4YFi6bh1yrVMzGIoN6XNs=
=O/uT
-----END PGP SIGNATURE-----
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.
sdw
tabris wrote:
>...
> I should also mention that the problem with 'generating' an OTP via any
>mechanical or algorithmic means is impossible as at best an OTP will only
>be pseudo-random, and therefore with identical inputs (assuming it is
>possible, which we can assume here for the sake of theory and security),
>the same OTP can be generated, thus breaking our assumption/necessity of
>non-deterministic output.
>
> I'd say more but I'm on my way to work.
>- --
>tabris
>- -
>I do not know whether I was then a man dreaming I was a butterfly, or
>whether I am now a butterfly dreaming I am a man.
> -- Chuang-tzu
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.3 (GNU/Linux)
>
>iD8DBQFAAagR1U5ZaPMbKQcRAmo2AJ0Wc6xTLCd/swZYlEO6emktLhOtRgCfUUP5
>OB4YFi6bh1yrVMzGIoN6XNs=
>=O/uT
>-----END PGP SIGNATURE-----
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
--
[email protected] http://www.hpti.com Personal: [email protected] http://sdw.st
Stephen D. Williams 703-724-0118W 703-995-0407Fax 20147-4622 AIM: sdw
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
>
> 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.
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.
I'm sure that someone else can be more knowledgeable on this than I, but
the general theory holds fast.
- --
tabris
- -
optimist, n.:
A proponent of the belief that black is white.
A pessimist asked God for relief.
"Ah, you wish me to restore your hope and cheerfulness," said God.
"No," replied the petitioner, "I wish you to create something that
would justify them."
"The world is all created," said God, "but you have overlooked
something -- the mortality of the optimist."
-- Ambrose Bierce, "The Devil's Dictionary"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFAAha21U5ZaPMbKQcRAi75AJwJQumzquOuyt0FY7BSlSDL80/szgCfVvWC
myboGReQJjI3hy+lvQcIRAU=
=ll/K
-----END PGP SIGNATURE-----
-----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.
> >
> > 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-----
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 [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
Disregarding the debates of true vs. pseudo randomness, ( an argument
best left to cypherpunks, philosophers, and quantum physicists ) -- let
me repeat the question the original poster asked ...
Does anyone have any info about securikey? The "white papers" on their
website are nothing but fluff.
It smells like snake oil to me -- probably just a thumbdrive with an
authentication driver.
Unless it actually encrypts the hard disk, it can't provide much security.
The system can most likely still be booted from a floppy or cdrom.
-
Mark Borgerding
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.
>
> sdw
>
> tabris wrote:
>
>> ...
>> I should also mention that the problem with 'generating' an OTP
>> via any mechanical or algorithmic means is impossible as at best an
>> OTP will only be pseudo-random, and therefore with identical inputs
>> (assuming it is possible, which we can assume here for the sake of
>> theory and security), the same OTP can be generated, thus breaking
>> our assumption/necessity of non-deterministic output.
>>
>> I'd say more but I'm on my way to work.
>> - --
>> tabris
>> - -
>> I do not know whether I was then a man dreaming I was a butterfly, or
>> whether I am now a butterfly dreaming I am a man.
>> -- Chuang-tzu
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.2.3 (GNU/Linux)
>>
>> iD8DBQFAAagR1U5ZaPMbKQcRAmo2AJ0Wc6xTLCd/swZYlEO6emktLhOtRgCfUUP5
>> OB4YFi6bh1yrVMzGIoN6XNs=
>> =O/uT
>> -----END PGP SIGNATURE-----
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-kernel" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>>
>
>
On Sun, 11 Jan 2004 23:10:47 EST, "Stephen D. Williams" said:
> 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.
The single most common OTP-related offense of Schneier's "snake oil crypto"
has got to be the fact it's almost never only used exactly once and then discarded.
So sure you can load 200 meg of OTP into the dongle before you leave the spy agency
on a mission. The fun starts when you get to the 201st megabyte of data. :)
It has puzzled me for a while why it doesn't occur to people that a high
quality OTP is a high quality source of shared private keys for a good
symmetric algorithm. That is a much better use than 1-to-1 XOR. Sure,
you're still only as secure as the symmetric algorithm but if you can
manage distribution of a OTP, you don't have to otherwise worry about
key management other than walking through the keys so that they are only
used once. 128MB+ (or 200MB or 1GB) represents a lot of AES keys.
With that many, you could just skip around on a non-key aligned random
point (using your high-quality random source of course ;-) ), transmit
the point you are using as a key selector, and not worry about avoiding
reuse management.
PKI is better for many reasons, but it's still interesting that an
essentially low-tech technique like OTP could be used in a similar way.
You still have an N^2 key exchange problem that PKI solves.
sdw
[email protected] wrote:
>On Sun, 11 Jan 2004 23:10:47 EST, "Stephen D. Williams" said:
>
>
>
>>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.
>>
>>
>
>The single most common OTP-related offense of Schneier's "snake oil crypto"
>has got to be the fact it's almost never only used exactly once and then discarded.
>
>So sure you can load 200 meg of OTP into the dongle before you leave the spy agency
>on a mission. The fun starts when you get to the 201st megabyte of data. :)
>
>
> How do you generate a one-time-pad? a one time pad must be
> by definition
> truly random, and be used only once. and if you can send the Securikey
> via a secure channel at the same time as the message, then you don't need
> the OTP.
To truly qualify as an OTP, the data would have to be random, used once,
and somehow securely transfered to both ends of what will be the secure
channel. This is, shall we say politely, seldom done for modern
cryptography.
However, many modern encryption schemes do require data that must be
unpredictable. If you want to encrypt a message using RSA, you generally use
a random key for a symmetric cypher and use RSA to protect the random key
rather than the (usually larger) message itself.
> I should also mention that the problem with 'generating' an
> OTP via any
> mechanical or algorithmic means is impossible as at best an OTP will only
> be pseudo-random, and therefore with identical inputs (assuming it is
> possible, which we can assume here for the sake of theory and security),
> the same OTP can be generated, thus breaking our assumption/necessity of
> non-deterministic output.
Except we don't live in a deterministic world, we live in a quantum world.
It is nearly trivial to mechanically produce data that is truly random. All
you need is a reverse biased zener diode.
Even if you do believe the world is deterministic, against the weight of
modern science, I really doubt you believe that anyone outside a sealed box
can predict microscopic zone temperature variations within a box and
therefore predict the phase jitter between two crystal oscillators inside
it.
DS
On Mon, 12 Jan 2004, David Schwartz wrote:
>
> > How do you generate a one-time-pad? a one time pad must be
> > by definition
> > truly random, and be used only once. and if you can send the Securikey
> > via a secure channel at the same time as the message, then you don't need
> > the OTP.
>
> To truly qualify as an OTP, the data would have to be random, used once,
> and somehow securely transfered to both ends of what will be the secure
> channel. This is, shall we say politely, seldom done for modern
> cryptography.
>
> However, many modern encryption schemes do require data that must be
> unpredictable. If you want to encrypt a message using RSA, you generally use
> a random key for a symmetric cypher and use RSA to protect the random key
> rather than the (usually larger) message itself.
>
> > I should also mention that the problem with 'generating' an
> > OTP via any
> > mechanical or algorithmic means is impossible as at best an OTP will only
> > be pseudo-random, and therefore with identical inputs (assuming it is
> > possible, which we can assume here for the sake of theory and security),
> > the same OTP can be generated, thus breaking our assumption/necessity of
> > non-deterministic output.
>
> Except we don't live in a deterministic world, we live in a quantum world.
> It is nearly trivial to mechanically produce data that is truly random. All
> you need is a reverse biased zener diode.
>
> Even if you do believe the world is deterministic, against the weight of
> modern science, I really doubt you believe that anyone outside a sealed box
> can predict microscopic zone temperature variations within a box and
> therefore predict the phase jitter between two crystal oscillators inside
> it.
>
> DS
>
Also, the data need not be random, but simply unpredictable. There
are many ways of generating such data, even without hardware. It
is possible to do it, entirely in software. The result can be verified
to never repeat, because the code takes time to execute and, therefore,
the time at which the code is executed will never repeat (time increases
always). Even artifically resetting the time will result in an
unpredictable jitter, making it provably difficult (like "nearly"
impossible) to repeat the same sequence generation if the code is
written towards this goal. Simple example:
Use the microseconds of time as a seed for rand() (rand() is not optimum,
but doesn't have to be).
Modify the number in some manner dependent upon the number of received
network interrupts (perhaps XOR). Wait until the number of network
interrupts increases, use microseconds of time to further modify the
result.
Here we are:
10: 198919 199027 IO-APIC-level eth0
The resulting integer can be bounded, but not predicted. It is
likely good enough for one of the components of a cipher. In
this manner, the starting parameter (seed) for the RND is
made unpredictable, then the result is further scrambled by
a non-deterministic external event. By using the fact that
time always increases, plus modification by something that
no code has control over (the network events), one can show
that the result can't be predicted. That's what is needed
for cipher components.
This is not a good way of obtaining unpredictable numbers because
of the long time necessary and the requirement for external
events like network interrupts, but it shows the mechanism.
Could you guess that it would become:
10: 198924 199076 IO-APIC-level eth0
Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.