medrogan a écrit 39 commentaires

Sapristi! Je ne peux plus éditer mon message.
Trois nouvelles versions du kernel me sont interdites…Je suppose qu'il y a eu quelques modifications dans la gestion de KMS et que mettre à jour nouveau (ce que j'ai déjà fait) ne résoudra malheureusement pas le problème (les noyaux futurs comporteront sans doutes cette modification) .

Bah en fait je joue également à des jeux vidéo (c'est mon plaisir coupable en dual-boot ;( ) et les benchmarks penchaient clairement en faveur de nvidia pour cette génération (sans compter les jeux optimisés pour physX etc…).
De plus je n'ai jamais essayé AMD et ai donc préféré rester dans ma zone de confort (raison alakon)…
Linus avait raison, je vais sans doute devoir vendre ma carte graphique et acheter chez AMD.

Merci pour ta réponse.
Je pense que copier un rapport dmesg complet sur un forum est nocif pour la sécurité de mon système (tu excuseras ma paranoïa).
J'ai cependant examiné les logs de la manière suivante:
- J'ai examiné les logs de démarrage du système (noyau 4.4 et 4.7)
- j'ai copié ces logs dans un fichier
- j'ai supprimé l'horodatage et les autres parties variables du fichier avec sed
- j'ai copié les doublons dans un autres fichier avec uniq

Je n'ai pas rencontré d'erreur significative (juste un problème avec mon clavier)…
Tu peux toujours me demander de copier certaines parties ciblées de mes logs. Encore désolé….

Le texte entre parenthèses est mal positionné, c'est dans mon volume de test qu'il y a un fichier contenant quatre caractères ;)

Ok merci j'ai compris, j'ai fait quelques tests avec "od" et, effectivement, il y a plein de blocs de zéros.

Oui mais une fois le volume chiffré, comment distingue-t-on ces motifs ?
Si l'algo est bien conçu le brouillage mathématique est censé être uniforme, non ?

Comment le disque peut être intégralement chiffré si aucune donnée n'y est modifiée ?
Je n'ai pas saisi le sens de ta dernière phrase. Tu m'invites à essayer avec un volume monté depuis un fichier ? C'est ce que j'ai fait avec losetup. Le contenu du fichier est intégralement chiffré.

J'ai fini par trouver des réponses à la plupart de mes questions.
J'ai utilisé la faq du site bitcoin.fr (qui semble assez exhaustive) et la doc d'Electrum.

Pour ceux que ça intéresse:

• Il existe un méthode de compression de la blockchain qui permet de réduire considérablement sa taille, de plus, il est possible d'utiliser des nœuds dédiés

• Je n'avais pas compris qu'une adresse = un solde et qu'une adresse est en fait un condensat de clef publique (plusieurs algorithmes de hashage sont en fait utilisés) encodé en base58

• Le serveur de blockchain est un mécanisme propre à Electrum qui n'est pas un client full node (n'héberge pas la blockchain et ne participe donc pas à la transmission et la sécurisation des transactions bitcoins)

Je n'ai en revanche rien trouvé sur les adresses de monnaie/change…

Un début de réponse sur le site officiel (https://electrum.org/#home): "Electrum is fast because it uses servers that index the bitcoin blockchain", avec la croissance de la blockchain c'est peut-être une alternative pertinente que de mettre en place des serveurs dédiés à son stockage…

Merci pour ta réponse.
J'avais malheureusement déjà visionné les deux vidéos et elles ne semblaient pas répondre à mes questions.
Pour la dernière, Electrum m'a demandé de me connecter à un serveur (dans une liste, ex: "ultra-ecoelectrum.my-gateway.de" en cochant sélection automatique) dont je ne sais rien de la finalité.
Des idées ?

Merci beaucoup, je viens d'essayer, ça fonctionne !

Curieux que je suis, j'ai encore quelques questions:

Je me suis rendu compte que mon paramétrage avec brctl n'était malheureusement pas conservé au redémarrage, j'ai donc entrepris de spécifier manuellement le bridge. Suite à quelques recherches, j'en arrive à la configuration fonctionnelle suivante (fichier /etc/network/interfaces):

auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto br0
iface br0 inet static
address 192.168.1.24
netmask 255.255.255.0
gateway 192.168.1.1
bridge_ports eno1
bridge_stp off
bridge_maxwait 0

• Pourquoi est-il conseillé de désactiver spanning tree ? Il me semble que c'est utilisé pour éviter les boucles de commutation dans les architectures comprenant des chemins redondants… Quel est l'intérêt de s'en préoccuper ?

• Ma configuration te semble-t-elle valide ? ;)

Ok, merci à vous deux.

Il y a cependant deux points qui m'échappent:

• Qu'entends-tu par basculer ma config ip ?

• Et, justement, pourquoi ma machine devient injoignable lorsque j'ajoute l'interface au bridge avec brctl ?

Ok j'ai compris, merci bien.
Je viens également de m’apercevoir que tu est l'auteur de quelques journaux sur le sujet, je vais de ce pas y jeter un oeil !

Merci pour ta réponse rapide.
J'ai cependant encore quelques questions (de noob ;).

• C'est bien la clef privée (ou une sous-clef privée) qui est utilisée pour signer ?

• Si la sous-clef privée est compromise, est-il possible de la remplacer sans compromettre l'intégrité de la clef primaire privée?

• Et à quoi peut bien servir une sous-clef publique (qui n'est, sauf erreur de ma part, utilisée que pour chiffrer les messages) ?