SecuriKey

SecuriKey

[Hunt, Adam]

Does anyone know anything about SecuriKey devices (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

Re: SecuriKey

[tabris]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 11 January 2004 10:44 am, Hunt, Adam wrote:
> Does anyone know anything about SecuriKey devices (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-----

High Quality Random sources, was: Re: SecuriKey

[Stephen D. Williams]

[-- Attachment #1: Type: text/plain, Size: 1697 bytes --]

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 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/
>  
>


-- 
swilliams@hpti.com http://www.hpti.com Personal: sdw@lig.net http://sdw.st
Stephen D. Williams 703-724-0118W 703-995-0407Fax 20147-4622 AIM: sdw


[-- Attachment #2: sdw.vcf --]
[-- Type: text/x-vcard, Size: 378 bytes --]

begin:vcard
fn:Stephen Williams
n:Williams;Stephen
org:High Performance Technologies, Inc.
adr:;;43392 Wayside Circle;Ashburn;VA;20147;US
email;internet:sdw@lig.net
title:Senior Technical Director
tel;work:703-724-0118
tel;fax:703-995-0407
tel;pager:sdwpage@lig.net
tel;home:703-729-5405
tel;cell:703-371-9362
x-mozilla-html:FALSE
url:http://www.hpti.com
version:2.1
end:vcard

Re: High Quality Random sources, was: Re: SecuriKey

[tabris]

-----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-----

Re: High Quality Random sources, was: Re: SecuriKey

[tabris]

-----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-----

Re: High Quality Random sources, was: Re: SecuriKey

[Stephen D. Williams]

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/
>  
>

Re: High Quality Random sources, was: Re: SecuriKey

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]

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. :)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: High Quality Random sources, was: Re: SecuriKey

[Stephen D. Williams]

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

Valdis.Kletnieks@vt.edu 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. :)
>  
>

Re: High Quality Random sources, was: Re: SecuriKey

[Mark Borgerding]

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 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/
>>  
>>
>
>

RE: SecuriKey

[David Schwartz]

> 	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

RE: SecuriKey

[Richard B. Johnson]

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.