Re: consulting question....
On 1243421494 seconds since the Beginning of the UNIX epoch Marcus Brinkmann wrote: However, it also sounds like they are shifting the burden of proof. Shouldn't they convince you (whoever they make the DRM for) that their system is working? Have we really reached a situation where non-experts believe that DRM works until proven otherwise? That seems an extraordinary marketing success of the sellers of DRM technology, because it stands against a mountain of evidence in the history of computing. I have noticed in my years as a security practitioner, that in my experience non-security people seem to assume that a system is perfectly secure until it is demonstrated that it is not with an example of an exploit. Until an exploit is generated, any discussion of insecurity is filed in their minds as ``academic'', ``theoretical'' or ``not real world''. This of course makes it quite difficult to cause various issues to be fixed in practice as it is generally more time consuming to construct and explain an exploit than to simply fix the bug that has been discovered. The next refrain that one is likely to hear even after demonstrating that a security issue exists is ``How many people know how to do that?'' I've actually heard that in some rather amusing circumstances such as ``Well, how many people actually know how to read or edit XML?'' It is a tricky conversation to explain to people that XML is not in fact an encryption mechanism---especially if they have seen any machine produced XML recently. Of course, this is one of the more amusing examples but others abound. I'm interested in asking people what rhetorical techniques they use to overcome such difficulties in practice? -- Roland Dowdeswell http://Imrryr.ORG/~elric/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CPRNGs are still an issue.
On 1227894567 seconds since the Beginning of the UNIX epoch Perry E. Metzger wrote: As it turns out, cryptographic pseudorandom number generators continue to be a good place to look for security vulnerabilities -- see the enclosed FreeBSD security advisory. The more things change, the more they stay the same... They failed to also mention that GBDE uses arc4random(9) to generate the keys which is uses to write data. So, any data written in the first five minutes after a boot may also be weakly keyed. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
analysis and implementation of LRW
In the last couple of days I have been considering implementing an LRW mode for CGD (http://www.imrryr.org/~elric/cgd) (CryptoGraphic Disk), but I haven't really seen a lot of cryptanalysis of it or found the canonical implementation. Has anyone here done the research? And if it is generally accepted as secure, is there a recommendation of an implementation that is BSD (or similar) licensed? Thanks, -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: comments wanted on gbde
I have started writing up a bit of an analysis of GBDE, which I would like to have people comment on before I continue with it. I.e. am I onto something here or not? I wrote this up very quickly over a few sleepless nights while trying to get my normal work done before I left on vacation, so please bear with me. The explanations are rather empirical. I am planning to put some mathematics in there eventually. At least after I return from my vacation. I think that I have demonstrated that there are weak master keys which can be used to construct an attack in 2^128 steps on individual sectors. I also discuss dictionary attacks and construct another attack which is more difficult than brute forcing each sector, but a little less time consuming than GBDE's author claims it should be. The URL is: http://www.imrryr.org/~elric/cgd/gbde-analysis.pdf Thanks, -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
