Hey guys,
I was wondering if anyone could point me to some documentation and/or sample code that may have implemented SHA1 or MD5 for creation of a hash of a file within a fsd. I would be interested to know about tips, tricks and traps in doing so, without having to go to usermode to do the dirty work.
Anyone know of such a thing?
–
Regards,
Dana Epp
[Blog: http://silverstr.ufies.org/blog/]
Google turned this up. It should be no problems to port to NT kernel mode. I
also suspect a good book or text on SHA-1 should be sufficient to write your
own.
http://www.thefreecountry.com/sourcecode/encryption.shtml
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dana Epp
Sent: Sunday, October 03, 2004 9:07 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Implimenting digest hashing in the Kernel
Hey guys,
I was wondering if anyone could point me to some documentation and/or sample
code that may have implemented SHA1 or MD5 for creation of a hash of a file
within a fsd. I would be interested to know about tips, tricks and traps in
doing so, without having to go to usermode to do the dirty work.
Anyone know of such a thing?
–
Regards,
Dana Epp
[Blog: http://silverstr.ufies.org/blog/]
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
__________ NOD32 1.860 (20040903) Information __________
This message was checked by NOD32 antivirus system.
http://www.nod32.com
Thanks for the info Jamey,
I am aware that there is a lot of open source code out there. I was more looking for work that may be using Microsoft’s CryptoAPI and the stuff in wincrypt.h for the kernel to get the work done.
I am a firm believer that writing your own crypto is a bad thing. Even trying to implement your own version of an existing algorithm should be frowned up; many people smarter than me have tried and failed. And thats why most cipherpunks and mathematicians have very little hair… they already had to walk that path 
In a pinch I can port the openssl code that handles SHA1… thats not a real concern. What I am hoping though is that there is a more “Microsoft” way in accomplishing that.
Anyone know of such a method?
Jamey Kirby wrote:
Google turned this up. It should be no problems to port to NT kernel mode. I
also suspect a good book or text on SHA-1 should be sufficient to write your
own.http://www.thefreecountry.com/sourcecode/encryption.shtml
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dana Epp
Sent: Sunday, October 03, 2004 9:07 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Implimenting digest hashing in the KernelHey guys,
I was wondering if anyone could point me to some documentation and/or sample
code that may have implemented SHA1 or MD5 for creation of a hash of a file
within a fsd. I would be interested to know about tips, tricks and traps in
doing so, without having to go to usermode to do the dirty work.Anyone know of such a thing?
–
Regards,
Dana Epp
[Blog: http://silverstr.ufies.org/blog/]
> I am aware that there is a lot of open source code out there.
I was more looking for work that may be using Microsoft’s
CryptoAPI and the stuff in wincrypt.h for the kernel to get the work done.
Well, this is possible. EFS does it his way. If NTFS finds an encrypted
file, it calls an EFS-defined function which has to decrypt the file.
EFS then connects with LSASS (hopefully I’m not wrong)
through LPC. LSASS decrypts the file content and NTFS
shows the decrypted content.
If you want to go this way, you will have to find a LPC documentation,
or think out some other communication. You will also have to
solve many other problems.
I am a firm believer that writing your own crypto is a bad thing.
I wonder how the “encryption people” here in this forum have done
that. Did you take an open source encryption sources
or did you take something compiled (and maybe already certified) ?
L.
You aren’t going to be able to call CryptoAPI from kernel mode (unless
there is some undocumented kernel mode interface that I don’t know
about). SHA1 is really easy to implement in kernel mode and the link
that Jamey posted is probably your best bet.
If you are concerned about your implementation of the algorithm, or
indeed even if you are not concerned, you should run your algorithm
against the NIST test vectors (http://csrc.nist.gov/cryptval/shs.html)
to make sure your implementation is correct.
Ben Curley
DESlock+ Lead Developer
Data Encryption Systems Ltd.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dana Epp
Sent: 04 October 2004 08:10
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Implimenting digest hashing in the Kernel
Thanks for the info Jamey,
I am aware that there is a lot of open source code out there. I was more
looking for work that may be using Microsoft’s CryptoAPI and the stuff
in wincrypt.h for the kernel to get the work done.
I am a firm believer that writing your own crypto is a bad thing. Even
trying to implement your own version of an existing algorithm should be
frowned up; many people smarter than me have tried and failed. And thats
why most cipherpunks and mathematicians have very little hair… they
already had to walk that path
In a pinch I can port the openssl code that handles SHA1… thats not a
real concern. What I am hoping though is that there is a more
“Microsoft” way in accomplishing that.
Anyone know of such a method?
Jamey Kirby wrote:
Google turned this up. It should be no problems to port to NT kernel
mode. I also suspect a good book or text on SHA-1 should be sufficient
to write your own.
http://www.thefreecountry.com/sourcecode/encryption.shtml
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dana Epp
Sent: Sunday, October 03, 2004 9:07 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Implimenting digest hashing in the KernelHey guys,
I was wondering if anyone could point me to some documentation and/or
sample code that may have implemented SHA1 or MD5 for creation of a
hash of a file within a fsd. I would be interested to know about tips,
tricks and traps in doing so, without having to go to usermode to do
the dirty work.Anyone know of such a thing?
–
Regards,
Dana Epp
[Blog: http://silverstr.ufies.org/blog/]
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@des.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com
Do you have any idea why they include wincrypt.h and the crypt*.lib in the DDK then?
Ben Curley wrote:
You aren’t going to be able to call CryptoAPI from kernel mode (unless
there is some undocumented kernel mode interface that I don’t know
about). SHA1 is really easy to implement in kernel mode and the link
that Jamey posted is probably your best bet.If you are concerned about your implementation of the algorithm, or
indeed even if you are not concerned, you should run your algorithm
against the NIST test vectors (http://csrc.nist.gov/cryptval/shs.html)
to make sure your implementation is correct.Ben Curley
DESlock+ Lead Developer
Data Encryption Systems Ltd.-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dana Epp
Sent: 04 October 2004 08:10
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Implimenting digest hashing in the KernelThanks for the info Jamey,
I am aware that there is a lot of open source code out there. I was more
looking for work that may be using Microsoft’s CryptoAPI and the stuff
in wincrypt.h for the kernel to get the work done.I am a firm believer that writing your own crypto is a bad thing. Even
trying to implement your own version of an existing algorithm should be
frowned up; many people smarter than me have tried and failed. And thats
why most cipherpunks and mathematicians have very little hair… they
already had to walk that pathIn a pinch I can port the openssl code that handles SHA1… thats not a
real concern. What I am hoping though is that there is a more
“Microsoft” way in accomplishing that.Anyone know of such a method?
Jamey Kirby wrote:
>Google turned this up. It should be no problems to port to NT kernel
>mode. I also suspect a good book or text on SHA-1 should be sufficient>to write your own.
>
>http://www.thefreecountry.com/sourcecode/encryption.shtml
>
>Jamey
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of Dana Epp
>Sent: Sunday, October 03, 2004 9:07 PM
>To: Windows File Systems Devs Interest List
>Subject: [ntfsd] Implimenting digest hashing in the Kernel
>
>Hey guys,
>
>I was wondering if anyone could point me to some documentation and/or
>sample code that may have implemented SHA1 or MD5 for creation of a
>hash of a file within a fsd. I would be interested to know about tips,>tricks and traps in doing so, without having to go to usermode to do
the dirty work.
>Anyone know of such a thing?
>–
Regards,
Dana Epp
[Blog: http://silverstr.ufies.org/blog/]
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17You are currently subscribed to ntfsd as: xxxxx@des.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
–
Regards,
Dana Epp
[Blog: http://silverstr.ufies.org/blog/]
They included most of the includes and libraries from the SDK to make this a
standalone product. Since windows.h includes wincrypt.h and is used in some
of the user space code, you need wincrypt.h and the libraries.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
“Dana Epp” wrote in message news:xxxxx@ntfsd…
> Do you have any idea why they include wincrypt.h and the crypt*.lib in the
DDK then?
>
>
> Ben Curley wrote:
>
> > You aren’t going to be able to call CryptoAPI from kernel mode (unless
> > there is some undocumented kernel mode interface that I don’t know
> > about). SHA1 is really easy to implement in kernel mode and the link
> > that Jamey posted is probably your best bet.
> >
> > If you are concerned about your implementation of the algorithm, or
> > indeed even if you are not concerned, you should run your algorithm
> > against the NIST test vectors (http://csrc.nist.gov/cryptval/shs.html)
> > to make sure your implementation is correct.
> >
> > Ben Curley
> > DESlock+ Lead Developer
> > Data Encryption Systems Ltd.
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Dana Epp
> > Sent: 04 October 2004 08:10
> > To: Windows File Systems Devs Interest List
> > Subject: Re: [ntfsd] Implimenting digest hashing in the Kernel
> >
> > Thanks for the info Jamey,
> >
> > I am aware that there is a lot of open source code out there. I was more
> > looking for work that may be using Microsoft’s CryptoAPI and the stuff
> > in wincrypt.h for the kernel to get the work done.
> >
> > I am a firm believer that writing your own crypto is a bad thing. Even
> > trying to implement your own version of an existing algorithm should be
> > frowned up; many people smarter than me have tried and failed. And thats
> > why most cipherpunks and mathematicians have very little hair… they
> > already had to walk that path
> >
> > In a pinch I can port the openssl code that handles SHA1… thats not a
> > real concern. What I am hoping though is that there is a more
> > “Microsoft” way in accomplishing that.
> >
> > Anyone know of such a method?
> >
> >
> > Jamey Kirby wrote:
> >
> >
> >>Google turned this up. It should be no problems to port to NT kernel
> >>mode. I also suspect a good book or text on SHA-1 should be sufficient
> >
> >
> >>to write your own.
> >>
> >>http://www.thefreecountry.com/sourcecode/encryption.shtml
> >>
> >>Jamey
> >>
> >>-----Original Message-----
> >>From: xxxxx@lists.osr.com
> >>[mailto:xxxxx@lists.osr.com] On Behalf Of Dana Epp
> >>Sent: Sunday, October 03, 2004 9:07 PM
> >>To: Windows File Systems Devs Interest List
> >>Subject: [ntfsd] Implimenting digest hashing in the Kernel
> >>
> >>Hey guys,
> >>
> >>I was wondering if anyone could point me to some documentation and/or
> >>sample code that may have implemented SHA1 or MD5 for creation of a
> >>hash of a file within a fsd. I would be interested to know about tips,
> >
> >
> >>tricks and traps in doing so, without having to go to usermode to do
> >
> > the dirty work.
> >
> >>Anyone know of such a thing?
> >>
> >
> >
> >
> > –
> > Regards,
> > Dana Epp
> > [Blog: http://silverstr.ufies.org/blog/]
> >
> >
> > —
> > Questions? First check the IFS FAQ at
> > https://www.osronline.com/article.cfm?id=17
> >
> > You are currently subscribed to ntfsd as: xxxxx@des.co.uk
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
> >
> > You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> –
> Regards,
> Dana Epp
> [Blog: http://silverstr.ufies.org/blog/]
>
>
So like most of the other SDK libs, does this mean its unsafe to use the CryptoAPI in kernelspace? I am guessing yes, but want to confirm.
Don Burn wrote:
They included most of the includes and libraries from the SDK to make this a
standalone product. Since windows.h includes wincrypt.h and is used in some
of the user space code, you need wincrypt.h and the libraries.
–
Regards,
Dana Epp
[Blog: http://silverstr.ufies.org/blog/]
You cannot use it in the kernel.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
“Dana Epp” wrote in message news:xxxxx@ntfsd…
> So like most of the other SDK libs, does this mean its unsafe to use the
CryptoAPI in kernelspace? I am guessing yes, but want to confirm.
>
> Don Burn wrote:
> > They included most of the includes and libraries from the SDK to make
this a
> > standalone product. Since windows.h includes wincrypt.h and is used in
some
> > of the user space code, you need wincrypt.h and the libraries.
> >
> >
>
>
> –
> Regards,
> Dana Epp
> [Blog: http://silverstr.ufies.org/blog/]
>
>
Thanks Don.
Don Burn wrote:
You cannot use it in the kernel.
–
Regards,
Dana Epp
[Blog: http://silverstr.ufies.org/blog/]
Look in the include directory. If a header doesn’t appear in the ddk sub
tree, it is usually not suitable for kernel mode. I guess Microsoft could
have segregated the libraries this way too, but they didn’t.
“Dana Epp” wrote in message news:xxxxx@ntfsd…
> So like most of the other SDK libs, does this mean its unsafe to use the
> CryptoAPI in kernelspace? I am guessing yes, but want to confirm.
> Don Burn wrote:
>> They included most of the includes and libraries from the SDK to make
>> this a
>> standalone product. Since windows.h includes wincrypt.h and is used in
>> some
>> of the user space code, you need wincrypt.h and the libraries.
>>
>>
>
>
> –
> Regards,
> Dana Epp
> [Blog: http://silverstr.ufies.org/blog/]
>
>
There were some description on interfaces to Fips.sys driver, which is a
kernel-mode CryptoAPI.
Anyway the reference implementation of MD5 is inside the same RFC, so, just
copy-paste it.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Dana Epp”
To: “Windows File Systems Devs Interest List”
Sent: Monday, October 04, 2004 11:10 AM
Subject: Re: [ntfsd] Implimenting digest hashing in the Kernel
> Thanks for the info Jamey,
>
> I am aware that there is a lot of open source code out there. I was more
looking for work that may be using Microsoft’s CryptoAPI and the stuff in
wincrypt.h for the kernel to get the work done.
>
> I am a firm believer that writing your own crypto is a bad thing. Even trying
to implement your own version of an existing algorithm should be frowned up;
many people smarter than me have tried and failed. And thats why most
cipherpunks and mathematicians have very little hair… they already had to
walk that path
>
> In a pinch I can port the openssl code that handles SHA1… thats not a real
concern. What I am hoping though is that there is a more “Microsoft” way in
accomplishing that.
>
> Anyone know of such a method?
>
>
> Jamey Kirby wrote:
>
> > Google turned this up. It should be no problems to port to NT kernel mode.
I
> > also suspect a good book or text on SHA-1 should be sufficient to write
your
> > own.
> >
> > http://www.thefreecountry.com/sourcecode/encryption.shtml
> >
> > Jamey
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Dana Epp
> > Sent: Sunday, October 03, 2004 9:07 PM
> > To: Windows File Systems Devs Interest List
> > Subject: [ntfsd] Implimenting digest hashing in the Kernel
> >
> > Hey guys,
> >
> > I was wondering if anyone could point me to some documentation and/or
sample
> > code that may have implemented SHA1 or MD5 for creation of a hash of a file
> > within a fsd. I would be interested to know about tips, tricks and traps in
> > doing so, without having to go to usermode to do the dirty work.
> >
> > Anyone know of such a thing?
> >
>
>
> –
> Regards,
> Dana Epp
> [Blog: http://silverstr.ufies.org/blog/]
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> EFS then connects with LSASS (hopefully I’m not wrong)
through LPC. LSASS decrypts the file content and NTFS
Not so. EFS contacts LSA to decrypt the file encryption key (FEK), since this
requires the knowledge of the user’s password, and nobody except LSA has this
knowledge.
After this, EFS decrypts itself, using the FEK returned by LSA.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> So like most of the other SDK libs, does this mean its unsafe to use the
CryptoAPI in
kernelspace? I am guessing yes, but want to confirm.
It’s undocumented, but I saw the description somewhere.
Anyway if we are speaking about MD5 - I would copy-paste the reference
implementation from the RFC. Simpler.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Hi,
I have a fsd which is basically a redirector communicating with a DAV
server.
There is a requirement where I need to store user’s password
somewhere in Kernel memory, just to refresh the connection on timeout. But I
can’t keep it in cleartext, so suggest me some ways to encrypt this password
and just make it available during reconnection.
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntfsd…
> > EFS then connects with LSASS (hopefully I’m not wrong)
> > through LPC. LSASS decrypts the file content and NTFS
>
> Not so. EFS contacts LSA to decrypt the file encryption key (FEK), since
this
> requires the knowledge of the user’s password, and nobody except LSA has
this
> knowledge.
>
> After this, EFS decrypts itself, using the FEK returned by LSA.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
>
There are plenty of interesting ways to do this. I guess it would help if you could profile the attacker in the situation to determine how far you want to take it. Knowing what risks you are susceptible to will go a long way to choosing the best method. Whenever possible you shouldn’t store a user’s password; not sure if that applies or not on your needs to refresh on a connection timeout.
With that said, I am always for using the security available in the OS where possible. Could you fire up to a usermode service and use the Data Protection API (DPAPI) to store the password until needed? There is a good section in “Writing Secure Code” by Michael Howard that discusses how to use this API effectively.
If you have to stay in the kernel, it becomes more difficult without some code overhead. One method to consider is in using guard pages to prevent unauthorized reads on regions of memory using VirtualProtect(). Of course you end up having to mod the perms for the whole memory page, but its something you can consider.
Just a few thoughts off the top of my head. I would seriously recommend you threat model this part of your app and decide if you even need to store the password; if you do… try finding the least impact on your code by using what is available in the operating system.
Gaurav Krishna wrote:
Hi,
I have a fsd which is basically a redirector communicating with a DAV
server.
There is a requirement where I need to store user’s password
somewhere in Kernel memory, just to refresh the connection on timeout. But I
can’t keep it in cleartext, so suggest me some ways to encrypt this password
and just make it available during reconnection.“Maxim S. Shatskih” wrote in message
> news:xxxxx@ntfsd…
>
>>>EFS then connects with LSASS (hopefully I’m not wrong)
>>>through LPC. LSASS decrypts the file content and NTFS
>>
>>Not so. EFS contacts LSA to decrypt the file encryption key (FEK), since
>
> this
>
>>requires the knowledge of the user’s password, and nobody except LSA has
>
> this
>
>>knowledge.
>>
>>After this, EFS decrypts itself, using the FEK returned by LSA.
>>
>>Maxim Shatskih, Windows DDK MVP
>>StorageCraft Corporation
>>xxxxx@storagecraft.com
>>http://www.storagecraft.com
>>
>>
>>
>
>
>
>
> —
> Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@vulscan.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
–
Regards,
Dana Epp
[Blog: http://silverstr.ufies.org/blog/]
It is safe to keep the cleartext passwords in nonpaged kernel memory.
LSA itself does this, using the VirtualLocked memory for this.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Gaurav Krishna”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Thursday, October 28, 2004 11:53 PM
Subject: Re:[ntfsd] Implimenting digest hashing in the Kernel
> Hi,
>
> I have a fsd which is basically a redirector communicating with a DAV
> server.
> There is a requirement where I need to store user’s password
> somewhere in Kernel memory, just to refresh the connection on timeout. But I
> can’t keep it in cleartext, so suggest me some ways to encrypt this password
> and just make it available during reconnection.
>
>
>
>
> “Maxim S. Shatskih” wrote in message
> news:xxxxx@ntfsd…
> > > EFS then connects with LSASS (hopefully I’m not wrong)
> > > through LPC. LSASS decrypts the file content and NTFS
> >
> > Not so. EFS contacts LSA to decrypt the file encryption key (FEK), since
> this
> > requires the knowledge of the user’s password, and nobody except LSA has
> this
> > knowledge.
> >
> > After this, EFS decrypts itself, using the FEK returned by LSA.
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
> >
>
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> With that said, I am always for using the security available in the OS where
possible. Could
you fire up to a usermode service and use the Data Protection API (DPAPI) to
store the
password until needed? There is a good section in “Writing Secure Code” by
Michael Howard
that discusses how to use this API effectively.
Copy-pasting from the reference implementation saves around 5 days of work at
least on inverted call path, and the API is also not this brain-damaged as MS’s
CryptoAPI is.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> ----------
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Maxim S. Shatskih[SMTP:xxxxx@storagecraft.com]
Reply To: Windows File Systems Devs Interest List
Sent: Friday, October 29, 2004 2:56 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Implimenting digest hashing in the Kernel> With that said, I am always for using the security available in the OS where
possible. Could
>you fire up to a usermode service and use the Data Protection API (DPAPI) to
store the
>password until needed? There is a good section in “Writing Secure Code” by
Michael Howard
>that discusses how to use this API effectively.Copy-pasting from the reference implementation saves around 5 days of work at
least on inverted call path, and the API is also not this brain-damaged as MS’s
CryptoAPI is.
I always wonder why people believe crypto and hash functions is some magic unattainable for normal programmer. In fact, most algorithms are straightforward and rather easy to implement (comparing to usual kernel mode work). The only problem can be speed optimization which is unnecessary in this case. There are reference implementations, free implementation with source and test vectors available. Just search and read. Ironically, trying to use CryptoAPI can be a lot of more work with no real advantage.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
Couple things might be to think about ?
How and where do you get the password form ? Is it user supplied ?. Upto
what point it would be
clear text ?. Sure after getting the hashed value, it might be safe …
There are some good discussion about what are the ways you could minimize
the exposure of plaintext thruout the systems in “Hackers Dissambly
uncoverd” by Kris Kaspersky, search amazon …
-pro
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Gaurav Krishna
Sent: Thursday, October 28, 2004 12:53 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Implimenting digest hashing in the Kernel
Hi,
I have a fsd which is basically a redirector communicating with a DAV
server.
There is a requirement where I need to store user’s password
somewhere in Kernel memory, just to refresh the connection on timeout. But I
can’t keep it in cleartext, so suggest me some ways to encrypt this password
and just make it available during reconnection.
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntfsd…
> > EFS then connects with LSASS (hopefully I’m not wrong)
> > through LPC. LSASS decrypts the file content and NTFS
>
> Not so. EFS contacts LSA to decrypt the file encryption key (FEK), since
this
> requires the knowledge of the user’s password, and nobody except LSA has
this
> knowledge.
>
> After this, EFS decrypts itself, using the FEK returned by LSA.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
>
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com