RDF: Serialise/parse to optionally encrypt/decrypt

[gjwgit]

For a Trust No ONe context, allow optional encryption key argument to parse() and serialise() to decrypt/encrypt.

Perhaps use ttc for encrypted ttl files.

[tian3rd]

Will first try the following two for file encryption and decryption:

1. https://pub.dev/packages/encrypt
2. https://pub.dev/packages/aes_crypt

[gjwgit]

Also have a look at what Anushka has done - he already has the encryption/decryption implemented in the indi and comm apps.

[tian3rd]

Also have a look at what Anushka has done - he already has the encryption/decryption implemented in the indi and comm apps.

Good idea! I'll check Anushka's code first!

[tian3rd]

After discussion with Anushka, I understand that for this package, we don't need to worry about Solid Pod side, and just focusing on encryption and decryption of the triple data, and then write/read encrypted/decrypted data to/from the file.

So it's a two-part task:

• Optional encryption of data (AES for now) in serializing
• Optional decryption of data in parsing

[tian3rd]

For encryption, Anushka suggested using a hashed key in the encrypted ttl file, which is useful when we want to check if the key is correct without the need to try decrypting the file (potentially very large thus time-consuming). So the encrypted ttl file will have the following format:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

rdf:subject rdf:type "encrypted"^^xsd:string ;
    xsd:token "936a185caaa266bb9cbe981e9e05cb78"^^xsd:string ;
    rdf:value "Fyc2DmEed6gx44lqebSQWDNmr+iAURRBKM+bvIhV+MVMgGslM3UOO8ti/IQIWkKAXRe78wcFQsWo2xPTRxHYA83Ng9igW4Hik0DeV0+F8eMwnB+Jt80GY3CaRbvmXc9+ZW1tOnytJvN02qezloaydDf8NdG5eOLOSwiMvfxVpnX/G/u8MP6dGoxM9D3nGLsjXaS3kTNWSYHIG+w0EKkrFKX/5krck8uXqyMudj3HpIRcJ8WhSjeBQRa0Mpn+y/AaQOGX3O33xpc2UPPGVrfa0Z9vuvBCaOqHeU22mNslpBT2R5/wHgGUuEZtNEvR7sUAFFMns3DOVC7YP7RuVTeWZDwktDUvNJJgWT+mFFezpQ5Y5vGSdHcuAUexR/EEEAISN+3XEWFUxHeR4zJQWSg0tCE0OI2OhPswCNPIQ5QcnKC3DdYsHtyJnKgfW+HTIK6jZ7k/Ug0iYoe2h2LzLr4E2k+uIOdOuZwHFZwhT3OVJyP9DslQ46YedVxXTxYGO1r4ZB0sMDvhcrV7Scrd6zrNrw6x4AypCf4G0w4hClEjgWtz5NcA9V6/5YQR+pcZMu+nb3gZHoKzfwm0TiwiaSR1nYSC5zi7oP70yEDjdO4ujkTZFBtn/0ooHbSMN5q0xt5JE3LZy8sSwXUs4y60IDY+eiB/3pOkK84b9FWl36PpWOn9FzRA+s2s/lBs/YOlFAvWB5F4NksN/tpaamEYfYJxohx4c4HCrarCG4neFTLIgNgN7lbTuuQWh/2iQoQL5VniPSrkUv0c9IOWdy+KRvS8t9dsNKUzoIFAePU7CP73PJ2n4y0Zl+k4XKPLkMhNumzhZO3KhO8hRf05Mfmt2WkpUuG8Pomhf1oGZI+36grX6d4mowrjsafLEEnx65GfXQ9M1mjg0ZrZb+FvY2sATbg5aCz52X30EMR7SrbYmVn3PpPITGCIenDff5bySxKuotOphVwrcHkea1BC2dEBsZQyVL9SF3vXq5es2gaSGD69DajbAjtwf5jgCHseebzDnr6AfDVIgHgx38Rb1pvhOQ7+0bDOQAKqJBXMZiGMKwtIiMr7gJlBHvP7RblycjjubFBCcCq60qpOSumS/A/cld+emA=="^^xsd:string .

which is the encrypted version of the following ttl file:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix sh-data: <http://silo.net.au/data/SOLID-Health#> .
@prefix sh-onto: <http://sii.cecs.anu.edu.au/onto/SOLID-Health#> .

sh-data:AssessmentTab-p43623-20220727T120913 rdf:type owl:NamedIndividual ;
    rdf:type sh-onto:AssessmentTab ;
    sh-onto:asthmaControl "Poor Control"^^xsd:string ;
    sh-onto:diastolicBloodPressure "75"^^xsd:int ;
    sh-onto:systolicBloodPressure "125.0"^^xsd:float .

sh-data:SeeAndDoTab-p43623-20220727T120913 rdf:type owl:NamedIndividual ;
    sh-onto:hasSeeAndDoOption sh-data:SeeAndDoOption-p43623-20220727T120913-fitnessDrive .

sh-data:SeeAndDoOption-p43623-20220727T120913-fitnessDrive rdf:type owl:NamedIndividual .

We specify three triples in the encrypted ttl file:

1. the first triple indicates this is an encrypted file (optional, can be omitted)
2. the second triple specifies the hashed key (the key is for the AES encryption/decryption)
3. the third triple contains the encrypted data of the whole original ttl file

The subjects and predicates of the second and third line can be modified based on our ontology in the future (e.g. CECS namespaces), here we use the RDF and XSD standard namespaces as placeholders.

[tian3rd]

Hi @gjwgit sorry I just noticed that you suggested using ttc for encrypted ttl file. So is there any standard format for this specific file format? Or is it similar to ttl turtle syntax?

(The current version uses .enc.ttl which is also a valid ttl file, we can modify it based on our needs)

[gjwgit]

.enc.ttl makes sense since it is a valid ttl file.