Re: Multiple layers of encryption

Mark Wooding wrote:

whole X.509/PKIX certification model is utterly hopeless. In the light
of (b), especially, I can't honestly recommend `vanilla' TLS.

Well, I'm not going to be screwing around with crypto algorithms myself
and wouldn't dare to try modifying them. I'll just be using Crypto++
functions to do DH key exchange followed by Serpent or Rijndael etc. I
will also be encrypting local files with a password.

The software I'm writing it a networked teamwork database for recording
and tracking networks of organised crime and corruption. Most users
wouldn't need much security, but some might be really paranoid and want
the maximum they can get. But as other people have said the physical
computer used and data storage are much weaker points of access. So I'm
not going to go crazy with the encryption, it's just waste of time
considering the highly professional and cutting edge technology of
potential opponents. There are countless instances where files regarding
investigations of organised crime or corrupt members of authority have
resulted in thefts and vandalism. For example, in the investigation into
the Clintons and tainted blood supplies one US office was raided and a
computer stolen and a Canadian office was burned down. So if the
powerful bad guys of the world want your data then they're going to get
it one way or another. All this encryption stuff just locks the doors
and slows them down rather than leaving the door wide for them to just
waltz in as they please.

I have looked at using libraries such as OpenSSL, MCrypt and GNU PGP but
their functions are limited to their intended use. Crypto++ offers
maximum functionality and hence greatest flexibility in choice of
encryption, both now and in the near future. I realise that if I use
DH-Serpent then that's not much different from SSL but by using Crypto++
I get to choose whatever algorithms and key sizes I want rather than
just accepting whatever standards SSL clients/servers use, which often
isn't the strongest for reasons of computational power on a broad range
of consumer devices.


Many thanks,
Erik
.

Relevant Pages

  • Re: Quadruple Algorithms
    ... occurring" (a fatal flaw being found in AES, ... If you really want secure crypto use various layers of encryption ... with the output of one cipher feeding ...
    (sci.crypt)
  • Re: AES and Diehard
    ... >you could employ kill file, ... The result of encryption which might eventually develop ... a standard for crypto the 'diversity' of interests is ... compression algorithm could exploit in order to compress. ...
    (sci.crypt)
  • Re: TrueCrypt or DiskCryptor?
    ... Have been using TrueCrypt for at least two years. ... source review breaks down. ... So a high level of crypto ... One should instead "nest" the encryption (at ...
    (alt.privacy)
  • Re: Infinite One-Time Pad, is this product BS?
    ... the encryption any stronger than admitting that all of it together ... information needed to properly decrypt a message) and post it. ... I ran a contest here several years ago using ... my crypto and some people tried. ...
    (sci.crypt)
  • Re: Crypto implementation in consumer encryption software
    ... >literally hundreds of encryption programs using AES, Twofish, ... too many also put every concevable feature in the product - giving ... reasonable risk, and find a product that does what you want. ... most 'consumer' crypto apps don't seem to understand ...
    (sci.crypt)