has anybody seen something like that?
-----BEGIN CONTAINER-----
AAEAAbhNth6wR78Jv94ci38B8XFG0Q1xdb2+JXji2RATYKGibZb41Syi1j/gB7oH
62qFCGdG2cFPm8Kj5eDDb6lpqW3WKmTPhMZE2aa/GCClgOPNu/Qqfb2vqWAwvgHy
.........
3jGzdXy6d4h7yfhycVcM2OtoE0eM701TpxWSPyjPawe6VKndfNN8C881iwiABFfN
qCtsUB+OxDDeJndc3VVxMEEPC2JujTbElPi/ekt1Xr2gHYLa
-----END CONTAINER-----
what does this container means? how it is generated?
iTunes send to apple FairPlayCertChain certificate and FairPlaySignature, apple responds with FairPlayKeyData and other info...
An introduction to Fairplay DRM can be found on page 2 of
http://teal.gmu.edu/courses/ECE646/project/reports_2007/AD-1.pdf
More about White-Box DES (what's behind the DRM) and one implementation of generating such containers:
https://crypto.stanford.edu/DRM2002/whitebox.pdf
Abstract of the second PDF:
For applications such as digital rights management (drm) solutions employing cryptographic implementations in software, white-box cryptography (or more formally: a cryptographic implementation designed to withstand the white-box attack context) is more appropriate
than traditional
black-box
cryptography. In the white-box context, the
attacker has total visibility into software implementation and execution,
and our objective is to prevent the extraction of secret keys from the
program. We present methods to make key extraction difficult in the
white-box context, with focus on symmetric block ciphers implemented
by substitution boxes and linear transformations. A
des
implementation
(useful also for triple-
des
) is presented as a concrete example.
If such information is not what you're looking for, please be more thorough in your question.
Related
I was searching through the internet for the meaning of this prefix.
Solidity docs do not have a clear explanation.
So what is this and why should I use it?
"\x19Ethereum Signed Message:\n32",
The prefix was introduced in EIP-191 as a way to distinguish signatures meant for Ethereum smart contracts, and for other cryptographic platforms. By adding the Ethereum-specific prefix, the message (with the prefix) results in a different signature, specific just for Ethereum. But if there were no platform-specific prefixes, the resulting signature would be the same for all platforms, which could potentially lead to signature replay attacks.
Note: Back in 2016, when this standard was introduced, there were no other EVM networks (e.g. Binance Smart Chain and Polygon) - or at least they were not widely used. Nowdays it's common to use the "Ethereum" prefix even if the message is intended for other EVM networks such as Polygon.
This specific byte 0x19 was standardized simply because an already existing implementation (in the Go Ethereum client software) was using it before the standard was finalized.
And the last number (32 in this case) is the byte length of the message (excluding the prefix) that is being signed.
I am designing a protocol to exchange IOUs (digital promissory notes).
These should be digitally signed, but the signature should be independent from the data representation (whether its XML, JSON, binary, little or big endian numbers).
Is there any standard on how to sign a list of strings and primitive types (like integers, floating points, booleans)?
There isn't one standard encoding, but you can specify canonical forms for particular encodings.
For json you could specify that there is no whitespace outside strings and that keys should be sorted in a particular way.
For ASN.1 there is DER encoding, which is the canonical form of BER.
There is Cryptographic Message Syntax (CMS), but I don't know much about it.
The better question is what is the best format for verifying digitally signed Data primitives.
The answer is xml formatted and signed according to the XAdES standard. XAdES is harmonized with the related standards and many implementations participate in interoperability tests hosted by etsi.
Unless it is easy to verify a digitally signed format, the signature has limited value.
You can sign any bit stream and store/maintain the signature as a detached signature. But then you and the relying parties (the recipients) need to deal with two files. One for the data and one for the signature.
The advantage of xml with XAdES is that the format enables the signed xml file to include the digital signature.
You can create an equivalent of XAdES for another data format such as json. But a new format has limited use unless it becomes popular and standardized. XAdES has already accomplished this, so it is the way to go.
Added
Re: comment--
I want to provide non-repudiation. I understand that I have to save the information I signed. But I was hoping that I don't have to save it as XML but could rather save all values included in the signature in a database (less verbosely) and uniquely reconstruct the signed string from them before verifying.
Technically, you can do that. You'll need to watch out for spacing issues within the xml. But practically, not a good idea. Why:
Proving non-repudiation requires that you meet the applicable burden of proof that the alleged signer really did sign the data.
You may be trying to convince the original signer of this, an expert third party (an auditor) or non-experts (lawyers and juries). You want to make it easy and simple to convince these people. Schemes such as "re-creating" the signed file are not simple to understand compared with "here is the original signed file. Its signature verifies and it was signed with the digital certificate belonging to Susan Signer."
To keep it simple, I'd suggest signing an XAdES XML file. Then extract the data from the file and use it in your dbms. Hang on to the original signed file in your dbms or elsewhere. In case of a dispute, produce the original file and show that it verifies. A second part of the audit would be to show that your dbms has the same data values as the signed XML.
The programming and storage costs of hanging on to the original, signed, xml file are de minimis, when compared with your goal of proving non-repudiation of the data.
By the way, how is the signer's certificate managed? If it is anything less than a QSCD (Qualified Signature Creation Device), such as storing the cert in the file system, then you have another problem: no way to conclusively prove that the certificate wasn't used by an imposter. Use a secure system for signing such as CoSign (my company) or an equivalent system.
I am kinda playing with the SHA-1 algorithm. I want to find out differences and variations in the results if I change few values in the SHA-1 algorithm for a college report. I have found a piece of java code to generate hash of a text. Its done by importing
java.security.MessageDigest
class. However, I want to change the h0-4 values and edit them but I don't know where can I find them? I had a look inside the MessageDigest class but couldn't find it there. Please help me out!
Thanx in advance.
I don't believe you can do that. Java doesn't provide any API for its MessageDigest Class, which can allow you change the values.
However, there are some workarounds (none of which I've ever tried). Take a look at this answer to the question "How to edit Java Platform Package (Built-in API) source code?"
If you're playing around with tweaks to an algorithm, you shouldn't be using a built-in class implementing that algorithm. The class you mention is designed to implement standard algorithms for people who just want to use them in production; if you're using SHA-1 (or any cryptographic algorithm) instead of playing around and tweaking it, it's never a good idea to change the algorithm yourself (e.g. by changing the initial hash value), so the class does not support modifying those constants.
Just implement the algorithm yourself; from Wikipedia's pseudocode, it doesn't look like it's all that complicated. I know that "don't implement your own crypto, use a standard and well-tested implementation" is a common mantra here, but that only applies to production-type code -- if you're playing around with an algorithm to see what effect tweaking it has, you should implement it yourself, so you have more flexibility in modifying it and seeing the effect of the modifications.
Basically adding to #Rahil's answer but too much for comments:
Even without API access, if MessageDigest were the implementation you could use reflection. But it's not.
Most of the java standard library is just commonly-useful classes in the usual way, e.g. java.util.ArrayList contains the implementation of ArrayList (or ArrayList<?> since 6), java.io.FileInputStream contains the implementation of FileInputStream (although it may use other classes in that implementation), etc. Java Cryptography uses a more complicated scheme where the implementations are not in the API classes but instead in "providers" that are mostly in their own jars (in JRE/lib and JRE/lib/ext) not rt.jar and mostly(?) don't have source in src.zip.
Thus the java.security.MessageDigest class does not have the code to implement SHA1, or SHA256, or MD5, etc etc. Instead it has code to search the JVM's current list of crypto providers to find an implementation of whatever algorithm is asked for, and instantiate and use that. Normally the list of providers used is set to (the list of) those included in the JRE distribution, although an admin or program can change it.
With the normal JRE7 providers, SHA1 is implemented by sun.security.provider.SHA.
In effect the API classes like MessageDigest Signature Cipher KeyGenerator etc function more like interfaces or facades by presenting the behavior that is common to possibly multiple underlying implementations, although in Java code terms they are actual classes and not interfaces.
This was designed back in 1990 or so to cope with legal restrictions on crypto in effect then, especially on export from the US. It allowed the base Java platform to be distributed easily because by itself it did no crypto. To use it -- and even if you don't do "real" crypto on user data in Java you still need things like verification of signed code -- you need to add some providers; you might have one set of providers, with complete and strong algorithms, used in US installations, and a different set, with fewer and weaker algorithms, used elsewhere. This capability is now much less needed since the US officially relaxed and in practice basically dropped enforcement about 2000, although there are periodically calls to bring it back. There is still one residual bit, however: JCE (in Oracle JREs) contains a policy that does not allow symmetric keys over 128 bits; to enable that you must download from the Oracle website and install an additional (tiny) file "JCE Unlimited Strength Policy".
TLDR: don't try to alter the JCE implementation. As #cpast says, in this case where you want to play with something different from the standard algorithm, do write your own code.
Is it possible to duplicate output from the perl crypt function using ColdFusion decrypt?
I am not familiar with encryption programming, but as I understand it crypt uses the DES algorithm unless otherwise indicated. Coldfusion can use the DES algorithm, but I don't know what other parameters to use.
Allow me to clarify my situation. I am working with a vendor supplied application written in perl. My local toolset is mainly ColdFusion. I would like to enhance the vendor supplied login function with a 'lost your password/reset password' function. I would prefer not to change the vendor source code, which I have access to, since it get upgraded regularly and I don't want to have to keep applying the changes. The best solution, for a host of reasons, is to emulate the perl crypt() function output in ColdFusion so I can build the password reset function externally to the vendor application. It is admittedly an awkward and confusing situation.
I do not know if the emulation approach is feasible; if not it is back to the drawing board.
Just in case you didn't know, perl's crypt() function (and the crypt() function in the standard C library) is a one-way hashing function usually used for storing passwords. It's not an encryption function and there is no known decryption function.
As such, you're probably not looking for a function called decrypt(). I don't used Coldfusion, so I can't help you find the proper function.
Now I want to encrypt or decrypt some data in object-c use DES algorithm ,can somebody give me some suggestion?
First point. AES has replaced DES as the de-facto encrpytion standard, at least for the banking industry.
Second Point: Irrespective of what algo you decide on, this is what you have to do.
Add the Security.framework to your project.
Import the "CommonCrypto/CommonCryptor.h" file. This contains all the interfaces for symmetric encryption.
Using the methods in this class, you can define your encryption algo (AES, DES, etc.), the key size, padding that you want to use, etc.
You have to option of a one-shot API for encryption/decryption (CCCrypt()) or more advanced options if needed.
Hope this helps. Let me know if you need any particular information.
A code sample can be found in How to encrypt an NSString in Objective C with DES in ECB-Mode?
As the referring topic describes, you will have to keep in mind that DES uses a 56-bit (7 bytes) key and 64-bit (8 bytes) blocks.
Although DES is symmetric you will have to decrypt data by providing the kCCDecrypt option to the CCCrypt function.